| draft-aboba-avtcore-hevc-webrtc-00.txt | |||||||||||||||||
| H.265 Profile for WebRTC | |||||||||||||||||
|
RFC 7742 defines WebRTC video processing and codec requirements, including guidance for endpoints supporting the VP8 and H.264 codecs, which are mandatory to implement. With support for H.265 under development in WebRTC browsers, the need has arisen to provide similar guidance for browsers desiring to support the (optional) H.265 codec, whose RTP payload format is defined in RFC 7798. | ||||||||||||||||
| draft-abraitis-bgp-version-capability-13.txt | |||||||||||||||||
| Software Version Capability for BGP | |||||||||||||||||
|
In this document, we introduce a new BGP capability that allows the advertisement of a BGP speaker's routing daemon version. This BGP capability is an optional advertisement. Implementations are not required to advertise the version nor to process received advertisements. | ||||||||||||||||
| draft-abraitis-extcommunity-paths-00.txt | |||||||||||||||||
| BGP Available Paths Count Extended Community | |||||||||||||||||
|
This document defines a new BGP Opaque Extended Community to carry the number of paths available for an arbitrary prefix. | ||||||||||||||||
| draft-accilent-at-sign-00.txt | |||||||||||||||||
| Clarification of Proper Use of "@" (at sign) in URI-style Components | |||||||||||||||||
|
Defacto standards have evolved that conflict with existing standards, specifically RFC 3986. This document clarifies the use of the "@" (at sign) in URIs and partial URI-like addresses. | ||||||||||||||||
| draft-acee-idr-lldp-peer-discovery-14.txt | |||||||||||||||||
| BGP Logical Link Discovery Protocol (LLDP) Peer Discovery | |||||||||||||||||
|
Link Layer Discovery Protocol (LLDP) or IEEE Std 802.1AB is implemented in networking equipment from many vendors. It is natural for IETF protocols to avail this protocol for simple discovery tasks. This document describes how BGP would use LLDP to discover directly connected and 2-hop peers when peering is based on loopback addresses. | ||||||||||||||||
| draft-acee-lsr-ospfv3-sr-yang-08.txt | |||||||||||||||||
| YANG Data Model for OSPFv3 Segment Routing | |||||||||||||||||
|
This document defines a YANG data module augmenting the IETF OSPF Segment Routing (SR) YANG model to support OSPFv3 extensions for SR. It can be used to configure and manage OSPFv3 Segment Routing in MPLS data plane. | ||||||||||||||||
| draft-acee-rtgwg-vrrp-rfc8347bis-01.txt | |||||||||||||||||
| A YANG Data Model for the Virtual Router Redundancy Protocol (VRRP) | |||||||||||||||||
|
This document describes a data model for the Virtual Router Redundancy Protocol (VRRP). Both versions 2 and 3 of VRRP are covered. The VRRP terminology has been updated conform to inclusive language guidelines for IETF technologies. The IETF has designated National Institute of Standards and Technology (NIST) "Guidance for NIST Staff on Using Inclusive Language in Documentary Standards" for its inclusive language guidelines. This document obsoletes RFC 8347. | ||||||||||||||||
| draft-acme-device-attest-00.txt | |||||||||||||||||
| Automated Certificate Management Environment (ACME) Device Attestation Extension | |||||||||||||||||
|
This document specifies new identifiers and a challenge for the Automated Certificate Management Environment (ACME) protocol which allows validating the identity of a device using attestation. | ||||||||||||||||
| draft-adams-bimi-reporting-04.txt | |||||||||||||||||
| BIMI Reporting | |||||||||||||||||
|
To support the utility of Brand Indicators for Message Identification (BIMI), domains publishing BIMI records may find it useful to know when their logos are failing to be displayed as expected. When an entity, for example a mailbox operator, determines whether or not to display the logo identified in the BIMI record, they may encounter errors trying to retrieve the image file. Similarly, the associated evidence document used to validate the logo may fail evaluation. In other cases, the evaluator may decide that despite everything validating, they may rely on local policies that determine validated logos should still not be displayed. This specification defines how BIMI evaluators should report their evaluation outcome back to the publisher within the context of existing Domain-based Message Authentication, Reporting, and Conformance (DMARC) reports. | ||||||||||||||||
| draft-agrawal-bess-bgp-srv6-mpls-interworking-00.txt | |||||||||||||||||
| BGP extensions for SRv6 and MPLS interworking | |||||||||||||||||
|
This document define the BGP protocol extensions required to provide interworking between SRv6 and SR-MPLS/MPLS for SRv6 deployment. | ||||||||||||||||
| draft-agrawal-spring-srv6-mpls-interworking-11.txt | |||||||||||||||||
| SRv6 and MPLS interworking | |||||||||||||||||
|
This document describes SRv6 and MPLS/SR-MPLS interworking and co- existence procedures. | ||||||||||||||||
| draft-aguilar-lpwan-schc-convergence-00.txt | |||||||||||||||||
| SCHC Convergence Profile | |||||||||||||||||
|
The present document defines a profile of Static Context Header Compression and fragmentation (SCHC) [RFC8724] for multi-radio devices or multi-network application. This profile can be used simultaneously over LoRaWAN, Sigfox, NB-IoT and any other technology that may use SCHC Fragmentation/Reassembly functionality. | ||||||||||||||||
| draft-aguilar-lpwan-schc-streaming-00.txt | |||||||||||||||||
| SCHC Streaming Mode | |||||||||||||||||
|
This documents presents an update of SCHC [RFC8724] by providing a new F/R mode called SCHC Streaming mode. | ||||||||||||||||
| draft-ahuang-ioam-on-path-delay-00.txt | |||||||||||||||||
| On-Path delay Data Field for In Situ Operations,Administration,and Maintenance (IOAM) | |||||||||||||||||
|
This document defines a Data Field In Situ Operations, Administration, and Maintenance (IOAM) architecture for on-path delay information. This data field is registered as a new entry in the "IOAM Trace-Type" registry. | ||||||||||||||||
| draft-ahuang-ippm-dex-timestamp-ext-00.txt | |||||||||||||||||
| Timestamp extension for In Situ Operations,Administration,and Maintenance (IOAM) Direct Export | |||||||||||||||||
|
This document extends the In Situ Operations, Administration, and Maintenance (IOAM) Direct Export option type to support timestamping by adding and defining two optional timestamp fields and corresponding flags. | ||||||||||||||||
| draft-ahuang-netconf-notif-yang-01.txt | |||||||||||||||||
| YANG model for NETCONF Event Notifications | |||||||||||||||||
|
This document defines the YANG model for NETCONF Event Notifications. | ||||||||||||||||
| draft-ajitomi-cose-cose-key-jwk-hpke-kem-01.txt | |||||||||||||||||
| COSE Key and JSON Web Key Representation for Key Encapsulation Mechanism (KEM) of Hybrid Public Key Encryption (HPKE) | |||||||||||||||||
|
This document defines an additional key parameter and a new key type for CBOR Object Signing and Encryption (COSE) Key and JSON Web Key (JWK) to represent a Key Encapsulated Mechanism (KEM) key and its associated information for Hybrid Public Key Encryption (HPKE). | ||||||||||||||||
| draft-ali-spring-bfd-sr-policy-10.txt | |||||||||||||||||
| Bidirectional Forwarding Detection (BFD) for Segment Routing Policies for Traffic Engineering | |||||||||||||||||
|
Segment Routing (SR) allows a headend node to steer a packet flow along any path using a segment list which is referred to as a SR Policy. Intermediate per-flow states are eliminated thanks to source routing. The header of a packet steered in an SR Policy is augmented with the ordered list of segments associated with that SR Policy. Bidirectional Forwarding Detection (BFD) is used to monitor different kinds of paths between node. BFD mechanisms can be also used to monitor the availability of the path indicated by a SR Policy and to detect any failures. Seamless BFD (S-BFD) extensions provide a simplified mechanism which is suitable for monitoring of paths that are setup dynamically and on a large scale. This document describes the use of Seamless BFD (S-BFD) mechanism to monitor the SR Policies that are used for Traffic Engineering (TE) in SR deployments. | ||||||||||||||||
| draft-ali-spring-sr-service-programming-oam-05.txt | |||||||||||||||||
| OAM for Service Programming with Segment Routing | |||||||||||||||||
|
This document defines the Operations, Administrations and Maintenance (OAM) for service programming in SR-enabled MPLS and IP networks. | ||||||||||||||||
| draft-ali-spring-sr-traffic-accounting-08.txt | |||||||||||||||||
| Traffic Accounting in Segment Routing Networks | |||||||||||||||||
|
Capacity planning is the continuous art of forecasting traffic load and failures to evolve the network topology, its capacity, and its routing to meet a defined Service-Level Agreement (SLA). This document takes a holistic view of network capacity planning and identifies the role of traffic accounting in network operation and capacity planning, without creating any additional states in the SR fabric. | ||||||||||||||||
| draft-almprs-sustainability-insights-00.txt | |||||||||||||||||
| Sustainability Insights | |||||||||||||||||
|
This document motivates the collection and aggregation of sustainability environmental related metrics. It describes the motivation and requirements to collect asset centric metrics including but not limited to power consumption and energy efficiency, circular economy properties, and more general metrics useful in environmental impact analysis. It provides foundations for building an industry-wide, open-source framework for the reduction of greenhouse gas emissions, enabling measurement and optimization of the overall impact on the environment of networking devices, software applications, services, and solutions across the lifecycle journey. | ||||||||||||||||
| draft-amjad-cfrg-partially-blind-rsa-00.txt | |||||||||||||||||
| Partially Blind RSA Signatures | |||||||||||||||||
|
This document specifies a blind RSA signature protocol that supports public metadata. It is an extension to the RSABSSA protocol recently specified by the CFRG. Discussion Venues This note is to be removed before publishing as an RFC. Discussion of this document takes place on the Crypto Forum Research Group mailing list (cfrg@ietf.org), which is archived at https://mailarchive.ietf.org/arch/search/?email_list=cfrg. Source for this draft and an issue tracker can be found at https://github.com/chris-wood/draft-amjad-cfrg-partially-blind-rsa. | ||||||||||||||||
| draft-amsuess-core-cachable-oscore-06.txt | |||||||||||||||||
| Cacheable OSCORE | |||||||||||||||||
|
Group communication with the Constrained Application Protocol (CoAP) can be secured end-to-end using Group Object Security for Constrained RESTful Environments (Group OSCORE), also across untrusted intermediary proxies. However, this sidesteps the proxies' abilities to cache responses from the origin server(s). This specification restores cacheability of protected responses at proxies, by introducing consensus requests which any client in a group can send to one server or multiple servers in the same group. | ||||||||||||||||
| draft-amsuess-core-coap-kitchensink-03.txt | |||||||||||||||||
| Everything over CoAP | |||||||||||||||||
|
The Constrained Application Protocol (CoAP) has become the base of applications both inside of the constrained devices space it originally aimed for and outside. This document gives an overview of applications that are, can, may, and would better not be implemented on top of CoAP. | ||||||||||||||||
| draft-amsuess-core-coap-over-gatt-03.txt | |||||||||||||||||
| CoAP over GATT (Bluetooth Low Energy Generic Attributes) | |||||||||||||||||
|
Interaction from computers and cell phones to constrained devices is limited by the different network technologies used, and by the available APIs. This document describes a transport for the Constrained Application Protocol (CoAP) that uses Bluetooth GATT (Generic Attribute Profile) and its use cases. | ||||||||||||||||
| draft-amsuess-core-edhoc-grease-00.txt | |||||||||||||||||
| Applying Generate Random Extensions And Sustain Extensibility (GREASE) to EDHOC Extensibility | |||||||||||||||||
|
This document applies the extensibility mechanism GREASE (Generate Random Extensions And Sustain Extensibility), which was pioneered for TLS, to the EDHOC ecosystem. It reserves a set of non-critical EAD labels and unusable cipher suites that may be included in messages to ensure peers correctly handle unknown values. | ||||||||||||||||
| draft-amsuess-core-pd-body-error-position-01.txt | |||||||||||||||||
| Concise Problem Details: Body Error Position | |||||||||||||||||
|
This defines a single standard problem detail for use with the Concise Problem Details format: Request Body Error Position. Using this detail, the server can point at the position inside the client's request body that induced the error. | ||||||||||||||||
| draft-amsuess-core-resource-directory-extensions-08.txt | |||||||||||||||||
| CoRE Resource Directory Extensions | |||||||||||||||||
|
A collection of extensions to the Resource Directory [rfc9176] that can stand on their own, and have no clear future in specification yet. Discussion Venues This note is to be removed before publishing as an RFC. Discussion of this document takes place on the Constrained RESTful Environments Working Group mailing list (core@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/core/. Source for this draft and an issue tracker can be found at https://gitlab.com/chrysn/resource-directory-extensions. | ||||||||||||||||
| draft-analysis-challenges-00.txt | |||||||||||||||||
| Challenges,Opportunities,and Directions for Formal Analysis in the IETF and IRTF | |||||||||||||||||
|
This document discusses challenges, opportunities, and directions for formal analysis of protocols developed in the IETF. 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-analysis-challenges/. Source for this draft and an issue tracker can be found at https://github.com/chris-wood/draft-analysis-challenges. | ||||||||||||||||
| draft-anish-spring-bimap-multicast-00.txt | |||||||||||||||||
| SRv6 Bitmap Multicast | |||||||||||||||||
|
Multicast forwarding in a network provides advantages in improving the network usage and performance. In some cases it helps improve the operations in managing network. The major challenge in multicast operations is in managing the per-flow states in the network as required by all the legacy multicast frameworks. This document specifies a bitmap forwarding extension to SRv6 to support state-free forwarding model in a network. | ||||||||||||||||
| draft-aravindbabu-idr-bgp-ls-flex-algo-ext-00.txt | |||||||||||||||||
| Advertising Flexible Algorithm Extensions in BGP Link-State | |||||||||||||||||
|
Flexible Algorithm is a solution that allows some routing protocols (e.g., OSPF and IS-IS) to compute paths over a network based on user- defined (and hence, flexible) constraints and metrics. The computation is performed by routers participating in the specific network in a distributed manner using a Flexible Algorithm Definition. This Definition is provisioned on one or more routers and propagated through the network by OSPF and IS-IS flooding. BGP Link-State (BGP-LS) enables the collection of various topology information from the network. RFC9351 introduced BGP-LS support for the advertisement of Flexible Algorithm Definition as a part of the topology information from the network. This document specifies the advertisement of further Flexible Algorithm related extensions in BGP-LS. | ||||||||||||||||
| draft-arkko-iab-data-minimization-principle-04.txt | |||||||||||||||||
| Data minimization among protocol participants | |||||||||||||||||
|
Communications security has been at the center of many security improvements in the Internet. The goal has been to ensure that communications are protected against outside observers and attackers. Privacy has also been a key focus area, and understanding the privacy implications of new Internet technology is an important factor when IETF works on such technologies. One key aspect of privacy is minimization of data disclosed to other parties. This document highlights the need for a particular focus with respect to data minimization. Avoiding data leakage to outside parties is of course important, but it can also be necessary to limit it among the primary protocol participants. This is because is necessary to protect against endpoints that are compromised, malicious, or whose interests simply do not align with the interests of users. It is important to consider the role of a participant and limit any data provided to it according to that role. | ||||||||||||||||
| draft-arolovitch-cdni-named-footprints-00.txt | |||||||||||||||||
| Content Delivery Network Interconnection (CDNI) Named Footprints | |||||||||||||||||
|
Open Caching architecture is a use case of Content Delivery Networks Interconnection (CDNI) in which the commercial Content Delivery Network (CDN) is the upstream CDN (uCDN) and the ISP caching layer serves as the downstream CDN (dCDN). This document extends the Footprint & Capabilities Advertisement Interface (FCI) defined in RFC8008, to allow advertising of named footprint objects, that can be referenced in a consistent manner from Metadata Interface (MI), also defined in RFC8006, as well as from the FCI itself as well as additional interfaces in the Open Caching architecture. This document also supplements the CDNI Metadata Footprint Types defined in RFC8006 and modifies the CDNI operation as described in RFC7336. | ||||||||||||||||
| draft-art-tigress-01.txt | |||||||||||||||||
| Transfer Digital Credentials Securely | |||||||||||||||||
|
This document describes a mechanism to transfer digital credentials securely between two devices. Secure credentials may represent a digital key to a hotel room, a digital key to a door lock in a house or a digital key to a car. Devices that share credentials may belong to the same or two different platforms (e.g. iOS and Android). Secure transfer may include one or more write and read operations. Credential transfer needs to be performed securely due to the sensitive nature of the information. | ||||||||||||||||
| draft-asaeda-pim-multiif-igmpmldproxy-05.txt | |||||||||||||||||
| Multiple Upstream Interface Support for IGMP/MLD Proxy | |||||||||||||||||
|
This document describes the way of supporting multiple upstream interfaces for an IGMP/MLD proxy device. The proposed extension enables an IGMP/MLD proxy device to receive multicast sessions/ channels through the different upstream interfaces. The upstream interface can be selected based on multiple criteria, such as the subscriber address prefixes, channel/session IDs, and interface priority values. A mechanism for upstream interface takeover that enables to switch from an inactive upstream interface to an active upstream interface is also described. | ||||||||||||||||
| draft-augustyn-intarea-ipref-00.txt | |||||||||||||||||
| IP Addressing with References (IPREF) | |||||||||||||||||
|
This document describes IP addressing with references (referred to as IPREF) and how it can be used with IPv4 and IPv6. IPREF is a private-to-private technology where hosts on private networks communicate with hosts on other private networks directly. Special addresses, called IPREF addresses, are used for the purpose. It also describes how hosts on private networks may publish their IPREF addresses via Domain Name System (DNS). | ||||||||||||||||
| draft-bagnulo-iccrg-iccrg-ledbat-bbr-interop-00.txt | |||||||||||||||||
| LEDBAT++ BBR interoperability issues | |||||||||||||||||
|
This document specifies describes some interoperability issues identified between LEDBAT++ and BBR, resulting in unexpected behaviour. Specifically, that under a set of common conditions, LEDBAT++ fails to yield in front of both BBRv1 and BBRv2(instead of the opposite expected behaviour). | ||||||||||||||||
| draft-bamberger-bess-imet-filter-evpn-etree-vxlan-00.txt | |||||||||||||||||
| IMET Route Filtering for Ethernet VPN (EVPN) Ethernet Tree (E-Tree) with VXLAN Encapsulation | |||||||||||||||||
|
RFC 8317 defines EVPN Ethernet Tree (E-Tree) and associated filtering rules for both known unicast and broadcast, unknown unicast, and multicast (BUM) traffic, using Multiprotocol Label Switching (MPLS) encapsulation. The processes and protocols specified in RFC 8317 for performing E-Tree filtering on known unicast traffic are implemented entirely with EVPN routes, and are thus also applicable to networks using Virtual Extensible LAN (VXLAN) encapsulation. However, E-Tree filtering for BUM traffic is accomplished using specific features of MPLS encapsulation, and is thus not applicable for networks using VXLAN encapsulation. In networks where E-Tree root/leaf role classification is done per- provider edge (PE) device, or per-attachment circuit (AC) on each PE device, an extension to EVPN type-3 inclusive multicast (IMET) routes can be added to allow E-Tree filtering for BUM traffic in networks using VXLAN encapsulation. Additionally, this proposal specifies filtering BUM traffic on ingress, as opposed to the egress filtering specified by RFC 8317, which can be considered to be more optimal, as it reduces the amount of unnecessary BUM traffic transmitted over the network. | ||||||||||||||||
| draft-bar-cfrg-spake2plus-08.txt | |||||||||||||||||
| SPAKE2+,an Augmented PAKE | |||||||||||||||||
|
This document describes SPAKE2+, a Password Authenticated Key Exchange (PAKE) protocol run between two parties for deriving a strong shared key with no risk of disclosing the password. SPAKE2+ is an augmented PAKE protocol, as only one party has knowledge of the password. This method is simple to implement, compatible with any prime order group and is computationally efficient. This document was produced outside of the IETF and IRTF, and represents the opinions of the authors. Publication of this document as an RFC in the Independent Submissions Stream does not imply endorsement of SPAKE2+ by the IETF or IRTF. | ||||||||||||||||
| draft-barguil-teas-network-slices-instantation-06.txt | |||||||||||||||||
| Instantiation of IETF Network Slices in Service Providers Network | |||||||||||||||||
|
Network Slicing (NS) is an integral part of Service Provider networks. The IETF has produced several YANG data models to support the Software-Defined Networking and network slice architecture and YANG- based service models for network slice (NS) instantiation. This document describes the relationship between IETF Network Slice models for requesting the IETF Network Slices and (e.g., Layer-3 Service Model, Layer-2 Service Model) and Network Models (e.g., Layer-3 Network Model, Layer-2 Network Model) used during their realizations. In addition, this document describes the communication between the IETF Network Slice Controller and the network controllers for the realization of IETF network slices. The IETF Network Slice YANG model provides the customer-oriented view of the network slice. Thus, once the IETF Network Slice controller (NSC) receives a request, it needs to map it to accomplish the specific parameters expected by the network controllers. The network models are analyzed to satisfy the IETF Network Slice requirements, and the gaps in existing models are reported. The document also provides operational and security considerations when deploying network slices in Service Provider networks. | ||||||||||||||||
| draft-barkai-lisp-pems-06.txt | |||||||||||||||||
| Portable Edge Multipoint Sockets | |||||||||||||||||
|
This document describes the use of the location/identity separation protocol (LISP) for performing on-path scaling and service-selection in environments where off-path cloud based web measures do not perform well. Scaling and service-selection is achieved by abstracting multipoint queue/channel socket communication objects, addressed by well known or algorithmic endpoint identifiers (EID). Multipoint sockets are decoupled from specific user-space processes, are portable between hosts and network locations. Portability applied by system management according to global considerations, relies on the LISP network for on-path steering between roaming clients and elastic functional processing. Interoperable on-path scaling is achieved by application specific socket addressing scheme. | ||||||||||||||||
| draft-barnes-mimi-identity-arch-00.txt | |||||||||||||||||
| Identity for E2E-Secure Communications | |||||||||||||||||
|
End-to-end (E2E) security is a critical property for modern user communications systems. E2E security protects users' communications from tampering or inspection by intermediaries that are involved in delivering those communcations from one logical endpoint to another. In addition to the much-discussed E2E encryption systems, true E2E security requires an identity mechanism that prevents the communications provider from impersonating participants in a session, as a way to gain access to the session. This document describes a high-level architecture for E2E identity, identifying the critical mechanisms that need to be specified. | ||||||||||||||||
| draft-barnes-mls-userinfo-vc-00.txt | |||||||||||||||||
| UserInfo Verifiable Credentials as MLS Credentials | |||||||||||||||||
|
This specification extends Message Layer Security (MLS) credentials framework with a new credential type, "UserInfoVC", based on the OpenID Connect UserInfo Verifiable Credential type "UserInfoCredential". A UserInfo Verifiable Credential encapsulates the UserInfo claims from the OpenID provider as a Verifiable Credential that can be presented to a third-party Verifier. These credentials can be easily provisioned to MLS clients using the OpenID Connect login flows, augmented with type "UserInfoCredential". The credential itself is an object associating identity attributes to the signature public key that the client will use in MLS, signed by the OpenID Provider. In situations where the OpenID Provider is distinct from the MLS Delivery Service, these credentials provide end-to-end secure identity assurance. | ||||||||||||||||
| draft-barnes-sframe-mls-01.txt | |||||||||||||||||
| Using Messaging Layer Security (MLS) to Provide Keys for SFrame | |||||||||||||||||
|
Secure Frames (SFrame) defines a compact scheme for encrypting real- time media. In order for SFrame to address cases where media are exchanged among many participants (e.g., real-time conferencing), it needs to be augmented with a group key management protocol. The Messaging Layer Security (MLS) protocol provides continuous group authenticated key exchange, allowing a group of participants in a media session to authenticate each other and agree on a group key. This document defines how the group keys produced by MLS can be used with SFrame to secure real-time sessions for groups. | ||||||||||||||||
| draft-barthel-lpwan-oam-schc-04.txt | |||||||||||||||||
| OAM for LPWAN using Static Context Header Compression (SCHC) | |||||||||||||||||
|
With IP protocols now generalizing to constrained networks, users expect to be able to Operate, Administer and Maintain them with the familiar tools and protocols they already use on less constrained networks. OAM uses specific messages sent into the data plane to measure some parameters of a network. Most of the time, no explicit values are sent is these messages. Network parameters are obtained from the analysis of these specific messages. This can be used: * To detect if a host is up or down. * To measure the RTT and its variation over time. * To learn the path used by packets to reach a destination. OAM in LPWAN is a little bit trickier since the bandwidth is limited and extra traffic added by OAM can introduce perturbation on regular transmission. Two scenarios can be investigated: * OAM coming from internet. In that case, the NGW should act as a | ||||||||||||||||
| draft-basavaraj-lsr-ospf-gr-enhancements-06.txt | |||||||||||||||||
| OSPF Graceful Restart Enhancements | |||||||||||||||||
|
This document describes enhancements to the OSPF graceful restart procedures to improve routing convergence in some OSPF network deployments. This document updates RFC 3623 and RFC 5187. | ||||||||||||||||
| draft-bash-rfc7958bis-00.txt | |||||||||||||||||
| DNSSEC Trust Anchor Publication for the Root Zone | |||||||||||||||||
|
The root zone of the Domain Name System (DNS) has been cryptographically signed using DNS Security Extensions (DNSSEC). In order to obtain secure answers from the root zone of the DNS using DNSSEC, a client must configure a suitable trust anchor. This document describes the format and publication mechanisms IANA has used to distribute the DNSSEC trust anchors. | ||||||||||||||||
| draft-bashandy-rtgwg-segment-routing-uloop-14.txt | |||||||||||||||||
| Loop avoidance using Segment Routing | |||||||||||||||||
|
This document presents a mechanism aimed at providing loop avoidance in the case of IGP network convergence event. The solution relies on the temporary use of SR policies ensuring loop-freeness over the post-convergence paths from the converging node to the destination. | ||||||||||||||||
| draft-baum-jmap-backend-info-00.txt | |||||||||||||||||
| JMAP Backend Information | |||||||||||||||||
|
It is likely that any JMAP implementation has either bugs or intentionally deviates from the standard. To cope with such a unique behavior, JMAP clients need to identify the software behind the JMAP endpoint and apply custom logic. This specification defines the ability to provide details about the product, backend and environment for JMAP servers. | ||||||||||||||||
| draft-baum-jmap-debug-00.txt | |||||||||||||||||
| JMAP Debug Logging | |||||||||||||||||
|
This document specifies a data model for extending the JMAP Response with log messages, particularly helpful for debugging. | ||||||||||||||||
| draft-baum-jmap-portability-01.txt | |||||||||||||||||
| JMAP for Migration and Data Portability | |||||||||||||||||
|
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. However, due to its large set of features, it is also quite complex, which makes it difficult to explore new application domains in practice. The goal of this document is to provide guidelines on implementing essential parts of JMAP for a much lower entry barrier and more efficient implementation of the protocol. | ||||||||||||||||
| draft-baum-jmap-rest-00.txt | |||||||||||||||||
| JMAP REST Mapping | |||||||||||||||||
|
This document specifies a REST Mapping for JMAP endpoints to impose fewer requirements on applications compared to conventional JMAP endpoints. | ||||||||||||||||
| draft-belchior-gateway-recovery-05.txt | |||||||||||||||||
| DLT Gateway Crash Recovery Mechanism | |||||||||||||||||
|
This memo describes the crash recovery mechanism for the Secure Asset Transfer Protocol (SATP). The goal of this draft is to specify the message flow that implements a crash recovery mechanism. The mechanism assures that gateways running SATP are able to recover faults, enforcing ACID properties for asset transfers across ledgers (i.e., double spend does not occur). | ||||||||||||||||
| draft-bellis-dnsext-multi-qtypes-07.txt | |||||||||||||||||
| DNS Multiple QTYPEs | |||||||||||||||||
|
This document specifies a method for a DNS client to request additional DNS record types to be delivered alongside the primary record type specified in the question section of a DNS query. | ||||||||||||||||
| draft-bellis-dnsop-qdcount-is-one-00.txt | |||||||||||||||||
| In the DNS,QDCOUNT is (usually) One | |||||||||||||||||
|
This document clarifies the allowable values of the QDCOUNT parameter in DNS messages with OPCODE = 0 (QUERY) and specifies the required behaviour when values that are not allowed are encountered. | ||||||||||||||||
| draft-benecke-cfbl-address-header-10.txt | |||||||||||||||||
| Complaint Feedback Loop Address Header | |||||||||||||||||
|
This document describes a method that allows a Message Originator to specify a complaint feedback loop (FBL) address as a message header field. Also, it defines the rules for processing and forwarding such a complaint. The motivation for this arises out of the absence of a standardized and automated way to provide Mailbox Providers with an address for a complaint feedback loop. Currently, providing and maintaining such an address is a manual and time-consuming process for Message Originators and Mailbox Providers. The mechanism specified in this document is being published as an experiment, to gauge interest of, and gather feedback from implementers and deployers. This document is produced through the Independent RFC stream and was not subject to the IETF's approval process. | ||||||||||||||||
| draft-bernardos-detnet-multidomain-01.txt | |||||||||||||||||
| DETNET multidomain extensions | |||||||||||||||||
|
This document addresses the multi-domain DetNet problem, analyzing what the technical gaps are and exploring some possible solutions. Application, control and data plane aspects are in scope. The goal is to help understanding what might be the next steps towards enabling DetNet in multi technology and/or administrative domains. | ||||||||||||||||
| draft-bernardos-dmm-mobility-virtualization-01.txt | |||||||||||||||||
| Mobility challenges in virtualization environments | |||||||||||||||||
|
Mobility is no longer restricted to physical end systems roaming among radio points of attachment. Current mobile network deployments do not only consider the traditional client-server model, but also include scenarios in which services are decomposed into functions that run on virtualized resources, thus becoming virtual functions. This opens the door for new scenarios in which mobility now includes: (i) the end-system mobility (traditional scenario), (ii) a physical resource hosting a virtual function (part of a service being consumed by a end-system) moving, and (iii) a virtual function part of a service moving (migrating) to a different physical resource. As these scenarios are expected to be more commonly deployed in the short future, this documents aims at presenting the new mobility- related scenarios and the potential gaps in terms of IETF protocols. | ||||||||||||||||
| draft-bernardos-dmm-sfc-mobility-06.txt | |||||||||||||||||
| SFC function mobility with Mobile IPv6 | |||||||||||||||||
|
Service function chaining (SFC) allows the instantiation of an ordered set of service functions and subsequent "steering" of traffic through them. In order to set up and maintain SFC instances, a control plane is required, which typically is centralized. In certain environments, such as fog computing ones, such centralized control might not be feasible, calling for distributed SFC control solutions. This document specifies Mobile IPv6 extensions to enable function migration in SFC. | ||||||||||||||||
| draft-bernardos-raw-joint-selection-raw-mec-04.txt | |||||||||||||||||
| Terminal-based joint selection and configuration of MEC host and RAW network | |||||||||||||||||
|
There are several scenarios involving multi-hop heterogeneous wireless networks requiring reliable and available features combined with multi-access edge computing, such as Industry 4.0. This document discusses mechanisms to allow a terminal influencing the selection of a MEC host for instantiation of the terminal-targeted MEC applications and functions, and (re)configuring the RAW network lying in between the terminal and the selected MEC host. This document assumes IETF RAW and ETSI MEC integration, fostering discussion about extensions at both IETF and ETSI MEC to better support these scenarios. | ||||||||||||||||
| draft-bernardos-raw-mec-05.txt | |||||||||||||||||
| Extensions to enable wireless reliability and availability in multi-access edge deployments | |||||||||||||||||
|
There are several scenarios involving multi-hop heterogeneous wireless networks requiring reliable and available features combined with multi-access edge computing, such as Industry 4.0. This document describes solutions integrating IETF RAW and ETSI MEC, fostering discussion about extensions at both IETF and ETSI MEC to better support these scenarios. | ||||||||||||||||
| draft-bernardos-raw-mobility-00.txt | |||||||||||||||||
| MIPv6 RAW mobility | |||||||||||||||||
|
There are several use cases where reliability and availability are key requirements for wireless heterogeneous networks in which connected devices might be mobile, such as eXtended Reality (XR). This document discusses and specifies control plane solutions to cope with mobility, by proactively preparing the network for the change of point of attachment of a connected mobile node. It also defines Mobile IPv6 extensions implementing these control plane solutions. | ||||||||||||||||
| draft-bernardos-raw-multidomain-02.txt | |||||||||||||||||
| RAW multidomain extensions | |||||||||||||||||
|
This document describes the multi-domain RAW problem and explores and proposes some extensions to enable RAW multi-domain operation. | ||||||||||||||||
| draft-bernardos-sfc-distributed-control-operation-06.txt | |||||||||||||||||
| Distributed SFC control operation | |||||||||||||||||
|
Service function chaining (SFC) allows the instantiation of an ordered set of service functions and subsequent "steering" of traffic through them. In order to set up and maintain SFC instances, a control plane is required, which typically is centralized. In certain environments, such as fog computing ones, such centralized control might not be feasible, calling for distributed SFC control solutions. This document describes a general framework for distributed SFC operation. | ||||||||||||||||
| draft-bernardos-sfc-nsh-distributed-control-07.txt | |||||||||||||||||
| NSH extensions for local distributed SFC control | |||||||||||||||||
|
Service function chaining (SFC) allows the instantiation of an ordered set of service functions and subsequent "steering" of traffic through them. In order to set up and maintain SFC instances, a control plane is required, which typically is centralized. In certain environments, such as fog computing ones, such centralized control might not be feasible, calling for distributed SFC control solutions. This document specifies several NSH extensions to provide in-band SFC control signaling. | ||||||||||||||||
| draft-bestbar-teas-yang-nrp-policy-03.txt | |||||||||||||||||
| YANG Data Model for Network Resource Partition Policy | |||||||||||||||||
|
A Network Resource Partition (NRP) is a collection of resources identified in the underlay network to support services (like IETF Network Slices) that need logical network structures with required characteristics to be created. An NRP policy is a policy construct that enables instantiation of mechanisms in support of service specific control and data plane behaviors on select topological elements associated with the NRP. This document defines a YANG data model for the management of NRP policies on NRP capable nodes and controllers in IP/MPLS networks. | ||||||||||||||||
| draft-bestbar-teas-yang-topology-filter-04.txt | |||||||||||||||||
| YANG Data Model for Topology Filter | |||||||||||||||||
|
This document defines a YANG data model for the management of topology filters/filter-sets on network elements and controllers. | ||||||||||||||||
| draft-bettini-imap-inprogress-00.txt | |||||||||||||||||
| IMAP4 Response Code for Command Progress Notifications. | |||||||||||||||||
|
This document defines a new IMAP untagged response code, "INPROGRESS", that serves as a keepalive for the client and, optionally, provides numeric progress status indication. | ||||||||||||||||
| draft-bft-rats-kat-00.txt | |||||||||||||||||
| An EAT-based Key Attestation Token | |||||||||||||||||
|
This document defines an evidence format for key attestation based on the Entity Attestation Token (EAT) format. Discussion Venues This note is to be removed before publishing as an RFC. Discussion of this document takes place on the Remote ATtestation ProcedureS Working Group mailing list (rats@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/rats/. Source for this draft and an issue tracker can be found at https://github.com/thomas-fossati/draft-kat. | ||||||||||||||||
| draft-bi-savi-wlan-24.txt | |||||||||||||||||
| A SAVI Solution for WLAN | |||||||||||||||||
|
This document describes a source address validation solution for WLANs where 802.11i or other security mechanisms are enabled to secure MAC addresses. This mechanism snoops NDP and DHCP packets to bind IP addresses to MAC addresses, and relies on the security of MAC addresses guaranteed by 802.11i or other mechanisms to filter IP spoofing packets. It can work in the special situations described in the charter of SAVI (Source Address Validation Improvements) workgroup, such as multiple MAC addresses on one interface. This document describes three different deployment scenarios, with solutions for migration of binding entries when hosts move from one access point to another. | ||||||||||||||||
| draft-bichot-msync-11.txt | |||||||||||||||||
| MSYNC | |||||||||||||||||
|
This document describes the Multicast Synchronization (MSYNC) Protocol that aims at transferring video media objects over IP multicast. Although generic, MSYNC has been primarily designed for transporting HTTP adaptive streaming (HAS) objects including manifest/playlists and media segments (e.g., CMAF) according to an HAS protocol such as Apple HLS or MPEG DASH between a multicast sender and a multicast receiver. | ||||||||||||||||
| draft-billon-expires-08.txt | |||||||||||||||||
| Updated Use of the Expires Message Header Field | |||||||||||||||||
|
This document allows broader use of the Expires message header field for mail messages. Message creators can then indicate when a message loses its validity, while recipients would use the information to ignore or change the display of these messages. | ||||||||||||||||
| draft-birkholz-cose-tsa-tst-header-parameter-01.txt | |||||||||||||||||
| COSE Header parameter for RFC 3161 Time-Stamp Tokens | |||||||||||||||||
|
RFC 3161 provides a method to time-stamp a message digest to prove that it was created before a given time. This document defines how signatures of CBOR Signing And Encrypted (COSE) message structures can be time-stamped using RFC 3161 along with the needed header parameter to carry the corresponding time-stamp. | ||||||||||||||||
| draft-birkholz-rats-epoch-markers-04.txt | |||||||||||||||||
| Epoch Markers | |||||||||||||||||
|
This document defines Epoch Markers as a way to establish a notion of freshness among actors in a distributed system. Epoch Markers are similar to "time ticks" and are produced and distributed by a dedicated system, the Epoch Bell. Systems that receive Epoch Markers do not have to track freshness using their own understanding of time (e.g., via a local real-time clock). Instead, the reception of a certain Epoch Marker establishes a new epoch that is shared between all recipients. | ||||||||||||||||
| draft-birkholz-scitt-receipts-02.txt | |||||||||||||||||
| Countersigning COSE Envelopes in Transparency Services | |||||||||||||||||
|
A transparent and authentic Transparent Registry service in support of a supply chain's integrity, transparency, and trust requires all peers that contribute to the Registry operations to be trustworthy and authentic. In this document, a countersigning variant is specified that enables trust assertions on Merkle-tree based operations for global supply chain registries. A generic procedure for producing payloads to be signed and validated is defined and leverages solutions and principles from the Concise Signing and Encryption (COSE) space. | ||||||||||||||||
| draft-birrane-dtn-ari-01.txt | |||||||||||||||||
| Asynchronous Resource Identifier | |||||||||||||||||
|
This document defines the structure, format, and features of the naming scheme for the objects defined in the Delay-Tolerant Networking (DTN) Application Data Model (ADM), in support of challenged network management solutions described in the Delay- Tolerant Networking Autonomous Management Architecture (AMA). This document defines a new Asynchronous Resource Identifier (ARI), based on the structure of a common URI, meeting the needs for a concise, typed, parameterized, and hierarchically organized set of data elements. | ||||||||||||||||
| draft-birrane-tvr-use-cases-00.txt | |||||||||||||||||
| TVR (Time-Variant Routing) Use Cases | |||||||||||||||||
|
Time-Variant Routing (TVR) refers to the calculation of a path or subpath through a network where the time of message transmission (or receipt) is part of the overall route computation. This means that, all things being equal, a TVR computation might produce different results depending on the time that the computation is performed without other detectable changes to the network topology or other cost functions associated with the route. This document introduces use cases where TVR computations could improve message exchange in a network. | ||||||||||||||||
| draft-blanchet-dtn-bp-application-framework-00.txt | |||||||||||||||||
| Delay-Tolerant Networking (DTN) Bundle Protocol Application Framework | |||||||||||||||||
|
The current Bundle Protocol specifications define the syntax of service identifiers but do not identify how to make them interoperable. For example, there are currently no way to map a service identifier to a specific Bundle payload format for an application agent. This document proposes an application framework enabling interoperable implementations and deployments of the Bundle Protocol. It also creates a service identifier registry for the Bundle Protocol. Warning: this draft was initially done in 2012 against RFC5050 in DTNRG; some parts may need to be updated. | ||||||||||||||||
| draft-blanchet-dtn-email-over-bp-01.txt | |||||||||||||||||
| Encapsulation of Email over Delay-Tolerant Networks(DTN) using the Bundle Protocol | |||||||||||||||||
|
This document describes the encapsulation of emails using RFC2442 format in the payload of bundles of the Bundle Protocol for the use case of Delay-Tolerant Networks(DTN) such as in space communications. | ||||||||||||||||
| draft-blanchet-dtn-http-over-bp-00.txt | |||||||||||||||||
| Encapsulation of HTTP over Delay-Tolerant Networks(DTN) using the Bundle Protocol | |||||||||||||||||
|
This document describes the encapsulation of HTTP requests and responses in the payload of bundles of the Bundle Protocol for the use case of Delay-Tolerant Networks(DTN) such as in space communications. | ||||||||||||||||
| draft-blanchet-quic-peerhints-00.txt | |||||||||||||||||
| Priming QUIC with Peer Hints for Atypical Networks,such as Delay-Tolerant Networks(DTN) | |||||||||||||||||
|
Abstract | ||||||||||||||||
| draft-blanchet-regext-rdap-space-00.txt | |||||||||||||||||
| RDAP Query and Response for Space Objects and Networks | |||||||||||||||||
|
Objects and networks in space are owned by entities, have locations and have identity or network address. This document describes Registration Data Access Protocol(RDAP) queries and response for these space objects and networks. | ||||||||||||||||
| draft-blanchet-tvr-contactplan-00.txt | |||||||||||||||||
| Contact Plan for Time-Variant Routing | |||||||||||||||||
|
Some networks, such as in space, have links that are up and down based on a known schedule. The links characteristics, such as latency and bandwidth, are often also known in advance. This document describes a data model, also known as contact plan or graph, and file format to be used as input to forwarding and routing engines. This specification applies for both IP and Bundle Protocol. | ||||||||||||||||
| draft-blanchet-tvr-forwarding-00.txt | |||||||||||||||||
| Forwarding in the context of Time-Variant Routing(TVR) | |||||||||||||||||
|
Some networks, such as in space, have links that are up and down based on a known schedule. In this context, IP Packets or Bundle Protocol Bundles should then be saved locally until the destination becomes reachable again. This document describes forwarding node policies regarding how to manage the local store as well as forwarding decisions. This specification applies to both IP packets or Bundle Protocol bundles. | ||||||||||||||||
| draft-bonica-6man-comp-rtg-hdr-29.txt | |||||||||||||||||
| The IPv6 Compact Routing Header (CRH) | |||||||||||||||||
|
This document defines two new Routing header types. Collectively, they are called the Compact Routing Headers (CRH). Individually, they are called CRH-16 and CRH-32. | ||||||||||||||||
| draft-bonica-6man-vpn-dest-opt-19.txt | |||||||||||||||||
| The IPv6 Tunnel Payload Forwarding (TPF) Option | |||||||||||||||||
|
This document explains how IPv6 options can be used in IPv6 tunnels. It also defines the IPv6 Tunnel Payload Forwarding (TPF) option. | ||||||||||||||||
| draft-bonica-spring-srv6-end-dtm-08.txt | |||||||||||||||||
| SR-MPLS / SRv6 Transport Interworking | |||||||||||||||||
|
This document describes procedures for interworking between an SR- MPLS transit domain and an SRv6 transit domain. Each domain contains Provider Edge (PE) and Provider (P) routers. Area Border Routers (ABR) provide connectivity between domains. The procedures described in this document require the ABR to carry a route to each PE router. However, they do not required the ABR to carry service (i.e., customer) routes. In that respect, these procedures resemble L3VPN Interprovider Option C. Procedures described in this document support interworking for global IPv4 and IPv6 service prefixes. They do not support interworking for VPN services prefixes where the SR-MPLS domain uses MPLS service labels. | ||||||||||||||||
| draft-bonnell-rfc5019bis-02.txt | |||||||||||||||||
| Updates to Lightweight OCSP Profile for High Volume Environments | |||||||||||||||||
|
This document updates RFC 5019 to allow OCSP clients to use SHA-256. An RFC 5019 compliant OCSP client is still able to use SHA-1, but the use of SHA-1 may become obsolete in the future. | ||||||||||||||||
| draft-bookham-rtgwg-nfix-arch-06.txt | |||||||||||||||||
| An Architecture for Network Function Interconnect | |||||||||||||||||
|
The emergence of technologies such as 5G, the Internet of Things (IoT), and Industry 4.0, coupled with the move towards network function virtualization, means that the service requirements demanded from networks are changing. This document describes an architecture for a Network Function Interconnect (NFIX) that allows for interworking of physical and virtual network functions in a unified and scalable manner across wide-area network and data center domains while maintaining the ability to deliver against SLAs. | ||||||||||||||||
| draft-bormann-asdf-sdf-compact-03.txt | |||||||||||||||||
| Semantic Definition Format (SDF) for Data and Interactions of Things: Compact Notation | |||||||||||||||||
|
The Semantic Definition Format (SDF) is a format for domain experts to use in the creation and maintenance of data and interaction models in the Internet of Things. It was created as a common language for use in the development of the One Data Model liaison organization (OneDM) definitions. Tools convert this format to database formats and other serializations as needed. The SDF format is mainly intended for interchange between machine generation and machine processing. However, there is often a need for humans to look at and edit SDF models. Similar to the way Relax-NG as defined in ISO/IEC 19757-2 has an XML format and a compact format (Annex C), this specification defines a compact format to go along SDF's JSON format. The present version of this document is mostly a proof of concept, but was deemed useful to obtain initial feedback on the approach taken. | ||||||||||||||||
| draft-bormann-asdf-sdf-mapping-01.txt | |||||||||||||||||
| Semantic Definition Format (SDF): Mapping files | |||||||||||||||||
|
The Semantic Definition Format (SDF) is a format for domain experts to use in the creation and maintenance of data and interaction models in the Internet of Things. It was created as a common language for use in the development of the One Data Model liaison organization (OneDM) definitions. Tools convert this format to database formats and other serializations as needed. An SDF specification often needs to be augmented by additional information that is specific to its use in a particular ecosystem or application. SDF mapping files provide a mechanism to represent this augmentation. | ||||||||||||||||
| draft-bormann-asdf-sdftype-link-00.txt | |||||||||||||||||
| An sdfType for Links | |||||||||||||||||
|
This document defines and registers an sdfType "link" for the Semantic Definition Format (SDF) for Data and Interactions of Things (draft-ietf-asdf-sdf-12.txt). | ||||||||||||||||
| draft-bormann-cbor-cddl-2-draft-02.txt | |||||||||||||||||
| CDDL 2.0 -- 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. What specific documents spawn from the present one or whether this document is evolved into a single CDDL 2.0 specification. | ||||||||||||||||
| draft-bormann-cbor-cddl-csv-02.txt | |||||||||||||||||
| Using CDDL for CSVs | |||||||||||||||||
|
The Concise Data Definition Language (CDDL), standardized in RFC 8610, is defined to provide data models for data shaped like JSON or CBOR. Another representation format that is quote popular is the CSV (Comma-Separated Values) file as defined by RFC 4180. The present document shows a way how to use CDDL to provide a data model for CSV files. | ||||||||||||||||
| draft-bormann-cbor-cddl-freezer-11.txt | |||||||||||||||||
| A feature freezer for the Concise Data Definition Language (CDDL) | |||||||||||||||||
|
In defining the Concise Data Definition Language (CDDL), some features have turned up that would be nice to have. In the interest of completing this specification in a timely manner, the present document was started to collect nice-to-have features that did not make it into the first RFC for CDDL, RFC 8610, or the specifications exercising its extension points, such as RFC 9165. Significant parts of this draft have now moved over to the CDDL 2.0 project, described in draft-bormann-cbor-cddl-2-draft. The remaining items in this draft are not directly related to the CDDL 2.0 effort. | ||||||||||||||||
| draft-bormann-cbor-cddl-modules-00.txt | |||||||||||||||||
| CDDL Module Structure | |||||||||||||||||
|
At the time of writing, the Concise Data Definition Language (CDDL) is defined by RFC 8610 and RFC 9165. The latter has used the extension point provided in RFC 8610, the _control operator_. As CDDL is being used in larger projects, the need for corrections and additional features has 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 defines a backward- and forward-compatible way to add a module structure to CDDL. // Previous versions of the changes in this document were part of // draft-bormann-cbor-cddl-2-draft and previously draft-bormann-cbor- // cddl-freezer. This submission extracts out the functionality that // is ready for WG adoption and further WG work. | ||||||||||||||||
| draft-bormann-cbor-cddl-more-control-01.txt | |||||||||||||||||
| More Control Operators for CDDL | |||||||||||||||||
|
The Concise Data Definition Language (CDDL), standardized in RFC 8610, provides "control operators" as its main language extension point. RFCs have added to this extension point both in an application-specific and a more general way. The present document defines a number of additional generally application control operators for text conversion (Bytes, Integers, JSON), operations on text, and deterministic encoding. // Revision -01 of this draft reflects comments from initial // discussion of the specification in the CBOR working group. It is // intended to be ready for working group adoption. | ||||||||||||||||
| draft-bormann-cbor-draft-numbers-01.txt | |||||||||||||||||
| Managing CBOR numbers in Internet-Drafts | |||||||||||||||||
|
CBOR-based protocols often make use of numbers allocated in a registry. While developing 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. Such changes are very well possible in the future, at which time this draft will be updated. | ||||||||||||||||
| draft-bormann-cbor-edn-literals-02.txt | |||||||||||||||||
| Application-Oriented Literals in CBOR Extended Diagnostic Notation | |||||||||||||||||
|
The Concise Binary Object Representation, CBOR (RFC 8949), defines a "diagnostic notation" in order to be able to converse about CBOR data items without having to resort to binary data. This document specifies how to add application-oriented extensions to the diagnostic notation. It then defines two such extensions for the use of CBOR diagnostic notation with CoRAL and Constrained Resource Identifiers (draft-ietf-core-coral, draft-ietf-core-href). | ||||||||||||||||
| draft-bormann-cbor-rfc-cddl-models-01.txt | |||||||||||||||||
| CDDL models for some existing RFCs | |||||||||||||||||
|
A number of CBOR- and JSON-based protocols have been defined before CDDL was standardized or widely used. This short draft records some CDDL definitions for such protocols, which could become part of a library of CDDL definitions available for use in CDDL2 processors. It focuses on CDDL in (almost) published IETF RFCs. | ||||||||||||||||
| draft-bormann-cbor-update-8610-grammar-00.txt | |||||||||||||||||
| Updates to the CDDL grammar of RFC 8610 | |||||||||||||||||
|
At the time of writing, the Concise Data Definition Language (CDDL) is defined by RFC 8610 and RFC 9165. The latter has used the extension point provided in RFC 8610, the _control operator_. As CDDL is being used in larger projects, the need for corrections and additional features has 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 updates errata and makes other small fixes for the ABNF grammar defined for CDDL in RFC 8610. // Previous versions of the changes in this document were part of // draft-bormann-cbor-cddl-2-draft and previously draft-bormann-cbor- // cddl-freezer. This submission extracts out those grammar changes // that are ready for WG adoption and publication. | ||||||||||||||||
| draft-bormann-t2trg-deref-id-00.txt | |||||||||||||||||
| The "dereferenceable identifier" pattern | |||||||||||||||||
|
In a protocol or an application environment, it is often important to be able to create unambiguous identifiers for some meaning (concept or some entity). Due to the simplicity of creating URIs, these have become popular for this purpose. Beyond the purpose of identifiers to be uniquely associated with a meaning, some of these URIs are in principle _dereferenceable_, so something can be placed that can be retrieved when encountering such a URI. The present -00 version is a stub to draw some attention to the opportunity that this pattern would benefit from a common description, documenting its benefits and pitfalls, and some mitigations for the latter. | ||||||||||||||||
| draft-boro-opsawg-ntw-attachment-circuit-02.txt | |||||||||||||||||
| A Network YANG Data Model for Attachment Circuits | |||||||||||||||||
|
This document specifies a network model for attachment circuits. The model can be used for the provisioning of attachment circuits prior or during service provisioning (e.g., Network Slice Service). A companion service model is specified in [I-D.boro-opsawg-teas-attachment-circuit]. The module augments the Service Attachment Point (SAP) model with the detailed information for the provisioning of attachment circuits in Provider Edges (PEs). | ||||||||||||||||
| draft-boro-opsawg-teas-attachment-circuit-05.txt | |||||||||||||||||
| YANG Data Models for 'Attachment Circuits'-as-a-Service (ACaaS) | |||||||||||||||||
|
This document specifies a YANG service data model for Attachment Circuits (ACs). This model can be used for the provisioning of ACs prior or during service provisioning (e.g., Network Slice Service). The document specifies also a module that updates other service and network modules with the required information to bind specific services to ACs that are created using the AC service model. Also, the document specifies a set of reusable groupings. Whether a service model reuses structures defined in the AC models or simply include an AC reference is a design choice of these service models. Relying upon the AC service model to manage ACs over which a service is delivered has the merit to decorrelate the management of a service vs. upgrade the AC components to reflect recent AC technologies or features. | ||||||||||||||||
| draft-boro-opsawg-teas-common-ac-01.txt | |||||||||||||||||
| A Common YANG Data Model for Attachment Circuits | |||||||||||||||||
|
The document specifies a common Attachment Circuits (ACs) YANG module, which is designed with the intent to be reusable by other models. For example, this common model can be reused by service models to expose ACs as a service, service models that require binding a service to a set of ACs, network and device models to provision ACs, etc. | ||||||||||||||||
| draft-boucadair-add-deployment-considerations-02.txt | |||||||||||||||||
| Discovery of Encrypted DNS Resolvers: Deployment Considerations | |||||||||||||||||
|
The document discusses some deployment considerations of the various options to discover encrypted DNS resolvers (e.g., DNS-over-HTTPS, DNS-over-TLS, or DNS-over-QUIC). In particular, the document describes how Discovery of Network-designated Resolvers (DNR) and Discovery of Designated Resolvers (DDR) can be used in typical deployment contexts. This document does not intend to provide deployment recommendations, but is meant to exemplify how operators can enable the encrypted DNS discovery mechanisms. In addition, the document illustrates the feasibility of hosting encrypted DNS forwarders in Customer Premises Equipment (CPEs). | ||||||||||||||||
| draft-boucadair-lisp-pubsub-flow-examples-03.txt | |||||||||||||||||
| LISP PubSub Flow Examples | |||||||||||||||||
|
This document provides a set of flow examples to illustrate the use of LISP PubSub specification. Discussion Venues This note is to be removed before publishing as an RFC. Discussion of this document takes place on the Locator/ID Separation Protocol Working Group mailing list (lisp@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/lisp/. Source for this draft and an issue tracker can be found at https://github.com/boucadair/lisp-pubsub-flow-examples. | ||||||||||||||||
| draft-boucadair-netmod-iana-registries-07.txt | |||||||||||||||||
| Recommendations for Creating IANA-Maintained YANG Modules | |||||||||||||||||
|
This document provides a set of guidelines for YANG module authors related to the design of IANA-maintained modules. These guidelines are meant to leverage existing IANA registries and use YANG as another format to present the content of these registries when appropriate. This document updates RFC 8407 by providing additional guidelines for IANA-maintained modules. Also, this document updates RFC 8126 by providing additional guidelines for writing the IANA considerations for RFCs that specify IANA-maintained modules. This document does not change anything written in RFC 8407 and RFC 8126. | ||||||||||||||||
| draft-boucadair-opsawg-ipfix-tcpo-v6eh-01.txt | |||||||||||||||||
| Extended TCP Options and IPv6 Extension Headers IPFIX Information Elements | |||||||||||||||||
|
This document specifies new IPFIX Information Elements (IEs) to solve some issues with existing ipv6ExtensionHeaders and tcpOptions IPFIX IEs, especially the ability to export any observed IPv6 Extension Headers or TCP options. | ||||||||||||||||
| draft-boucadair-opsawg-tsvwg-udp-ipfix-04.txt | |||||||||||||||||
| Export of UDP Options Information in IP Flow Information Export (IPFIX) | |||||||||||||||||
|
This document specifies new IP Flow Information Export (IPFIX) Information Elements for UDP options. Discussion Venues This note is to be removed before publishing as an RFC. Discussion of this document takes place on the Operations and Management Area Working Group Working Group mailing list (opsawg@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/opsawg/. Source for this draft and an issue tracker can be found at https://github.com/boucadair/udp-ipfix. | ||||||||||||||||
| draft-boucadair-tcpm-rst-diagnostic-payload-06.txt | |||||||||||||||||
| TCP RST Diagnostic Payload | |||||||||||||||||
|
This document specifies a diagnostic payload format to be returned in TCP RST segments. Such payloads are used to share with the endpoints the reasons for which a TCP connection has been reset. This is meant to ease diagnostic and troubleshooting. | ||||||||||||||||
| draft-boucla-opsawg-ipfix-fixes-04.txt | |||||||||||||||||
| Simple Fixes to the IP Flow Information Export (IPFIX) IANA Registry | |||||||||||||||||
|
This document describes simple fixes to the IANA IP Flow Information Export (IPFIX) registry. These fixes are mainly updates to point to newer IANA registries and also updates to the description of some Information Elements (IEs). | ||||||||||||||||
| draft-bourbaki-6man-classless-ipv6-08.txt | |||||||||||||||||
| IPv6 is Classless | |||||||||||||||||
|
Over the history of IPv6, various classful address models have been proposed, none of which has withstood the test of time. The last remnant of IPv6 classful addressing is a rigid network interface identifier boundary at /64. This document removes the fixed position of that boundary for interface addressing. | ||||||||||||||||
| draft-boutros-bess-elan-services-over-sr-04.txt | |||||||||||||||||
| A Simplified Scalable ELAN Service Model with Segment Routing Underlay | |||||||||||||||||
|
This document proposes a new approach for realizing Ethernet LAN (ELAN) services with an objective of leveraging Segment Routing Control plane to achieve high scalability, faster network convergence, and reduced operational complexity. Furthermore, it naturally brings the benefits of All-Active multihoming as well as MAC learning in data-plane. | ||||||||||||||||
| draft-bradshaw-envelope-validation-extension-dkim-01.txt | |||||||||||||||||
| DKIM Envelope Validation Extension (eve) | |||||||||||||||||
|
DKIM as defined in RFC6376 is an IETF standard of cryptographically signing email with a domain key. DKIM is widely used to build a reputation based on the signing domain and assign that reputation to message filtering. Section 8.6 defines a vulnerability called DKIM replay, in which a single message can be replayed to a large group of unrelated recipients, thereby hijacking the reputation of the original sender. This proposal defines a method of declaring the original envelope sender and recipient(s) within a DKIM signature such that compliant DKIM validators can detect a DKIM signature which may have been replayed and modify their use of domain reputation accordingly. This technique remains fully backwards compatible with DKIM validators which do not support the new methods, while allowing compliant forwarders to declare their ingress authentication state in Authentication Results headers for consumption by subsequent validators. | ||||||||||||||||
| draft-brand-indicators-for-message-identification-03.txt | |||||||||||||||||
| Brand Indicators for Message Identification (BIMI) | |||||||||||||||||
|
Brand Indicators for Message Identification (BIMI) permits Domain Owners to coordinate with Mail User Agents (MUAs) to display brand- specific Indicators next to properly authenticated messages. There are two aspects of BIMI coordination: a scalable mechanism for Domain Owners to publish their desired Indicators, and a mechanism for Mail Transfer Agents (MTAs) to verify the authenticity of the Indicator. This document specifies how Domain Owners communicate their desired Indicators through the BIMI Assertion Record in DNS and how that record is to be interpreted by MTAs and MUAs. MUAs and mail- receiving organizations are free to define their own policies for making use of BIMI data and for Indicator display as they see fit. | ||||||||||||||||
| draft-briscoe-docsis-q-protection-06.txt | |||||||||||||||||
| The DOCSIS(r) Queue Protection Algorithm to Preserve Low Latency | |||||||||||||||||
|
This informational document explains the specification of the queue protection algorithm used in DOCSIS technology since version 3.1. A shared low latency queue relies on the non-queue-building behaviour of every traffic flow using it. However, some flows might not take such care, either accidentally or maliciously. If a queue is about to exceed a threshold level of delay, the queue protection algorithm can rapidly detect the flows most likely to be responsible. It can then prevent harm to other traffic in the low latency queue by ejecting selected packets (or all packets) of these flows. The document is designed for four types of audience: a) congestion control designers who need to understand how to keep on the 'good' side of the algorithm; b) implementers of the algorithm who want to understand it in more depth; c) designers of algorithms with similar goals, perhaps for non-DOCSIS scenarios; and d) researchers interested in evaluating the algorithm. | ||||||||||||||||
| draft-briscoe-iccrg-prague-congestion-control-02.txt | |||||||||||||||||
| Prague Congestion Control | |||||||||||||||||
|
This specification defines the Prague congestion control scheme, which is derived from DCTCP and adapted for Internet traffic by implementing the Prague L4S requirements. Over paths with L4S support at the bottleneck, it adapts the DCTCP mechanisms to achieve consistently low latency and full throughput. It is defined independently of any particular transport protocol or operating system, but notes are added that highlight issues specific to certain transports and OSs. It is mainly based on experience with the reference Linux implementation of TCP Prague and the Apple implementation over QUIC, but it includes experience from other implementations where available. The implementation does not satisfy all the Prague requirements (yet) and the IETF might decide that certain requirements need to be relaxed as an outcome of the process of trying to satisfy them all. Future plans that have typically only been implemented as proof-of- concept code are outlined in a separate section. | ||||||||||||||||
| draft-brotman-ietf-bimi-guidance-07.txt | |||||||||||||||||
| General Guidance for Implementing Branded Indicators for Message Identification (BIMI) | |||||||||||||||||
|
This document is meant to provide guidance to various entities so that they may implement Brand Indicators for Message Identification (BIMI). This document is a companion to various other BIMI drafts, which should first be consulted. | ||||||||||||||||
| draft-buraglio-v6ops-ula-use-cases-01.txt | |||||||||||||||||
| IPv6 Unique Local Addressing Deployment Details and Operational Use Cases | |||||||||||||||||
|
Use of unique local addressing (ULA) as an addressing practice brings with it distinctive and specialized use cases that may be counter to more widely deployed use cases using Global Unicast Addressing (GUA) in some operational scenarios. | ||||||||||||||||
| draft-burdet-bess-evpn-fast-reroute-05.txt | |||||||||||||||||
| EVPN Fast Reroute | |||||||||||||||||
|
This document summarises EVPN convergence mechanisms and specifies procedures for EVPN networks to achieve fast and scale-independent convergence. | ||||||||||||||||
| draft-burgin-jenkins-identity-chaining-00.txt | |||||||||||||||||
| OAuth Identity Chaining | |||||||||||||||||
|
This specification defines a new OAuth claim that allows a proxying OAuth client to pass identity information for a different OAuth client to an OAuth authorization server during a token request. The authorization server uses this additional identity information when populating the "client_id" and "cnf" fields of the returned access token instead of the identity information about the proxying client requesting the token. | ||||||||||||||||
| draft-busi-teas-te-topology-profiles-05.txt | |||||||||||||||||
| Profiles for Traffic Engineering (TE) Topology Data Model and Applicability to non-TE Use Cases | |||||||||||||||||
|
This document describes how profiles of the Traffic Engineering (TE) Topology Model, defined in RFC8795, can be used to address applications beyond "Traffic Engineering". | ||||||||||||||||
| draft-busizheng-teas-yang-te-mpls-topology-04.txt | |||||||||||||||||
| A YANG Data Model for MPLS-TE Topology | |||||||||||||||||
|
This document describes a YANG data model for Multi-Protocol Label Switching (MPLS) with Traffic Engineering (MPLS-TE) networks. | ||||||||||||||||
| draft-campling-ech-deployment-considerations-05.txt | |||||||||||||||||
| Encrypted Client Hello Deployment Considerations | |||||||||||||||||
|
(Editorial note: to be updated as the text in the main body of the document is finalised) This document is intended to inform the community about the impact of the deployment of the proposed Encrypted Client Hello (ECH) standard that encrypts Server Name Indication (SNI) and other data. Data encapsulated by ECH (ie data included in the encrypted ClientHelloInner) is of legitimate interest to on-path security actors including those providing inline malware detection, parental controls, content filtering to prevent access to malware and other risky traffic, mandatory security controls etc. The document includes observations on current use cases for SNI data in a variety of contexts. It highlights how the use of that data is important to the operators of both public and private networks and shows how the loss of access to SNI data will cause difficulties in the provision of a range of services to end-users, including the potential weakening of cybersecurity defences. Some mitigations are identified that may be useful for inclusion by those considering the adoption of support for ECH in their software. | ||||||||||||||||
| draft-celi-irtf-hrpc-ipvc-00.txt | |||||||||||||||||
| Intimate Partner Violence Digital Considerations | |||||||||||||||||
|
This document aims to inform how Internet protocols and their implementations might better mitigate technical attacks at the user endpoint by describing technology-based practices to perpetrate intimate partner violence (IPV). IPV is a pervasive reality that is not limited to, but can be exacerbated with, the usage of technology. The IPV context enables the attacker to access one, some or all of: devices, local networks, authentication mechanisms, identity information, and accounts. These kinds of technical compromise exist in addition to on-path attacks, both active and passive [RFC7624]. In this document we describe the tactics the IPV attacker uses and what kind of counter-measures can be designed in IETF protocols. | ||||||||||||||||
| draft-cfrg-schwabe-kyber-02.txt | |||||||||||||||||
| Kyber Post-Quantum KEM | |||||||||||||||||
|
This memo specifies a preliminary version ("draft00", "v3.02") of Kyber, an IND-CCA2 secure Key Encapsulation Method. About This Document This note is to be removed before publishing as an RFC. The latest revision of this draft can be found at https://bwesterb.github.io/draft-schwabe-cfrg-kyber/draft-cfrg- schwabe-kyber.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-cfrg-schwabe-kyber/. Source for this draft and an issue tracker can be found at https://github.com/bwesterb/draft-schwabe-cfrg-kyber. | ||||||||||||||||
| draft-chan-lsr-igp-adv-offset-02.txt | |||||||||||||||||
| IGP extensions for Advertising Offset for Flex-Algorithm | |||||||||||||||||
|
This document describes the IGP extensions to provide predictable Adjacency-SIDs per Flex-Algorithm [FLEXALGO] in segment routing. We propose some methods to allow the advertisement of additional TLV in IGP so that the Flex-Algorithm specific Adjacency-SIDs could be automatically derived. With the proposed method, the size of advertisement on per node per link basis is greatly reduced. Each participating router would derive the required labels automatically. Extensions for offset to derive Flex-Algorithm Prefix-SID is also included in the document. | ||||||||||||||||
| draft-chan-tsvwg-eipf-cgnat-02.txt | |||||||||||||||||
| Enhanced Port Forwarding functions with CGNAT | |||||||||||||||||
|
There is a need for peer-to-peer (P2P) communication under the use of CGNAT in service providers. With the combination of home gateway, this becomes NAT444. In RFC5128, methods of using UDP hole punching solves the problem partially when EIM (Endpoint-Independent Mapping) is supported in NAT device in the path, and there exists a common rendezvous server. The success rate of UDP hole punching is high, but not TCP hole punching in practical world. Also, the P2P solution requires a common server in the public internet to exchange the IP and port information. In this draft, a method is described to achieve incoming TCP or UDP session without a common rendezvous server in NAT444 situation. | ||||||||||||||||
| draft-chariton-ipcaa-00.txt | |||||||||||||||||
| DNS CAA Resource Record Property for IP Address Certificates | |||||||||||||||||
|
This document specifies a new DNS CAA Resource Record Property that allows an IP Address holder to specify one or more Certification Authorities (CAs) authorized to issue certificates for that IP Address. | ||||||||||||||||
| draft-chen-ati-adaptive-ipv4-address-space-12.txt | |||||||||||||||||
| Adaptive IPv4 Address Space | |||||||||||||||||
|
This document describes a solution to the Internet address depletion issue through the use of an existing Option mechanism that is part of the original IPv4 protocol. This proposal, named EzIP (phonetic for Easy IPv4), outlines the IPv4 public address pool expansion and the Internet system architecture enhancement considerations. EzIP may expand an IPv4 address by a factor of 256M without affecting the existing IPv4 based Internet, or the current private networks. It is in full conformance with the IPv4 protocol, and supports not only both direct and private network connectivity, but also their interoperability. EzIP deployments may coexist with existing Internet traffic and IoTs (Internet of Things) operations without perturbing their setups, while offering end-users the freedom to indepdently choose which service. EzIP may be implemented as a software or firmware enhancement to Internet edge routers or private network routing gateways, wherever needed, or simply installed as an inline adjunct hardware module between the two, enabling a seamless introduction. The 256M case detailed here establishes a complete spherical layer of an overlay of routers for interfacing between the Internet fabic (core plus edge routers) and the end user premises or IoTs. Incorporating caching proxy technology in the gateway, a fairly large geographical region may enjoy address expansion based on as few as one ordinary IPv4 public address utilizing IP packets with degenerated EzIP header. If IPv4 public pool allocations were reorganized, the assignable pool could be multiplied 512M fold or even more. Enabling hierarchical address architecture which facilitates both hierarchical and mesh routing, EzIP can provide nearly the same order of magnitude of address pool resources as IPv6 while streamlining the administrative aspects of it. The basic EzIP will immediately resolve the local IPv4 address shortage, while being transparent to the rest of the Internet as a new parallel facility. Under the Dual-Stack environment, these proposed interim facilities will relieve the IPv4 address shortage issue, while affording IPv6 more time to reach maturity for providing the availability levels required for delivering a long-term general service. The basic EzIP may be deployed in two distinctive phases. First, replace the 100.64/10 netblock of RFC6598 with 240/4 netblock to enhance the CG- NAT operation. Second, make use of the Option Word mechanism in the IP header to enable the end-to-end connectivity. | ||||||||||||||||
| draft-chen-bier-egress-protect-04.txt | |||||||||||||||||
| BIER Egress Protection | |||||||||||||||||
|
This document describes a mechanism for fast protection against the failure of an egress node of a "Bit Index Explicit Replication" (BIER) domain. It is called BIER egress protection. It does not require any per-flow state in the core of the domain. With BIER egress protection the failure of a primary BFER (Bit Forwarding Egress Router) is protected with a backup BFER such that traffic destined to the primary BFER in the BIER domain is fast rerouted by a neighbor BFR to the backup BFER on the BIER layer. The mechanism is applicable if all BIER traffic sent to the primary BFER can reach its destination also via the backup BFER. It is complementary to BIER- FRR which cannot protect against the failure of a BFER. | ||||||||||||||||
| draft-chen-bier-idr-bier-te-bgp-00.txt | |||||||||||||||||
| BGP extensions for BIER-TE | |||||||||||||||||
|
Bit Index Explicit Replication (BIER)-TE shares architecture and packet formats with BIER as described in [RFC8279]. BIER-TE forwards and replicates packets based on a BitString in the packet header, but every BitPosition of the BitString of a BIER-TE packet indicates one or more adjacencies as described in [I-D.ietf-bier-te-arch]. This document describes BGP extensions for advertising the BIER-TE specific information. | ||||||||||||||||
| draft-chen-bier-te-egress-protect-04.txt | |||||||||||||||||
| BIER-TE Egress Protection | |||||||||||||||||
|
This document describes a mechanism for fast protection against the failure of an egress node of an explicit point to multipoint (P2MP) multicast path/tree in a "Bit Index Explicit Replication" (BIER) Traffic Engineering (TE) domain. It does not have any per-flow state in the core of the domain. For a multicast packet to the egress node, when the egress node fails, its upstream hop as a PLR sends the packet to the egress' backup node once the PLR detects the failure. | ||||||||||||||||
| draft-chen-bier-te-enc-02.txt | |||||||||||||||||
| BIER-TE Encapsulation with Multiple BitStrings | |||||||||||||||||
|
This document describes a "Bit Index Explicit Replication Traffic Engineering" (BIER-TE) header, two levels of Bit Index Forwarding Tables (BIFTs) and a forwarding procedure for efficiently processing BIER-TE packets with the header. For a multicast packet with an explicit point-to-multipoint (P2MP) path, which has multiple BitStrings, the packet with the header containing the BitStrings is replicated and forwarded statelessly along the path. | ||||||||||||||||
| draft-chen-bier-te-frr-04.txt | |||||||||||||||||
| BIER-TE Fast ReRoute | |||||||||||||||||
|
This document describes a mechanism for fast re-route (FRR) protection against the failure of a transit node or link on an explicit point to multipoint (P2MP) multicast path/tree in a "Bit Index Explicit Replication" (BIER) Traffic Engineering (TE) domain. It does not have any per-path state in the core. For a multicast packet to traverse a transit node along an explicit P2MP path, when the node fails, its upstream hop node as a PLR reroutes the packet around the failed node along the P2MP path once it detects the failure. | ||||||||||||||||
| draft-chen-bier-te-lan-06.txt | |||||||||||||||||
| BIER-TE for Broadcast Link | |||||||||||||||||
|
This document describes extensions to "Bit Index Explicit Replication Traffic Engineering" (BIER-TE) for supporting LANs (i.e., broadcast links). For a multicast packet with an explicit point-to-multipoint (P2MP) path traversing LANs, the packet is replicated and forwarded statelessly along the path. | ||||||||||||||||
| draft-chen-bier-te-ospf-04.txt | |||||||||||||||||
| OSPF Extensions for BIER-TE | |||||||||||||||||
|
This document describes OSPF extensions for distributing BitPositions configured on the links in "Bit Index Explicit Replication Traffic Engineering" (BIER-TE) domain. | ||||||||||||||||
| draft-chen-detnet-sr-based-bounded-latency-02.txt | |||||||||||||||||
| Segment Routing (SR) Based Bounded Latency | |||||||||||||||||
|
One of the goals of DetNet is to provide bounded end-to-end latency for critical flows. This document defines how to leverage Segment Routing (SR) to implement bounded latency. Specifically, the SR Identifier (SID) is used to specify transmission time (cycles) of a packet. When forwarding devices along the path follow the instructions carried in the packet, the bounded latency is achieved. This is called Cycle Specified Queuing and Forwarding (CSQF) in this document. Since SR is a source routing technology, no per-flow state is maintained at intermediate and egress nodes, SR-based CSQF naturally supports flow aggregation that is deemed to be a key capability to allow DetNet to scale to large networks. | ||||||||||||||||
| draft-chen-emu-eap-tls-ibs-05.txt | |||||||||||||||||
| Use Identity as Raw Public Key in EAP-TLS | |||||||||||||||||
|
This document specifies the use of identity as a raw public key in EAP-TLS, the procedure of EAP-TIBS is consistent with EAP-TLS's interactive process, identity-based signature is extended to support EAP-TLS's signature algorithms to avoid X.509 certificates, this authentication method can avoid the overhead of receiving and processing certificate chains. | ||||||||||||||||
| draft-chen-idr-bgp-ls-algo-related-adjacency-sid-01.txt | |||||||||||||||||
| Algorithm Related Adjacency SID Advertisement | |||||||||||||||||
|
This draft updates [RFC9085] to defines extensions to the Border Gateway Protocol-Link State (BGP-LS) address family in order to carry algorithm Related Adjacency SID. | ||||||||||||||||
| draft-chen-idr-bgp-ls-security-capability-00.txt | |||||||||||||||||
| the extensions of BGP-LS to carry security capabilities | |||||||||||||||||
|
The goal is to collect the security capabilities of nodes, which will be one of the factors to form the routing topology, and use the routing programming capabilities to form a secure routing path. The BGP-LS protocol is extended to carry the security capabilities of the node. The controller collects topology information, forms a topology path with security capabilities according to security requirements, and supports SRv6 path sending to execute node forwarding through programming. | ||||||||||||||||
| draft-chen-idr-bgp-ls-sr-policy-nrp-02.txt | |||||||||||||||||
| SR Policies Extensions for NRP in BGP-LS | |||||||||||||||||
|
This document defines a new TLV which enable the headed to report the configuration and the states of SR policies carrying NRP information by using BGP-LS. | ||||||||||||||||
| draft-chen-idr-ctr-availability-06.txt | |||||||||||||||||
| BGP for Network High Availability | |||||||||||||||||
|
This document describes protocol extensions to BGP for improving the reliability or availability of a network controlled by a controller cluster. | ||||||||||||||||
| draft-chen-idr-mbinding-01.txt | |||||||||||||||||
| BGP for Mirror Binding | |||||||||||||||||
|
BGP is used to distribute a binding to a node. The binding includes a binding SID and a path represented by a list of SIDs. This document describes extensions to BGP for distributing the information about the binding to a protecting node. For an SR path via the node with the binding SID, when the node fails, the protecting node such as the upstream neighbor on the path uses the information to protect the binding SID of the failed node. | ||||||||||||||||
| draft-chen-idr-sr-ingress-protection-08.txt | |||||||||||||||||
| SR Path Ingress Protection | |||||||||||||||||
|
This document describes extensions to Border Gateway Protocol (BGP) for protecting the ingress node of a Segment Routing (SR) tunnel or path. | ||||||||||||||||
| draft-chen-idr-tcp-user-timeout-01.txt | |||||||||||||||||
| Applying TCP User Timeout Parameter to BGP Sessions | |||||||||||||||||
|
In this document we discuss the TCP "User Timeout" parameter and recommend using it to handle stuck BGP sessions. | ||||||||||||||||
| draft-chen-isis-ias-lk-10.txt | |||||||||||||||||
| ISIS Extensions for Broadcast Inter-AS TE Link | |||||||||||||||||
|
This document presents extensions to the ISIS protocol for advertising broadcast inter-AS Traffic Engineering (TE) links. | ||||||||||||||||
| draft-chen-lsr-adv-lkno-01.txt | |||||||||||||||||
| IGP Extensions for Advertising Link Numbers | |||||||||||||||||
|
This document describes OSPF and IS-IS extensions for distributing the link numbers assigned to the links originating at a node. | ||||||||||||||||
| draft-chen-lsr-adv-ni-01.txt | |||||||||||||||||
| IGP Extensions for Advertising Node Index | |||||||||||||||||
|
This document describes OSPF and IS-IS extensions for distributing the node index configured on a node. | ||||||||||||||||
| draft-chen-lsr-ctr-availability-06.txt | |||||||||||||||||
| IGP for Network High Availability | |||||||||||||||||
|
This document describes protocol extensions to OSPF and IS-IS for improving the reliability or availability of a network controlled by a controller cluster. | ||||||||||||||||
| draft-chen-lsr-isis-big-tlv-00.txt | |||||||||||||||||
| IS-IS Extension for Big TLV | |||||||||||||||||
|
The IS-IS routing protocol uses TLV (Type-Length-Value) encoding in a variety of protocol messages. The original IS-IS TLV definition allows for 255 octets of value in maximum. This document proposes a backward compatible IS-IS extension for encoding the TLV whose value is bigger than 255 octets. | ||||||||||||||||
| draft-chen-lsvr-flood-reduction-04.txt | |||||||||||||||||
| BGP-SPF Flooding Reduction | |||||||||||||||||
|
This document describes extensions to Border Gateway Protocol (BGP) for flooding the link states on a topology that is a subgraph of the complete topology of a BGP-SPF domain, so that the amount of flooding traffic in the domain is greatly reduced. This would reduce convergence time with a more stable and optimized routing environment. | ||||||||||||||||
| draft-chen-nmrg-dtn-interface-01.txt | |||||||||||||||||
| Requirements for Interfaces of Network Digital Twin | |||||||||||||||||
|
The interfaces of Digital Twin Network can be divided as twin network southbound interface, internal interface and northbound interface. In order to build a digital twin network and realize its many advantages, different interfaces should be able to meet different requirements. And this memo introduces the requirements for the interfaces of the Digital Twin Network. | ||||||||||||||||
| draft-chen-nmrg-ibn-management-00.txt | |||||||||||||||||
| Network Management Intent -One of IBN Use Cases | |||||||||||||||||
|
Full life cycle network management will be a key feature of the future communication networks. Meanwhile, the complexity of the network management should be reduced and the network expects to be managed in a fully automated manner with humans out of the loop. In this document, we propose an use case of intent based network management to achieve more flexible , convenient, and efficient network management. In this use case, we propose an architecture and attempt to illustrate the five levels of achieving full autonomous network management. | ||||||||||||||||
| draft-chen-ospf-abnormal-state-info-09.txt | |||||||||||||||||
| OSPF Abnormal State Information | |||||||||||||||||
|
This document describes a couple of options for an OSPF router to advertise its abnormal state information in a routing domain. | ||||||||||||||||
| draft-chen-ospf-ias-lk-10.txt | |||||||||||||||||
| OSPF Extensions for Broadcast Inter-AS TE Link | |||||||||||||||||
|
This document presents extensions to the Open Shortest Path First (OSPF) for advertising broadcast inter-AS Traffic Engineering (TE) links. | ||||||||||||||||
| draft-chen-pce-bier-10.txt | |||||||||||||||||
| PCEP Extensions for BIER-TE | |||||||||||||||||
|
Bit Index Explicit Replication (BIER)-TE shares architecture and packet formats with BIER as described in [RFC8279]. BIER-TE forwards and replicates packets based on a BitString in the packet header, but every BitPosition of the BitString of a BIER-TE packet indicates one or more adjacencies as described in [RFC9262]. BIER-TE Path can be derived from a Path Computation Element (PCE). This document specifies extensions to the Path Computation Element Protocol (PCEP) that allow a PCE to compute and initiate the path for the BIER-TE. | ||||||||||||||||
| draft-chen-pce-bier-te-path-05.txt | |||||||||||||||||
| PCE for BIER-TE Path | |||||||||||||||||
|
This document describes extensions to Path Computation Element (PCE) communication Protocol (PCEP) for supporting Bit Index Explicit Replication (BIER) Traffic Engineering (TE) paths. | ||||||||||||||||
| draft-chen-pce-compute-backup-egress-21.txt | |||||||||||||||||
| Extensions to the Path Computation Element Communication Protocol (PCEP) for Backup Egress of a Traffic Engineering Label Switched Path | |||||||||||||||||
|
This document presents extensions to the Path Computation Element Communication Protocol (PCEP) for a PCC to send a request for computing a backup egress for an MPLS TE P2MP LSP or an MPLS TE P2P LSP to a PCE and for a PCE to compute the backup egress and reply to the PCC with a computation result for the backup egress. | ||||||||||||||||
| draft-chen-pce-compute-backup-ingress-21.txt | |||||||||||||||||
| Extensions to Path Computation Element Communication Protocol (PCEP) for Backup Ingress of a Traffic Engineering Label Switched Path | |||||||||||||||||
|
This document presents extensions to the Path Computation Element Communication Protocol (PCEP) for a PCC to send a request for computing a backup ingress for an MPLS TE P2MP LSP or an MPLS TE P2P LSP to a PCE and for a PCE to compute the backup ingress and reply to the PCC with a computation result for the backup ingress. | ||||||||||||||||
| draft-chen-pce-controller-bier-te-04.txt | |||||||||||||||||
| PCEP Procedures and Protocol Extensions for Using PCE as a Central Controller (PCECC) of BIER-TE | |||||||||||||||||
|
This draft specify extensions to PCEP protocol when a PCE-based controller is responsible for allocates the BIER-TE information(BIER subdomain-id, adjacencies BitPosition(s), and Adjacency Types etc), then PCC generate a "Bit Index Forwarding Table"(BIFT). | ||||||||||||||||
| draft-chen-pce-ctr-availability-06.txt | |||||||||||||||||
| PCE for Network High Availability | |||||||||||||||||
|
This document describes extensions to Path Computation Element (PCE) communication Protocol (PCEP) for improving the reliability or availability of a network controlled by a controller cluster. | ||||||||||||||||
| draft-chen-pce-forward-search-p2mp-path-23.txt | |||||||||||||||||
| A Forward-Search P2MP TE LSP Inter-Domain Path Computation | |||||||||||||||||
|
This document presents a forward search procedure for computing a path for a Point-to-MultiPoint (P2MP) Traffic Engineering (TE) Label Switched Path (LSP) crossing a number of domains through using multiple Path Computation Elements (PCEs). In addition, extensions to the Path Computation Element Communication Protocol (PCEP) for supporting the forward search procedure are described. | ||||||||||||||||
| draft-chen-pce-forward-search-p2p-path-computation-24.txt | |||||||||||||||||
| A Forward-Search P2P TE LSP Inter-Domain Path Computation | |||||||||||||||||
|
This document presents a forward search procedure for computing paths for Point-to-Point (P2P) Traffic Engineering (TE) Label Switched Paths (LSPs) crossing a number of domains using multiple Path Computation Elements (PCEs). In addition, extensions to the Path Computation Element Communication Protocol (PCEP) for supporting the forward search procedure are described. | ||||||||||||||||
| draft-chen-pce-h-connect-access-12.txt | |||||||||||||||||
| PCEP Link State Abstraction | |||||||||||||||||
|
This document presents extensions to the Path Computation Element Communication Protocol (PCEP) for a child PCE to abstract its domain information to its parent for supporting a hierarchical PCE system. | ||||||||||||||||
| draft-chen-pce-h-discovery-12.txt | |||||||||||||||||
| Hierarchical PCE Determination | |||||||||||||||||
|
This document presents extensions to the Path Computation Element Communication Protocol (PCEP) for determining parent child relations and exchanging the information between a parent and a child PCE in a hierarchical PCE system. | ||||||||||||||||
| draft-chen-pce-label-x-domains-16.txt | |||||||||||||||||
| Extensions to PCEP for Distributing Label Cross Domains | |||||||||||||||||
|
This document specifies extensions to PCEP for distributing labels crossing domains for an inter-domain Point-to-Point (P2P) or Point- to-Multipoint (P2MP) Traffic Engineering (TE) Label Switched Path (LSP). | ||||||||||||||||
| draft-chen-pce-mbinding-01.txt | |||||||||||||||||
| PCE for Mirror Binding | |||||||||||||||||
|
PCE is used to distribute a binding to a node. The binding includes a binding SID and a path represented by a list of SIDs. This document describes extensions to PCEP for distributing the information about the binding to a protecting node. For an SR path via the node with the binding SID, when the node fails, the protecting node such as the upstream neighbor on the path uses the information to protect the binding SID of the failed node. | ||||||||||||||||
| draft-chen-pce-pcc-ted-12.txt | |||||||||||||||||
| Static PCEP Link State | |||||||||||||||||
|
This document presents extensions to the Path Computation Element Communication Protocol (PCEP) for a PCC to advertise the information about the links without running IGP and for a PCE to build a TED based on the information received. | ||||||||||||||||
| draft-chen-pce-pce-initiated-ip-tunnel-02.txt | |||||||||||||||||
| PCE-initiated IP Tunnel | |||||||||||||||||
|
This document specifies a set of extensions to PCEP to support PCE- initiated IP Tunnel to satisfy the requirement which is introduced in [I-D.li-spring-tunnel-segment]. The extensions include the setup, maintenance and teardown of PCE-initiated IP Tunnels, without the need for local configuration on the PCC. | ||||||||||||||||
| draft-chen-pce-pcep-extension-pce-controller-bier-04.txt | |||||||||||||||||
| PCEP Procedures and Protocol Extensions for Using PCE as a Central Controller (PCECC) of BIER | |||||||||||||||||
|
This draft specify a new mechanism where PCE allocates the BIER information centrally and uses PCEP to distribute them to all nodes, then PCC generate a "Bit Index Forwarding Table"(BIFT). | ||||||||||||||||
| draft-chen-pce-protection-applicability-20.txt | |||||||||||||||||
| The Applicability of the PCE to Computing Protection and Recovery Paths for Single Domain and Multi-Domain Networks. | |||||||||||||||||
|
The Path Computation Element (PCE) provides path computation functions in support of traffic engineering in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. A link or node failure can significantly impact network services in large-scale networks. Therefore it is important to ensure the survivability of large scale networks which consist of various connections provided over multiple interconnected networks with varying technologies. This document examines the applicability of the PCE architecture, protocols, and procedures for computing protection paths and restoration services, for single and multi-domain networks. This document also explains the mechanism of Fast Re-Route (FRR) where a point of local repair (PLR) needs to find the appropriate merge point (MP) to do bypass path computation using PCE. | ||||||||||||||||
| draft-chen-pce-sr-ingress-protection-09.txt | |||||||||||||||||
| Path Ingress Protections | |||||||||||||||||
|
This document describes extensions to Path Computation Element (PCE) communication Protocol (PCEP) for fast protecting the ingress nodes of two types of paths or tunnels, which are Segment Routing (SR) paths and Bit Index Explicit Replication Tree/Traffic Engineering (BIER-TE) paths. The extensions comprise a foundation for protecting the ingress nodes of different types of paths. Based on this, the ingress protection of a new type of paths can be easily supported. | ||||||||||||||||
| draft-chen-pce-sr-mpls-sid-verification-06.txt | |||||||||||||||||
| PCEP Extensions for sid verification for SR-MPLS | |||||||||||||||||
|
This document defines a new flag for indicating the headend is explicitly requested to verify SID(s) by the PCE. | ||||||||||||||||
| draft-chen-pim-be-mrh-simu-00.txt | |||||||||||||||||
| Stateless Best Effort Multicast Simulations | |||||||||||||||||
|
This document describes simulations of stateless best effort Multicasts and lists a set of simulation results for different large network sizes and different tree sizes. | ||||||||||||||||
| draft-chen-pim-mrh6-04.txt | |||||||||||||||||
| Stateless Traffic Engineering Multicast using MRH | |||||||||||||||||
|
This document describes a stateless traffic engineering (TE) multicast along an explicit P2MP Path/Tree using an IPv6 extension header called TE multicast routing header (MRH). The MRH with the path encoded in link numbers is added into a packet to be multicast at the ingress. The packet is delivered to the egresses along the path. There is no state stored in the core of the network. | ||||||||||||||||
| draft-chen-pim-srv6-p2mp-path-07.txt | |||||||||||||||||
| Stateless SRv6 Point-to-Multipoint Path | |||||||||||||||||
|
This document describes a solution for a SRv6 Point-to-Multipoint (P2MP) Path/Tree to deliver the traffic from the ingress of the path to the multiple egresses/leaves of the path in a SR domain. There is no state stored in the core of the network for a SR P2MP path like a SR Point-to-Point (P2P) path in this solution. | ||||||||||||||||
| draft-chen-rtgwg-srv6-midpoint-protection-11.txt | |||||||||||||||||
| SRv6 Midpoint Protection | |||||||||||||||||
|
The current local repair mechanism, e.g., TI-LFA, allows local repair actions on the direct neighbors of the failed node or link to temporarily route traffic to the destination. This mechanism does not work properly for SRv6 TE path after the failure happens in the destination point and IGP converges on the failure. This document defines midpoint protection for SRv6 TE path, which enables other nodes on the network to perform endpoint behaviors for the faulty node, update the IPv6 destination address to the next endpoint after the faulty node, and choose the next hop based on the new destination address. | ||||||||||||||||
| draft-chen-secure-routing-requirements-01.txt | |||||||||||||||||
| The Requirements for Secure Routing | |||||||||||||||||
|
Both ISPs and users have put forward requirements for secure routing, the scenarios are analyzed in the draft draft-chen-secure-routing- use-cases. This draft analyzes the functions required to implement secure routing. Attack detection and users security requirements translateion are out of scope. | ||||||||||||||||
| draft-chen-secure-routing-use-cases-02.txt | |||||||||||||||||
| The Use Cases for Secure Routing | |||||||||||||||||
|
Current routing mechanism is based on the shortest path, which only take the link status and the path accessibility into consideration, without the security of links and forwarding nodes. As security has become an important factor to the user. This paper proposes to add security factor in the routing process. With the frequent occurrence of security incidents, services security is an essential demand for the users. As there are many security devices in the ISP's network, this draft proposes secure routing mechanism. The purpose of secure routing is to converge security and routing to ensure the secure data transmission. The scope is transmission process security, while end-to-end security and application layer security are out of scope. | ||||||||||||||||
| draft-chen-sm2-sm3-algorithms-04.txt | |||||||||||||||||
| Use of the SM2 and SM3 Algorithms in Handle System | |||||||||||||||||
|
The Handle System is a global name service that allows secured handle resolution and administration over the public Internet according to [1][5][3]. Handle System protocol [3] is designed to be transmitted as a byte stream via a TCP connection. In this document, SM2 and SM3 algorithms [4][5]are introduced into the handle system to enhance the security and compactivity. Trusted resolution and message credential are extended to support SM2 and SM3 algorithms. | ||||||||||||||||
| draft-chen-spring-sr-policy-for-ubfd-06.txt | |||||||||||||||||
| Segment Routing for Unaffiliated BFD Echo Function | |||||||||||||||||
|
This document describes how to leverage Segment Routing (SR) to ensure that the Unaffiliated BFD (U-BFD) Echo packets must reach the remote system before being looped back to the local system. This enables that U-BFD works not only for one hop scenario but for multiple hops scenario as well. In addition, this document also defines a way to explicitly specify the loop back path of the U-BFD Echo packets. This is useful in the case where the forward and reverse path of the Echo packets are required to follow the same path. | ||||||||||||||||
| draft-chen-spring-srmpls-frr-ex-00.txt | |||||||||||||||||
| SR-MPLS FRR Extension | |||||||||||||||||
|
The current SR FRR such as TI-LFA provides fast re-route protection for the failure of a node on an SR-MPLS path by the neighbor upstream node as point of local repair (PLR) of the failed node. However, once the IGP converges, the SR FRR is no longer sufficient to forward traffic of the path around the failure, since the non-neighbor upstream node of the failed node will no longer have a route to the failed node. This document describes a simple mechanism to extend the fast re-route protection for the failure on an SR-MPLS path after the IGP converges. The mechanism protects the node SID, adjacency SID and binding SID of the failed node on the path. | ||||||||||||||||
| draft-chen-trusted-resolution-04.txt | |||||||||||||||||
| Trusted Resolution System and Protocol Extension | |||||||||||||||||
|
The Handle System [1][2]is a name service system for handle resolution and management over the public Internet. Handle System protocol [3] is designed to be transmitted as a byte stream via a TCP connection. This document describes a Trusted Resolution System and the protocol extension based on Handle System protocol. Trusted resolution aims to achieve credibility verification through data signing. The Trusted Resolution System determines whether to perform trusted resolution and verification on the response according to the trusted flag requested by the client. | ||||||||||||||||
| draft-cheng-6man-source-address-programmability-00.txt | |||||||||||||||||
| Source IPv6 Address Programmability | |||||||||||||||||
|
IPv6-based tunneling technologies, such as SRv6, have been deployed by provider on transport networks to provide users with services such as VPN and SD-WAN. After the service traffic enters the provider's transport network, it will be encapsulated by tunnel (SRv6 encapsulation). In order to better meet the SLA requirements of users, some technologies need to carry relevant information along with the flow to guide the processing of packets during forwarding. This document discusses the programmability of IPv6 source addresses to carry the necessary flow information | ||||||||||||||||
| draft-cheng-dhc-distribute-srv6-locator-by-dhcp-04.txt | |||||||||||||||||
| Distribute SRv6 Locator by DHCP | |||||||||||||||||
|
In SRv6 network, locators need to be assigned to each SRv6 Endpoint, and segments are created based on locators. This document describes the method of assigning locators to SRv6 Endpoints through DHCPv6. | ||||||||||||||||
| draft-cheng-idr-redirection-risks-ps-02.txt | |||||||||||||||||
| Problem statement of Inter-domain Traffic Redirection Risks | |||||||||||||||||
|
Redirection of network traffic on the Internet is a common technology. In operator network, there are complex scenarios, such as multi-domain interconnection and large scale network topology. Typo, limitation of out-of-band tool capabilities for configuration verification, network adjustment or failure may cause risks, such as traffic detour, traffic exposure, traffic black hole and traffic loops. This draft describes these risks. | ||||||||||||||||
| draft-cheng-lsr-igp-shortcut-enhancement-00.txt | |||||||||||||||||
| IGP Shortcut Enhancement | |||||||||||||||||
|
IGP shortcut mechanism allows calculating routes to forward traffic over Traffic Engineering tunnels. This document describes the enhancement of IGP shortcut which can steer routes onto TE-tunnels based on colors. | ||||||||||||||||
| draft-cheng-lsr-isis-srv6-sid-block-01.txt | |||||||||||||||||
| IS-IS Extension to Advertise SRv6 SIDs using SID Block | |||||||||||||||||
|
This document proposes a simplified method to advertise SRv6 SIDs in IS-IS. The SRv6 SID Block is composed of a number of continuous SIDs within the address range of a Locator. When a SID is assigned from the SID Block, it is described by an index based on the SID Block, instead of the whole 128-bit IPv6 address. | ||||||||||||||||
| draft-cheng-lsr-ospf-adjacency-suppress-00.txt | |||||||||||||||||
| OSPF Adjacency Suppression | |||||||||||||||||
|
This document describes a mechanism for a router to instructs its neighbors to suppress advertising the adjacency to it until link- state database synchronization and LSA reoriginating are complete. This minimizes transient routing disruption when a router restarts from unplanned outages. | ||||||||||||||||
| draft-cheng-rtgwg-srv6-multihome-egress-protection-03.txt | |||||||||||||||||
| SRv6 Egress Protection in Multi-homed scenario | |||||||||||||||||
|
This document describes a SRv6 egress node protection mechanism in multi-homed scenarios. | ||||||||||||||||
| draft-cheng-savnet-proactive-defense-network-00.txt | |||||||||||||||||
| Network Proactive Defense based on Source Address Validation | |||||||||||||||||
|
Network proactive defense can be achieved if the routers run source address validation mechanisms for checking the validity of packets. This document mainly describes network proactive threat awareness which can be the first step of network proactive defense. | ||||||||||||||||
| draft-cheng-spring-service-interworking-srv6-00.txt | |||||||||||||||||
| Service Interworking between SRv6 | |||||||||||||||||
|
When operators provide services through SRv6, such as L3VPN and L2VPN, there may be cross-domain scenarios of multiple ASs, or multiple admin domain scenarios within the same AS. This document describes how to implement interworking of services for such scenarios. | ||||||||||||||||
| draft-cheng-spring-sr-policy-group-01.txt | |||||||||||||||||
| SR Policy Group | |||||||||||||||||
|
Segment Routing is a source routing paradigm that explicitly indicates the forwarding path for packets at the ingress node. An SR Policy is associated with one or more candidate paths, and each candidate path is either dynamic, explicit or composite. This document describes SR policy Group in MPLS and IPv6 environments. | ||||||||||||||||
| draft-cheng-spring-srv6-encoding-network-sliceid-06.txt | |||||||||||||||||
| Encoding Network Slice Identification for SRv6 | |||||||||||||||||
|
This document describes a method to encode network slicing identifier within SRv6 domain. | ||||||||||||||||
| draft-cheng-spring-srv6-resource-programming-01.txt | |||||||||||||||||
| Network Resource Programming with SRv6 | |||||||||||||||||
|
This document defines a new SRv6 network function which can be used for SRv6 Network Resource Programming. | ||||||||||||||||
| draft-choi-icnrg-aiot-10.txt | |||||||||||||||||
| Requirements and Challenges for User-level Service Managements of IoT Network by utilizing Artificial Intelligence | |||||||||||||||||
|
This document describes the requirements and challenges to employ artificial intelligence (AI) into the constraint Internet of Things (IoT) service environment for embedding intelligence and increasing efficiency. The IoT service environment includes heterogeneous and multiple IoT devices and systems that work together in a cooperative and intelligent way to manage homes, buildings, and complex autonomous systems. Therefore, it is becoming very essential to integrate IoT and AI technologies to increase the synergy between them. However, there are several limitations to achieve AI enabled IoT as the availability of IoT devices is not always high, and IoT networks cannot guarantee a certain level of performance in real-time applications due to resource constraints. This document intends to present a right direction to empower AI in IoT for learning and analyzing the usage behaviors of IoT devices/systems and human behaviors based on previous records and experiences. With AI enabled IoT, the IoT service environment can be intelligently managed in order to compensate for the unexpected performance degradation often caused by abnormal situations. | ||||||||||||||||
| draft-chuang-dkim-replay-problem-03.txt | |||||||||||||||||
| DKIM Replay Problem Statement | |||||||||||||||||
|
DomainKeys Identified Mail (DKIM, RFC6376) permits claiming some responsibility for a message by cryptographically associating a domain name with the message. For data covered by the cryptographic signature, this also enables detecting changes made during transit. DKIM survives basic email relaying. In a Replay Attack, a recipient of a DKIM-signed message re-posts the message to other recipients,while retaining the original, validating signature, and thereby leveraging the reputation of the original signer. This document discusses the resulting damage to email delivery, interoperability, and associated mail flows. A significant challenge to mitigating this problem is that it is difficult for receivers to differentiate between legitimate forwarding flows and a DKIM Replay Attack. | ||||||||||||||||
| draft-chuang-relay-flow-identifier-03.txt | |||||||||||||||||
| Relay Flow Identifier | |||||||||||||||||
|
To prevent spammers from using relay forwarding, we propose to identify relay flows. We do this by having relays categorize their authenticated traffic flows and publish to receivers identifiers associated with those flows. This is a unique, persistent over time, relay flow identifier name that is secured by some digital signature. Receivers can use this identifier to help categorize traffic through the relay and use that identifier to apply fine-grain anti-abuse policies instead of on the entire traffic through the relay. This document provides a specification for DKIM (RFC6376) for originating traffic and ARC (RFC8617) for forwarded traffic. | ||||||||||||||||
| draft-chuang-replay-resistant-arc-05.txt | |||||||||||||||||
| Replay Resistant Authenticated Receiver Chain | |||||||||||||||||
|
DKIM (RFC6376) is an IETF standard for the cryptographic protocol to authenticate email at the domain level and protect the integrity of messages during transit. Section 8.6 defines a vulnerability called DKIM Replay as a spam message sent through a SMTP MTA DKIM signer, that then is sent to many more recipients, leveraging the reputation of the signer. We propose two Replay Resistant cryptographic domain based protocols that leverage ARC (RFC8617). The first technique discloses all SMTP recipients as signed RFC822 headers by the sender which allows a receiver to verify this. The second technique defines a SMTP extension that allows both the sender and receiver to participate in signing the message signature. It includes a path building technique that accurately defines the SMTP forwarding path of the message. Both techniques permit a receiver to detect DKIM and ARC replay attacks and other attacks. This specification also defines a relay flow identifier to prevent spammers from using relay forwarding, We do this by having relays categorize their authenticated traffic flows and publish to receivers identifiers associated with those flows. Receivers can use this identifier to help categorize traffic through the relay and use that identifier to apply fine-grain anti-abuse policies instead of on the entire traffic through the relay. | ||||||||||||||||
| draft-chunduri-rtgwg-preferred-path-routing-03.txt | |||||||||||||||||
| Preferred Path Routing Framework | |||||||||||||||||
|
Capacity demands, Traffic Engineering (TE) and determinism are some of key requirements for various cellular, edge and industrial deployments. These deployments span from many underlying data pane technologies including native IPv4, native IPv6 along with MPLS and Segment Routing (SR). This document provides a framework for Preferred Path Routing (PPR). PPR is a method of providing path based dynamic routing for a number of packet types including IPv4, IPv6 and MPLS. This seamlessly works with a controller plane which holds both complete network view of operator policies, while distributed control plane providing self- healing benefits in a near-real time fashion. PPR builds on existing encapsulations at the edge nodes to add path identity to the packet. This reduces the per packet overhead required for path steering and therefore has a smaller impact on both packet MTU, data plane processing and overall goodput for small payload packets, while extending path steering benefits to any existing data plane. A number of extensions that allow expansion of use beyond simple point-to-point-paths are also described in this memo. | ||||||||||||||||
| draft-cl-spring-generalized-srv6-for-cmpr-06.txt | |||||||||||||||||
| Generalized SRv6 Network Programming for SRv6 Compression | |||||||||||||||||
|
This document proposes Generalized Segment Routing over IPv6 (G-SRv6) Networking Programming for SRv6 compression. G-SRv6 can reduce the overhead of SRv6 by encoding the Generalized SIDs(G-SID) in SID list, and it also supports to program SRv6 SIDs and G-SIDs in a single SRH to support incremental deployment and smooth upgrade. G-SRv6 is fully compatible with SRv6 with no modification of SRH, no new address consumption, no new route creation, and even no modification of control plane. G-SRv6 for Compression is designed based on the Compressed SRv6 Segment List Encoding in SRH [I-D.ietf-spring-srv6-srh-compression] framework. | ||||||||||||||||
| draft-clad-spring-srv6-srh-compression-illus-02.txt | |||||||||||||||||
| Illustrations for Compressed SRv6 Segment List Encoding in SRH | |||||||||||||||||
|
This document provides illustrations for compressed SRv6 Segment List Encoding in the Segment Routing Header (SRH). | ||||||||||||||||
| draft-claise-opsawg-collected-data-manifest-06.txt | |||||||||||||||||
| A Data Manifest for Contextualized Telemetry Data | |||||||||||||||||
|
Network elements use Model-driven Telemetry, and in particular YANG- Push, to continuously stream information, including both counters and state information. This document documents the metadata that ensure that the collected data can be interpreted correctly. This document specifies the Data Manifest, composed of two YANG data models (the Platform Manifest and the Data Collection Manifest.) The Data Manifest must be streamed and stored along with the data, up to the collection and analytics system in order to keep the collected data fully exploitable by the data scientists. | ||||||||||||||||
| draft-coene-rserpool-applic-ipfix-20.txt | |||||||||||||||||
| Reliable Server Pooling Applicability for IP Flow Information Exchange | |||||||||||||||||
|
This document describes the applicability of the Reliable Server Pooling architecture to the IP Flow Information Exchange using the Aggregate Server Access Protocol (ASAP) functionality of RSerPool only. Data exchange in IPFIX between the router and the data collector can be provided by a limited retransmission protocol. | ||||||||||||||||
| draft-collink-6man-pio-pflag-00.txt | |||||||||||||||||
| Signalling DHCPv6 Prefix Delegation Availability to Hosts | |||||||||||||||||
|
This document defines a ‘P’ flag in the Prefix Information Option of IPv6 Router Advertisements (RAs). The flag is used to indicate that the network prefers that hosts acquire global addresses using DHCPv6 PD instead of using SLAAC for this prefix. | ||||||||||||||||
| draft-collink-v6ops-ent64pd-03.txt | |||||||||||||||||
| Using DHCP-PD to Allocate Unique IPv6 Prefix per Host in Broadcast Networks | |||||||||||||||||
|
This document discusses the IPv6 deployment scenario when individual hosts connected to broadcast networks (like WiFi hotspots or enterprise networks) are allocated unique prefixes via DHCP-PD. | ||||||||||||||||
| draft-contreras-alto-service-edge-07.txt | |||||||||||||||||
| Use of ALTO for Determining Service Edge | |||||||||||||||||
|
Service providers are starting to deploy computing capabilities across the network for hosting applications such as AR/VR, vehicle networks, IoT, and AI training, among others. In these distributed computing environments, knowledge about computing and communication resources is necessary to determine the proper deployment location of each application. This document proposes an initial approach towards the use of ALTO to expose such information to the applications and assist the selection of their deployment locations. | ||||||||||||||||
| draft-contreras-coinrg-clas-evolution-00.txt | |||||||||||||||||
| An Evolution of Cooperating Layered Architecture for SDN (CLAS) for Compute and Data Awareness | |||||||||||||||||
|
This document proposes an extension to the Cooperating Layered Architecture for Software-Defined Networking (SDN) by including compute resources and data processing. | ||||||||||||||||
| draft-contreras-nmrg-interconnection-intents-03.txt | |||||||||||||||||
| Interconnection Intents | |||||||||||||||||
|
This memo introduces the use case of the usage of intents for expressing advance interconnection features, further than traditional IP peering. | ||||||||||||||||
| draft-contreras-nmrg-transport-slice-intent-06.txt | |||||||||||||||||
| IETF Network Slice Intent | |||||||||||||||||
|
Slicing at the transport network is expected to be offered as part of end-to-end network slices, fostered by the introduction of new services such as 5G. This document explores the usage of intent technologies for requesting IETF network slices. | ||||||||||||||||
| draft-contreras-opsawg-scheduling-oam-tests-00.txt | |||||||||||||||||
| A YANG Data Model for Network Diagnosis by scheduling sequences of OAM tests | |||||||||||||||||
|
This document defines a YANG data model for network diagnosis on- demand using Operations, Administration, and Maintenance (OAM) tests. This document defines both 'oam-unitary-test' and 'oam-test-sequence' data models to enable on-demand activation of network diagnosis procedures. The YANG data model defined in this document conforms to the Network Management Datastore Architecture (NMDA). | ||||||||||||||||
| draft-contreras-teas-slice-controller-models-05.txt | |||||||||||||||||
| IETF Network Slice Controller and its associated data models | |||||||||||||||||
|
This document describes a potential division in major functional components of an IETF Network Slice Controller (NSC) as well as references the data models required for supporting the requests of IETF network slice services and their realization. This document describes a potential way of structuring the IETF Network Slice Controller as well as how to use different data models being defined for IETF Network Slice Service provision (and how they are related). It is not the purpose of this document to standardize or constrain the implementation the IETF Network Slice Controller. | ||||||||||||||||
| draft-contreras-tvr-alto-exposure-00.txt | |||||||||||||||||
| Using ALTO for exposing Time-Variant Routing information | |||||||||||||||||
|
Network operations can require time-based, scheduled changes in nodes, links, adjacencies, etc. All those changes can alter the connectivity in the network in a predictable manner, which is known as Time-Variant Routing (TVR). Existing IETF solutions like ALTO can assist on the exposure of such predicted changes to both internal and external applications then anticipating the occurence of routing changes. This document describes how ALTO helps in that purpose. | ||||||||||||||||
| draft-coolidge-enhanced-data-protection-00.txt | |||||||||||||||||
| Enhanced Data Protection via Cryptographic Signing and Permission-based Labeling | |||||||||||||||||
|
This document proposes an enhanced approach to data protection for computer applications by requiring them to cryptographically sign or label data generated using granted permissions. This would allow the host system to manage the storage and transport of generated data, ensuring a granular level of control and ultimately protecting user data more effectively. | ||||||||||||||||
| draft-cp-spring-srv6-sid-allocation-02.txt | |||||||||||||||||
| SRv6 SID Allocation | |||||||||||||||||
|
This document describes a SRv6 SID allocation method. | ||||||||||||||||
| draft-cppy-grow-bmp-path-marking-tlv-12.txt | |||||||||||||||||
| BMP Extension for Path Status TLV | |||||||||||||||||
|
The BGP Monitoring Protocol (BMP) provides an interface for obtaining BGP Path information. BGP Path Information is conveyed within BMP Route Monitoring (RM) messages. This document proposes an extension to BMP to convey the status of a path after being processed by the BGP process. This extension makes use of the TLV mechanims described in draft-ietf-grow-bmp-tlv [I-D.ietf-grow-bmp-tlv] and draft-ietf-grow-bmp-tlv-ebit [I-D.ietf-grow-bmp-tlv-ebit]. | ||||||||||||||||
| draft-crocker-dkim-replay-00.txt | |||||||||||||||||
| DKIM Replay: Problem Statement | |||||||||||||||||
|
DomainKeys Identified Mail (DKIM, RFC6376) permits claiming some responsibility for a message by cryptographically associating a domain name with the message. For data covered by the cryptographic signature, this also enables detecting changes made during transit. DKIM survives basic email relaying. In a Replay Attack, a recipient of a DKIM-signed message re-posts the message to other recipients, while retaining the original, validating signature, and thereby leveraging the reputation of the original signer. This document discusses the resulting damage to email delivery, interoperability, and associated mail flows. A significant challenge to mitigating this problem is that it is difficult for receivers to differentiate between legitimate forwarding flows and a DKIM Replay Attack. | ||||||||||||||||
| draft-cth-rtgwg-bgp-control-10.txt | |||||||||||||||||
| Architecture for Use of BGP as Central Controller | |||||||||||||||||
|
BGP is a core part of a network including Software-Defined Networking (SDN) system. It has the traffic engineering information on the network topology and can compute optimal paths for a given traffic flow across the network. This document describes some reference architectures for BGP as a central controller. A BGP-based central controller can simplify the operations on the network and use network resources efficiently for providing services with high quality. | ||||||||||||||||
| draft-cui-savnet-anti-ddos-01.txt | |||||||||||||||||
| SAV-based Anti-DDoS Architecture | |||||||||||||||||
|
Existing SAV schemes can not effectively defend against IP Spoofing DDoS under incremental deployment. This document proposes SAV-D, an SAV-honeynet based distributed defense architecture to enhance SAV's defense. The main idea of SAV-D is to collect and aggregate more threat data from existing SAV devices and then distribute crucial knowledge to widespread devices, thus significantly expanding defense across the entire network. | ||||||||||||||||
| draft-cuiling-dnsop-sm2-alg-05.txt | |||||||||||||||||
| SM2 Digital Signature Algorithm for DNSSEC | |||||||||||||||||
|
This document describes how to specify SM2 Digital Signature Algorithm keys and signatures in DNS Security (DNSSEC). It lists the curve and uses SM3 as hash algorithm for signatures. | ||||||||||||||||
| draft-cullen-radextra-status-realm-00.txt | |||||||||||||||||
| Status-Realm and Loop Prevention for the Remote Dial-In User Service (RADIUS) | |||||||||||||||||
|
This document describes extension to the Remote Authentication Dial- In User Service (RADIUS) protocol to allow participants in a multi- hop RADIUS proxy fabric to check the status of a remote RADIUS authentication realm, gain visibility into the path that a RADIUS request will take across the RADIUS proxy fabric, and mitigate or prevent RADIUS proxy loops. | ||||||||||||||||
| draft-cutler-httpbis-partitioned-cookies-01.txt | |||||||||||||||||
| Cookies Having Independent Partitioned State specification | |||||||||||||||||
|
This document updates RFC6265bis, defining a new attribute, Partitioned, which restricts the contexts in which a cookie is available to only those whose top-level document is same-site with the top-level document that initiated the request that created the cookie. These cookies are referred to as "partitioned cookies" and allow embedded sites which are cross-site with the top-level frame to have access to HTTP state which cannot be used for tracking across multiple top-level sites. | ||||||||||||||||
| draft-cx-green-metrics-02.txt | |||||||||||||||||
| Green Networking Metrics | |||||||||||||||||
|
This document explains the need for network instrumentation that allows to assess the power consumption, energy efficiency, and carbon footprint associated with a network, its equipment, and the services that are provided over it. It also suggests a set of related metrics that, when provided visibility into, can help to optimize a network's energy efficiency and "greenness". | ||||||||||||||||
| draft-cx-green-ps-02.txt | |||||||||||||||||
| Challenges and Opportunities in Management for Green Networking | |||||||||||||||||
|
Reducing technology's carbon footprint is one of the big challenges of our age. Networks are an enabler of applications that reduce this footprint, but also contribute to this footprint substantially themselves. Many of the biggest opportunities to reduce this footprint may not be management or even networking specific, for instance general power efficiency gains in hardware or deployment of equipment in more energy-efficient buildings. However, methods to make networking technology itself "greener" and in particular to manage networks in ways that reduces their carbon footprint without impacting their utility also need to be explored. This document outlines a corresponding set of opportunities, along with associated research challenges, for networking technology in general and management technology in particular to become "greener" and reduce network carbon footprint. | ||||||||||||||||
| draft-cx-mpls-mna-inband-pm-01.txt | |||||||||||||||||
| MNA for Performance Measurement with Alternate Marking Method | |||||||||||||||||
|
MPLS Network Action (MNA) is used to indicate action for Label Switched Paths (LSPs) and/or MPLS packets and to transfer data needed for the action. This document defines MNA encoding for MPLS performance measurement with alternate marking method, which performs flow-based packet loss, delay, and jitter measurements on MPLS live traffic. | ||||||||||||||||
| draft-cz-bier-bgp-ls-bier-te-ext-01.txt | |||||||||||||||||
| BGP-LS extensions for BIER-TE | |||||||||||||||||
|
as described in [RFC8279]. BIER-TE forwards and replicates packets based on a BitString in the packet header, but every BitPosition of the BitString of a BIER-TE packet indicates one or more adjacencies as described in [RFC9262]. BGP Link-State (BGP-LS) enables the collection of various topology informations from the network, and the topology informations are used by the PCE to calculate the path and then propagate them onto the BFRs(instead of having each node to calculate on its own) and that can be for both inter-as and intra-as situations. This document specifies extensions to the BGP Link-state address- family in order to advertise BIER-TE informations. | ||||||||||||||||
| draft-dahm-opsawg-tacacs-security-01.txt | |||||||||||||||||
| TACACS+ Security and SSH Public Keys | |||||||||||||||||
|
The TACACS+ Protocol [RFC8907] provides device administration for routers, network access servers and other networked computing devices via one or more centralized servers. This document, a companion to the TACACS+ protocol [RFC8907], adds new packet formats to improve security and function and support for SSH [RFC4716] public keys. | ||||||||||||||||
| draft-dai-netconf-quic-netconf-over-quic-03.txt | |||||||||||||||||
| Using NETCONF over QUIC connection | |||||||||||||||||
|
The Network Configuration Protocol (NETCONF) provides mechanisms to install, manipulate, and delete the configuration of network devices. At present, almost all implementations of NETCONF are based on TCP based protocol. QUIC, a new UDP-based, secure and multiplexed transport protocol, can facilitate to improve the transportation performance, information security and resource utility when being used as an infrastructure layer of NETCONF. This document describes how to use the QUIC protocol as the transport protocol of NETCONF(It is so called NETCONFoQUIC). | ||||||||||||||||
| draft-dai-sfc-fused-architecture-and-scenario-04.txt | |||||||||||||||||
| Architecture and application scenario for fused service function chain | |||||||||||||||||
|
This document discusses the architecture and application scenarios of fused service function chain. Fused service function chain means that two or more service function chains are fused to become a single service function chain from the view of data plane, control plane and management plane. Fused service function chain is an expansion for general service function chain.Anyhow, some mechanism or methods need to be used when two or more service function chains are fused to be a single service function chain based on architecture described in this memo. | ||||||||||||||||
| draft-dai-sfc-fused-protocol-and-procedure-01.txt | |||||||||||||||||
| Protocol extension and mechanism for fused service function chain | |||||||||||||||||
|
This document discusses the protocol extension and procedure that are used to implement the fused service function chain. Fused service function chain means that two or more service function chains are fused to become a single service function chain from the view of data plane and control plane. Fused service function chain is a extension for service function chain. | ||||||||||||||||
| draft-daley-gendispatch-venue-requirements-00.txt | |||||||||||||||||
| IETF Meeting Venue Requirements Review | |||||||||||||||||
|
This document sets out a series of recommendations and proposals to the IETF Community from the IETF Administration LLC following a review of the IETF meeting venue requirements. Editorial Note Discussion of this draft takes place on the gendispatch mailing list, which has its home page at | ||||||||||||||||
| draft-damjanovic-websockets-https-rr-01.txt | |||||||||||||||||
| Advertising the WebSockets support in the HTTPS resource record | |||||||||||||||||
|
This specification introduces a mechanism to advertise the support for WebSockets over different HTTP versions using HTTPS resource records. This mechanism allows clients to avoid delays in establishing WebSocket connections using HTTP-based advertisement for WebSocket support. | ||||||||||||||||
| draft-davidben-tls-merkle-tree-certs-00.txt | |||||||||||||||||
| Merkle Tree Certificates for TLS | |||||||||||||||||
|
This document describes Merkle Tree certificates, a new certificate type for use with TLS. A relying party that regularly fetches information from a transparency service can use this certificate type as a size optimization over more conventional mechanisms with post- quantum signatures. Merkle Tree certificates integrate the roles of X.509 and Certificate Transparency, achieving comparable security properties with a smaller message size, at the cost of more limited applicability. | ||||||||||||||||
| draft-davidben-x509-policy-graph-01.txt | |||||||||||||||||
| Updates to X.509 Policy Validation | |||||||||||||||||
|
This document updates RFC 5280 to replace the algorithm for X.509 policy validation with an equivalent, more efficient algorithm. The original algorithm built a structure which scaled exponentially in the worst case, leaving implementations vulnerable to denial-of- service attacks. | ||||||||||||||||
| draft-davids-forsalereg-02.txt | |||||||||||||||||
| Registration of Underscored and Globally Scoped 'for sale' DNS Node Name | |||||||||||||||||
|
This document defines a simple operational convention of using a reserved underscored node name ("_for-sale") to indicate that the parent domain name above, is for sale. It has the advantage that it can be easily deployed, without affecting any running operations. As such, the method can be applied to a domain name that is still in full use. | ||||||||||||||||
| draft-davies-int-historic-05.txt | |||||||||||||||||
| Deprecating infrastructure "int" domains | |||||||||||||||||
|
The document deprecates the use of any "int" domain names that were designated for infrastructure purposes by the IETF, and identifies them for removal from the "int" top-level domain. Any implementation that involves these domains should be considered deprecated. This document also requests moving the status of RFC 1528 and RFC 1706 to historic. | ||||||||||||||||
| draft-davis-netmod-modelling-boundaries-01.txt | |||||||||||||||||
| Modelling Boundaries | |||||||||||||||||
|
Current modelling techniques appear to have boundaries that make representation of some concepts in modern problems, such as intent and capability, challenging. The concepts all have in common the need to represent uncertainty and vagueness. The challenge results from the rigidity of boundary representation, including the absoluteness of instance value and the process of classification itself, provided by current techniques. When describing solutions, a softer approach seems necessary where the emphasis is on the focus on a particular thing from a particular perspective. Intelligent control (use of AI/ML etc.) could take advantage of partial compatibilities etc. if a softer representation was achieved. The solution representation appears to require * Expression of range, preference and focus as a fundamental part of | ||||||||||||||||
| draft-dbb-netmod-acl-03.txt | |||||||||||||||||
| Extensions to the Access Control Lists (ACLs) YANG Model | |||||||||||||||||
|
RFC 8519 defines a YANG data model for Access Control Lists (ACLs). This document discusses a set of extensions that fix many of the limitations of the ACL model as initially defined in RFC 8519. Discussion Venues This note is to be removed before publishing as an RFC. Discussion of this document takes place on the Network Modeling Working Group mailing list (netmod@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/netmod/. Source for this draft and an issue tracker can be found at https://github.com/oscargdd/draft-dbb-netmod-enhanced-acl. | ||||||||||||||||
| draft-dcn-bmwg-containerized-infra-10.txt | |||||||||||||||||
| Considerations for Benchmarking Network Performance in Containerized Infrastructures | |||||||||||||||||
|
Recently, the Benchmarking Methodology Working Group has extended the laboratory characterization from physical network functions (PNFs) to virtual network functions (VNFs). Considering the network function implementation trend moving from virtual machine-based to container- based, system configurations and deployment scenarios for benchmarking will be partially changed by how the resource allocation and network technologies are specified for containerized VNFs. This draft describes additional considerations for benchmarking network performance when network functions are containerized and performed in general-purpose hardware. | ||||||||||||||||
| draft-dcook-ppm-dap-interop-test-design-03.txt | |||||||||||||||||
| DAP Interoperation Test Design | |||||||||||||||||
|
This document defines a common test interface for implementations of the Distributed Aggregation Protocol for Privacy Preserving Measurement (DAP) and describes how this test interface can be used to perform interoperation testing between the implementations. Tests are orchestrated with containers, and new test-only APIs are introduced to provision DAP tasks and initiate processing. | ||||||||||||||||
| draft-decraene-mpls-slid-encoded-entropy-label-id-05.txt | |||||||||||||||||
| Using Entropy Label for Network Slice Identification in MPLS networks. | |||||||||||||||||
|
This document updates [RFC6790] to extend the use of the TTL field of the Entropy Label in order to provide a flexible set of flags called the Entropy Label Control field. This document also defines a solution to encode a slice identifier in MPLS in order to distinguish packets that belong to different slices, to allow enforcing per network slice policies (.e.g, Qos). The slice identification is independent of the topology. It allows for QoS/DiffServ policy on a per slice basis in addition to the per packet QoS/DiffServ policy provided by the MPLS Traffic Class field. In order to minimize the size of the MPLS stack and to ease incremental deployment the slice identifier is encoded as part of the Entropy Label. | ||||||||||||||||
| draft-defoy-moq-relay-network-handling-01.txt | |||||||||||||||||
| MOQ Relays for Support of High-Throughput Low-Latency Traffic | |||||||||||||||||
|
This document describes a mechanism to convey information about media frames. The information is used for specific handling in functions such as error recovery and congestion handling. These functions can be critical to improve energy efficiency and network capacity in some (especially wireless) networks. Due to end-to-end encryption, MOQ relays are expected to extract the metadata required by these functions. This document aims to enable a level of wireless network support for MOQ equivalent to what is possible for RTP. | ||||||||||||||||
| draft-dejong-remotestorage-20.txt | |||||||||||||||||
| remoteStorage | |||||||||||||||||
|
This draft describes a protocol by which client-side applications, running inside a web browser, can communicate with a data storage server that is hosted on a different domain name. This way, the provider of a web application need not also play the role of data storage provider. The protocol supports storing, retrieving, and removing individual documents, as well as listing the contents of an individual folder, and access control is based on bearer tokens. | ||||||||||||||||
| draft-dekater-panrg-scion-overview-03.txt | |||||||||||||||||
| SCION Overview | |||||||||||||||||
|
The Internet has been successful beyond even the most optimistic expectations and is intertwined with many aspects of our society. But although the world-wide communication system guarantees global reachability, the Internet has not primarily been built with security and high availability in mind. The next-generation inter-network architecture SCION (Scalability, Control, and Isolation On Next- generation networks) aims to address these issues. SCION was explicitly designed from the outset to offer security and availability by default. The architecture provides route control, failure isolation, and trust information for end-to-end communication. It also enables multi-path routing between hosts. This document discusses the motivations behind the SCION architecture and gives a high-level overview of its fundamental components, including its authentication model and the setup of the control- and data plane. A more detailed analysis of relationships and dependencies between components is available in [I-D.rustignoli-scion-components]. As SCION is already in production use today, the document concludes with an overview of SCION deployments. | ||||||||||||||||
| draft-dekater-scion-pki-02.txt | |||||||||||||||||
| SCION Control-Plane PKI | |||||||||||||||||
|
This document presents the trust concept and design of the SCION _control-plane Public Key Infrastructure (PKI)_, SCION's public key infrastructure model. SCION (Scalability, Control, and Isolation On Next-generation networks) is a path-aware, inter-domain network architecture. The control-plane PKI, or short CP-PKI, handles cryptographic material and lays the foundation for the authentication procedures in SCION. It is used by SCION's control plane to authenticate and verify path information, and builds the basis for SCION's special trust model based on so-called Isolation Domains. This document first introduces the trust model behind the SCION's control-plane PKI, as well as clarifications to the concepts used in it. This is followed by specifications of the different types of certificates and the Trust Root Configuration. The document then specifies how to deploy the whole infrastructure. | ||||||||||||||||
| draft-dekok-radext-deprecating-radius-01.txt | |||||||||||||||||
| Deprecating RADIUS/UDP and RADIUS/TCP | |||||||||||||||||
|
RADIUS crypto-agility was first mandated as future work by RFC 6421. The outcome of that work was the publication of RADIUS over TLS (RFC 6614) and RADIUS over DTLS (RFC 7360) as experimental documents. Those transport protocols have been in wide-spread use for many years in a wide range of networks. They have proven their utility as replacements for the previous UDP (RFC 2865) and TCP (RFC 6613) transports. With that knowledge, the continued use of insecure transports for RADIUS has serious and negative implications for privacy and security. This document formally deprecates the use of the User Datagram Protocol (UDP) and of the Transport Congestion Protocol (TCP) as transport protocols for RADIUS. These transports are permitted inside of secure networks, but their use even in that environment is strongly discouraged. For all other environments, the use of secure transports such as IPsec or TLS is mandated. | ||||||||||||||||
| draft-dekok-radext-radiusv11-05.txt | |||||||||||||||||
| RADIUS Version 1.1 | |||||||||||||||||
|
This document defines Application-Layer Protocol Negotiation Extensions for use with RADIUS/TLS and RADIUS/DTLS. These extensions permit the negotiation of an additional application protocol for RADIUS over (D)TLS. No changes are made to RADIUS/UDP or RADIUS/TCP. The extensions allow the negotiation of a transport profile where the RADIUS shared secret is no longer used, and all MD5-based packet signing and attribute obfuscation methods are removed. When this extension is used, the previous Authenticator field is repurposed to contain an explicit request / response identifier, called a Token. The Token also allows more than 256 packets to be outstanding on one connection. This extension can be seen as a transport profile for RADIUS, as it is not an entirely new protocol. It uses the existing RADIUS packet layout and attribute format without change. As such, it can carry all present and future RADIUS attributes. Implementation of this extension requires only minor changes to the protocol encoder and decoder functionality. The protocol defined by this extension is named "RADIUS version 1.1", or "RADIUS/1.1". | ||||||||||||||||
| draft-dekok-radext-reverse-coa-00.txt | |||||||||||||||||
| Reverse CoA in RADIUS | |||||||||||||||||
|
This document defines a "reverse change of authorization (CoA)" path for RADIUS packets. This specification allows a home server to send CoA packets in "reverse" down a RADIUS/TLS connection. Without this capability, it is impossible for a home server to send CoA packets to a NAS which is behind a firewall or NAT gateway. The reverse CoA functionality extends the available transport methods for CoA packets, but it does not change anything else about how CoA packets are handled. | ||||||||||||||||
| draft-dekok-radext-tls-psk-00.txt | |||||||||||||||||
| RADIUS and TLS-PSK | |||||||||||||||||
|
This document gives implementation and operational considerations for using TLS-PSK with RADIUS/TLS (RFC6614) and RADIUS/DTLS (RFC7360). | ||||||||||||||||
| draft-deng-overlay-routing-ps-01.txt | |||||||||||||||||
| Overlay Routing Problem Statement | |||||||||||||||||
|
This document considers the limitations of existing technologies in addressing the challenges of low network latency. It analyzes the problem of signaling redundancy on control plane and problem of non- global optimal path selection policy for overlay network and explores possible solutions. | ||||||||||||||||
| draft-denis-dprive-dnscrypt-00.txt | |||||||||||||||||
| The DNSCrypt protocol | |||||||||||||||||
|
The DNSCrypt protocol is designed to encrypt and authenticate DNS traffic between clients and resolvers. This document specifies the protocol and its implementation. About This Document This note is to be removed before publishing as an RFC. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-denis-dprive-dnscrypt/. Source for this draft and an issue tracker can be found at https://github.com/DNSCrypt/dnscrypt-protocol. | ||||||||||||||||
| draft-deping-avtcore-video-bframe-01.txt | |||||||||||||||||
| Video BFrame RTP Header Extension | |||||||||||||||||
|
This document describes an RTP header extension used to convey decoding time information about video when Bi-directional predicted frames exist, It adds CompositionTime(CTS) as value so that receiver can decode video with correct sequence. | ||||||||||||||||
| draft-devault-bare-08.txt | |||||||||||||||||
| Binary Application Record Encoding (BARE) | |||||||||||||||||
|
The Binary Application Record Encoding (BARE) is a data format used to represent application records for storage or transmission between programs. BARE messages are concise and have a well-defined schema, and implementations may be simple and broadly compatible. A schema language is also provided to express message schemas out-of-band. Comments Comments are solicited and should be addressed to the mailing list at ~sircmpwn/public-inbox@lists.sr.ht and/or the author(s). | ||||||||||||||||
| draft-dhody-pce-pcep-extension-pce-controller-p2mp-10.txt | |||||||||||||||||
| PCE Communication Protocol (PCEP) Extensions for Using the PCE as a Central Controller (PCECC) of point-to-multipoint (P2MP) LSPs | |||||||||||||||||
|
The PCE is a core component of Software-Defined Networking (SDN) systems. The PCE has been identified as an appropriate technology for the determination of the paths of point-to-multipoint (P2MP) TE Label Switched Paths (LSPs). A PCE-based Central Controller (PCECC) can simplify the processing of a distributed control plane by blending it with elements of SDN and without necessarily completely replacing it. Thus, the P2MP LSP can be calculated/set up/initiated and the label-forwarding entries can also be downloaded through a centralized PCE server to each network device along the P2MP path, while leveraging the existing PCE technologies as much as possible. This document specifies the procedures and PCE Communication Protocol (PCEP) extensions for using the PCE as the central controller for provisioning labels along the path of the static P2MP LSP. | ||||||||||||||||
| draft-dhody-pce-pcep-object-order-03.txt | |||||||||||||||||
| Updated Rules for PCE Communication Protocol (PCEP) Object Ordering | |||||||||||||||||
|
The PCE Communication Protocol (PCEP) defines the mechanisms for the communication between a Path Computation Client (PCC) and a PCE, or among PCEs. Such interactions include path computation requests and path computation replies defined in RFC 5440. As per RFC 5440, these message are required to follow strict object ordering. This document updates RFC 5440 by relaxing the strict object ordering requirement in the PCEP messages. | ||||||||||||||||
| draft-dhody-pce-pceps-tls13-02.txt | |||||||||||||||||
| Updates for PCEPS | |||||||||||||||||
|
RFC 8253 defines how to protect PCEP messages with TLS 1.2. This document updates RFC 8253 to address support requirements for TLS 1.2 and TLS 1.3 and the use of TLS 1.3's early data. Discussion Venues This note is to be removed before publishing as an RFC. Discussion of this document takes place on the Path Computation Element Working Group mailing list (pce@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/pce/. Source for this draft and an issue tracker can be found at https://github.com/dhruvdhody/draft-dhody-pce-pceps-tls13. | ||||||||||||||||
| draft-dhody-pce-stateful-pce-vendor-16.txt | |||||||||||||||||
| Conveying Vendor-Specific Information in the Path Computation Element (PCE) Communication Protocol (PCEP) extensions for Stateful PCE. | |||||||||||||||||
|
A Stateful Path Computation Element (PCE) maintains information on the current network state, including computed Label Switched Path (LSPs), reserved resources within the network, and the pending path computation requests. This information may then be considered when computing new traffic engineered LSPs, and for the associated and the dependent LSPs, received from a Path Computation Client (PCC). RFC 7470 defines a facility to carry vendor-specific information in Path Computation Element Communication Protocol (PCEP). This document extends this capability for the Stateful PCEP messages. | ||||||||||||||||
| draft-dhody-teas-ietf-network-slice-mapping-03.txt | |||||||||||||||||
| IETF Network Slice Service Mapping YANG Model | |||||||||||||||||
|
This document provides a YANG data model to map IETF network slice service to Traffic Engineering (TE) models (e.g., the Virtual Network (VN) model or the TE Tunnel etc). It also supports mapping to the VPN Network models and Network Resource Partition (NRP) models. These models are referred to as IETF network slice service mapping model and are applicable generically for the seamless control and management of the IETF network slice service with underlying TE/VPN support. The models are principally used for monitoring and diagnostics of the management systems to show how the IETF network slice service requests are mapped onto underlying network resource and TE/VPN models. | ||||||||||||||||
| draft-dhody-teas-te-traffic-yang-03.txt | |||||||||||||||||
| Traffic Mapping YANG model for Traffic Engineering (TE) | |||||||||||||||||
|
This document provides a YANG data model to map traffic to Traffic Engineering (TE) paths. This model providers operator a seamless control and management of which traffic to send on the underlying TE resources. | ||||||||||||||||
| draft-dhodylee-pce-pcep-ls-25.txt | |||||||||||||||||
| PCEP extensions for Distribution of Link-State and TE Information | |||||||||||||||||
|
In order to compute and provide optimal paths, a Path Computation Elements (PCEs) require an accurate and timely Traffic Engineering Database (TED). Traditionally, this TED has been obtained from a link state (LS) routing protocol supporting the traffic engineering extensions. This document extends the Path Computation Element Communication Protocol (PCEP) with Link-State and TE Information as an experimental extension. | ||||||||||||||||
| draft-diaz-lzip-06.txt | |||||||||||||||||
| Lzip Compressed Format and the 'application/lzip' Media Type | |||||||||||||||||
|
Lzip is a lossless compressed data format designed for data sharing, long-term archiving, and parallel compression/decompression. Lzip uses a simplified form of the LZMA stream format and provides a 3 factor integrity checking to maximize interoperability and optimize safety. Lzip can achieve higher compression ratios than gzip. This document describes the lzip format and registers a media type, a content encoding, and a structured syntax suffix to be used when transporting lzip-compressed content via MIME or HTTP. | ||||||||||||||||
| draft-ding-idr-rtc-for-bgp-flow-sr-00.txt | |||||||||||||||||
| Route Target Constraint for BGP Flow Spec(BGP Flow) and BGP Segment Routing Policies(BGP SR-Policy) | |||||||||||||||||
|
This document introduces an extension to the application scenarios of Route Target Constraints (RTC). By using the global administrator field of the IPv4 Address Specific Extended Community to represent a network node and exchanging BGP Route-Target routes, a BGP speaker could generate an egress policy for filtering one or a group of network nodes, which could implement precise control and distribution of services such as BGP Flow Spec and BGP Segment Routing Policies. | ||||||||||||||||
| draft-dkg-mail-cleartext-copy-01.txt | |||||||||||||||||
| Encrypted E-mail with Cleartext Copies | |||||||||||||||||
|
When an e-mail program generates an encrypted message to multiple recipients, it is possible that it has no encryption capability for at least one of the recipients. In this circumstance, an e-mail program may choose to send the message in cleartext to the recipient it cannot encrypt to. This draft currently offers several possible approaches when such a choice is made by the sender, so that the recipient can reason about and act on the cryptographic status of the message responsibly. | ||||||||||||||||
| draft-dkg-openpgp-stateless-cli-06.txt | |||||||||||||||||
| Stateless OpenPGP Command Line Interface | |||||||||||||||||
|
This document defines a generic stateless command-line interface for dealing with OpenPGP messages, known as sop. It aims for a minimal, well-structured API covering OpenPGP object security. | ||||||||||||||||
| draft-dnsop-dnssec-extension-pkix-01.txt | |||||||||||||||||
| DNSSEC Extension by Using PKIX Certificates | |||||||||||||||||
|
The Domain Name System Security Extensions (DNSSEC) were standardized a couple of decades ago but it has not been widely deployed. Thus, a vast majority of DNS messages in the real world are still vulnerable to various kinds of integrity attacks like cache poisoning attacks. This document describes a mechanism that extends the current DNSSEC protocol in such a way that guarantees the integrity of DNS messages using PKIX certificates without any dependencies on other entities in the DNS infrastructure. | ||||||||||||||||
| draft-dong-idr-flowspec-network-slice-ts-01.txt | |||||||||||||||||
| BGP Flowspec for IETF Network Slice Traffic Steering | |||||||||||||||||
|
BGP Flow Specification (Flowspec) provides a mechanism to distribute traffic flow specifications and the forwarding actions to be performed to the specific traffic flows. A set of Flowspec components are defined to specify the matching criteria that can be applied to the packet, and a set of BGP extended communities are defined to encode the actions a routing system can take on a packet which matches the flow specification. An IETF Network Slice enables connectivity between a set of Service Demarcation Points (SDPs) with specific Service Level Objectives (SLOs) and Service Level Expectations (SLEs) over a common underlay network. To meet the connectivity and performance requirements of network slice services, network slice service traffic needs to be mapped to a corresponding Network Resource Partition (NRP). The edge nodes of the NRP needs to identify the traffic flows which belong to a network slice and steer the matched traffic into the corresponding NRP, or a specific path within the corresponding NRP. BGP Flowspec can be used to distribute the matching criteria and the forwarding actions to be preformed on network slice service traffic. The existing Flowspec components can be reused for the matching of network slice services flows at the edge of an NRP. New components and traffic action may need to be defined for steering network slice service flows into the corresponding NRP. This document defines the extensions to BGP Flowspec for IETF network slice traffic steering (NS-TS). | ||||||||||||||||
| draft-dong-idr-sr-policy-nrp-02.txt | |||||||||||||||||
| BGP SR Policy Extensions for Network Resource Partition | |||||||||||||||||
|
Segment Routing (SR) Policy is a set of candidate paths, each consisting of one or more segment lists and the associated information. The header of a packet steered in an SR Policy is augmented with an ordered list of segments associated with that SR Policy. A Network Resource Partition (NRP) is a subset of network resources allocated in the underlay network which can be used to support one or a group of IETF network slice services. In networks where there are multiple NRPs, an SR Policy may be associated with a particular NRP. The association between SR Policy and NRP needs to be specified, so that for service traffic which is steered into the SR Policy, the header of the packets can be augmented with the information associated with the NRP. An SR Policy candidate path can be distributed using BGP SR Policy. This document defines the extensions to BGP SR policy to specify the NRP which the SR Policy candidate path is associated with. | ||||||||||||||||
| draft-dong-pce-pcep-nrp-00.txt | |||||||||||||||||
| Path Computation Element Communication Protocol (PCEP) Extensions for Network Resource Partition (NRP) | |||||||||||||||||
|
This document specifies the extensions to Path Computation Element Communication Protocol (PCEP) to carry Network Resource Partition (NRP) related information in the PCEP messages. The extensions in this document can be used to indicate the NRP-specific constraints and information needed in path computation, path status report and path initialization. | ||||||||||||||||
| draft-dong-spring-sr-4map6-segment-00.txt | |||||||||||||||||
| 4map6 Segment for IPv4 Service delivery over IPv6-only underlay networks | |||||||||||||||||
|
This document defines a new type of segment for Segment Routing, i.e., 4map6 segment, which is a mapping rule-based IPv4/IPv6 conversion function running in PE nodes. This segment can be used for IPv4 service delivery over IPv6-only undelay networks. | ||||||||||||||||
| draft-dong-spring-srv6-inter-layer-programming-05.txt | |||||||||||||||||
| SRv6 for Inter-Layer Network Programming | |||||||||||||||||
|
This document defines a new SRv6 function which can be used for SRv6 based inter-layer network programming. It is a variant of the SRv6 End.X behavior which is called "End.XU". Instead of pointing to an interface with layer-3 adjacency, the End.XU behavior points to an underlay interface which connects to a remote layer-3 node via underlying paths or connections that may be invisible in the L3 topology. | ||||||||||||||||
| draft-draft-li-istn-addressing-requirement-00.txt | |||||||||||||||||
| Problems and Requirements of Addressing in Integrated Space-Terrestrial Network | |||||||||||||||||
|
This document presents a detailed analysis of the problems and requirements of network addressing in "Internet in space" for terrestrial users. It introduces the basics of satellite mega- constellations, terrestrial terminals/ground stations, and their inter-networking. Then it explicitly analyzes how space-terrestrial mobility yeilds challenges for the logical topology, addressing, and their impact on routing. The requirements of addressing in the space-terrestrial network are discussed in detail, including uniqueness, stability, locality, scalability, efficiency and backward compatibility with terrestrial Internet. The problems and requirements of network addressing in space-terrestrial networks are finally outlined. | ||||||||||||||||
| draft-drake-teas-bgp-ls-filter-nrp-00.txt | |||||||||||||||||
| Using BGP-LS Filters to Instanted Network Resource Partitions | |||||||||||||||||
|
Future networks that support advanced services, such as those enabled by 5G mobile networks, envision a set of overlay networks each with different performance and scaling properties. These overlays are known as network slices and are realized over a common underlay network. In the context of IETF technologies, they are known as IETF network slices. In order to support IETF network slicing, as well as to offer enhanced VPN services in general, it is necessary to define a mechanism by which specific resources (buffers, queues, scheduling policies, etc.) of specific network topology components (links and/or nodes) of an underlay network can be used by a specific network slice, VPN, or set of VPNs. These collections of resources are known as Network Resource Partitions (NRPs). This document sets out such a mechanism for use of BGP-LS to construct and operate NRPs in Segment Routing networks. | ||||||||||||||||
| draft-dreibholz-ipv4-flowlabel-37.txt | |||||||||||||||||
| An IPv4 Flowlabel Option | |||||||||||||||||
|
This draft defines an IPv4 option containing a flowlabel that is compatible to IPv6. It is required for simplified usage of IntServ and interoperability with IPv6. | ||||||||||||||||
| draft-dreibholz-rserpool-applic-distcomp-34.txt | |||||||||||||||||
| Applicability of Reliable Server Pooling for Real-Time Distributed Computing | |||||||||||||||||
|
This document describes the applicability of the Reliable Server Pooling architecture to manage real-time distributed computing pools and access the resources of such pools. | ||||||||||||||||
| draft-dreibholz-rserpool-applic-mobility-33.txt | |||||||||||||||||
| Applicability of Reliable Server Pooling for SCTP-Based Endpoint Mobility | |||||||||||||||||
|
This document describes a novel mobility concept based on a combination of SCTP with Dynamic Address Reconfiguration extension and Reliable Server Pooling (RSerPool). | ||||||||||||||||
| draft-dreibholz-rserpool-asap-hropt-32.txt | |||||||||||||||||
| Handle Resolution Option for ASAP | |||||||||||||||||
|
This document describes the Handle Resolution option for the ASAP protocol. | ||||||||||||||||
| draft-dreibholz-rserpool-delay-31.txt | |||||||||||||||||
| Definition of a Delay Measurement Infrastructure and Delay-Sensitive Least-Used Policy for Reliable Server Pooling | |||||||||||||||||
|
This document contains the definition of a delay measurement infrastructure and a delay-sensitive Least-Used policy for Reliable Server Pooling. | ||||||||||||||||
| draft-dreibholz-rserpool-enrp-takeover-29.txt | |||||||||||||||||
| Takeover Suggestion Flag for the ENRP Handle Update Message | |||||||||||||||||
|
This document describes the Takeover Suggestion Flag for the ENRP_HANDLE_UPDATE message of the ENRP protocol. | ||||||||||||||||
| draft-dreibholz-rserpool-nextgen-ideas-19.txt | |||||||||||||||||
| Ideas for a Next Generation of the Reliable Server Pooling Framework | |||||||||||||||||
|
This document collects some idea for a next generation of the Reliable Server Pooling framework. | ||||||||||||||||
| draft-dreibholz-rserpool-score-32.txt | |||||||||||||||||
| Reliable Server Pooling (RSerPool) Bakeoff Scoring | |||||||||||||||||
|
This memo describes some of the scoring to be used in the testing of Reliable Server Pooling protocols ASAP and ENRP at upcoming bakeoffs. | ||||||||||||||||
| draft-dreibholz-taps-neat-socketapi-12.txt | |||||||||||||||||
| NEAT Sockets API | |||||||||||||||||
|
This document describes a BSD Sockets-like API on top of the callback-based NEAT User API. This facilitates porting existing applications to use a subset of NEAT's functionality. | ||||||||||||||||
| draft-dreibholz-tsvwg-sctp-nextgen-ideas-17.txt | |||||||||||||||||
| Ideas for a Next Generation of the Stream Control Transmission Protocol (SCTP) | |||||||||||||||||
|
This document collects some ideas for a next generation of the Stream Control Transmission Protocol (SCTP) for further discussion. It is a result of lessons learned from more than one decade of SCTP deployment. | ||||||||||||||||
| draft-dreibholz-tsvwg-sctpsocket-multipath-26.txt | |||||||||||||||||
| SCTP Socket API Extensions for Concurrent Multipath Transfer | |||||||||||||||||
|
This document describes extensions to the SCTP sockets API for configuring the CMT-SCTP and CMT/RP-SCTP extensions. | ||||||||||||||||
| draft-dreibholz-tsvwg-sctpsocket-sqinfo-26.txt | |||||||||||||||||
| Sender Queue Info Option for the SCTP Socket API | |||||||||||||||||
|
This document describes an extension to the SCTP sockets API for querying information about the sender queue. | ||||||||||||||||
| draft-driscoll-pqt-hybrid-terminology-02.txt | |||||||||||||||||
| Terminology for Post-Quantum Traditional Hybrid Schemes | |||||||||||||||||
|
One aspect of the transition to post-quantum algorithms in cryptographic protocols is the development of hybrid schemes that incorporate both post-quantum and traditional asymmetric algorithms. This document defines terminology for such schemes. It is intended to be used as a reference and, hopefully, to ensure consistency and clarity across different protocols, standards, and organisations. | ||||||||||||||||
| draft-dss-star-02.txt | |||||||||||||||||
| STAR: Distributed Secret Sharing for Private Threshold Aggregation Reporting | |||||||||||||||||
|
Servers often need to collect data from clients that can be privacy- sensitive if the server is able to associate the collected data with a particular user. In this document we describe STAR, an efficient and secure threshold aggregation protocol for collecting measurements from clients by an untrusted aggregation server, while maintaining K-anonymity guarantees. | ||||||||||||||||
| draft-dthaler-rats-endorsements-00.txt | |||||||||||||||||
| RATS Endorsements: CORIM vs EAT | |||||||||||||||||
|
Various formats exist, including standard and vendor-specific formats, for messages in the RATS Architecture. Indeed, one of the purposes of a Verifer is to accept Evidence in a variety of formats and generate Attestation Results in a format needed by a Relying Party. This document discusses considerations around formats for Endorsements, and the suitability of EAT and CORIM as Endorsement formats. | ||||||||||||||||
| draft-du-cats-computing-modeling-description-00.txt | |||||||||||||||||
| Computing Information Description in Computing-Aware Traffic Steering | |||||||||||||||||
|
This document describes the considerations and the potential architecture of the computing information that needs to be notified in the network in Computing-Aware Traffic Steering (CATS). | ||||||||||||||||
| draft-du-coinrg-coordination-on-data-plane-00.txt | |||||||||||||||||
| Data-driven Coordination of Network Devices in Computing in the Network | |||||||||||||||||
|
This document describes a coordinatable mechanism for the network devices in Computing in the Network (COIN). A Flag filed in the packet header is used in the mechanism. It provides a straightforward way to communicate information among the network devices supporting COIN in the network. | ||||||||||||||||
| draft-du-coordination-for-serivce-ip-in-mec-00.txt | |||||||||||||||||
| Coordination for Service IP in Multi-access Edge Computing | |||||||||||||||||
|
This document describes a coordinatable mechanism for the Service IP in Multi-access Edge Computing. The Service IP means that an IP address is associated with a specific service in the network. For example, the IP address is deployed as an anycast address for Computing Aware Networking (CAN). | ||||||||||||||||
| draft-du-coordination-of-networks-in-ccn-00.txt | |||||||||||||||||
| Coordination of Networks in Computing Centric Network | |||||||||||||||||
|
This document describes a coordinatable mechanism for the networks that each contains a service node in the Computing Centric Network (CCN). The CCN stands for an overlay network or called a network federation that focuses on the computing service providing. In CCN, many service nodes in different networks can join in or leave the federation dynamically. | ||||||||||||||||
| draft-du-intarea-service-routing-in-mec-02.txt | |||||||||||||||||
| Service Routing in Multi-access Edge Computing | |||||||||||||||||
|
This document introduces a service routing mechanism in the scenario of Multi-access Edge Computing, in which the server's preferred address mechanism in QUIC can be used. | ||||||||||||||||
| draft-du-programmable-ip-in-iot-network-00.txt | |||||||||||||||||
| Programmable IP Format in IOT Network | |||||||||||||||||
|
This document describes a programmable IP format communication mechanism for the IOT network . | ||||||||||||||||
| draft-duan-bess-mvpn-ipv6-infras-03.txt | |||||||||||||||||
| BGP MVPN in IPv6 Infrastructure Networks: Problems and Solution Approaches | |||||||||||||||||
|
MVPN deployment faces some problems while used in provider's IPv6 infrastructure networks. This document describes these problems, and corresponding solutions. | ||||||||||||||||
| draft-duan-bess-simplified-mvpn-for-bier-and-ir-00.txt | |||||||||||||||||
| Simplified MVPN for BIER and IR | |||||||||||||||||
|
Per RFC6513 and RFC6514, seven MCAST-VPN NLRIs and relevant procedures are defined to build multicast forwarding tree over the service provider backbone. RFC8556 introduces that MVPN can use BIER as PMSI tunnel to perform optimal multicast forwarding. However, the complicated NLRI exchange and the switching from I-PMSI to S-PMSI tunnel is not necessary for BIER and IR tunnel. The architectural advantages of BIER and IR cannot be fully utilized. Therefore, a new simplified MVPN for BIER and IR is proposed to substitute current NLRIs exchange and procedures. This document would like to discuss the value of the MVPN simplification and provide suggestive solution. | ||||||||||||||||
| draft-duffy-csmp-04.txt | |||||||||||||||||
| Cisco's CoAP Simple Management Protocol | |||||||||||||||||
|
CoAP Simple Management Protocol (CSMP) is purpose-built to provide lifecycle management for resource constrained IoT devices deployed within large-scale, bandwidth constrained IoT networks. CSMP offers an efficient transport and message encoding supporting classic NMS functions such as device on-boarding, device configuration, device status reporting, securing the network, etc. This document describes the design and operation of CSMP. This document does not represent an IETF consensus. | ||||||||||||||||
| draft-duke-httpbis-quic-version-alt-svc-02.txt | |||||||||||||||||
| An Alt-Svc Parameter and SvcParamKey for QUIC Versions | |||||||||||||||||
|
HTTP Alternative Services (Alt-Svc) describes how one origin's resource can be accessed via a different protocol/host/port combination. Alternatives are advertised by servers using the Alt- Svc header field or the ALTSVC frame. This includes a protocol name, which reuses Application Layer Protocol Negotiation (ALPN) codepoints. The "h3" codepoint indicates the availability of HTTP/3. A client that uses such an alternative first makes a QUIC connection. However, without a priori knowledge of which QUIC version to use, clients might incur a round-trip latency penalty to complete QUIC version negotiation, or forfeit desirable properties of a QUIC version. This document specifies a new Alt-Svc parameter that specifies alternative supported QUIC versions, which substantially reduces the chance of this penalty. Similarly, clients can retrieve additional instructions about access to services or resources via DNS SVCB and HTTP Resource Records. This document also defines a new SvcParamKey for these Resource Records, which specifies the specific QUIC versions in use. | ||||||||||||||||
| draft-duke-quic-version-aliasing-09.txt | |||||||||||||||||
| QUIC Version Aliasing | |||||||||||||||||
|
The QUIC transport protocol preserves its future extensibility partly by specifying its version number. There will be a relatively small number of published version numbers for the foreseeable future. This document provides a method for clients and servers to negotiate the use of other version numbers in subsequent connections and encrypts Initial Packets using secret keys instead of standard ones. If a sizeable subset of QUIC connections use this mechanism, this should prevent middlebox ossification around the current set of published version numbers and the contents of QUIC Initial packets, as well as improving the protocol's privacy properties. | ||||||||||||||||
| draft-dulaunoy-misp-core-format-16.txt | |||||||||||||||||
| MISP core format | |||||||||||||||||
|
This document describes the MISP core format used to exchange indicators and threat information between MISP (Open Source Threat Intelligence Sharing Platform formerly known as Malware Information Sharing Platform) instances. The JSON format includes the overall structure along with the semantic associated for each respective key. The format is described to support other implementations which reuse the format and ensuring an interoperability with existing MISP [MISP-P] software and other Threat Intelligence Platforms. | ||||||||||||||||
| draft-dunbar-rtgwg-5g-edge-metadata-bgp-usage-00.txt | |||||||||||||||||
| BGP Usage for 5G Edge Computing Service Metadata | |||||||||||||||||
|
This draft describes the problems in the 5G Edge computing environment and how BGP can be used to propagating additional information, so that the ingress routers in the 5G Local Data Network can make path selection not only based on the routing distance but also the running environment of the destinations. The goal is to improve latency and performance for 5G EC services. | ||||||||||||||||
| draft-eap-sha256-srp6a-00.txt | |||||||||||||||||
| EAP SHA256-SRP6a Authentication Protocol | |||||||||||||||||
|
This document describes an authentication protocol intended for Internet applications which may require a robust and non-leaky exchange of credentials even under adverse network conditions. The protocol has the ability to recover from packet loss during the authentication process, as for example, should the Internet application use the UDP transport protocol under lossy network conditions. It does so by allowing the retransmission of lost packets during authentication. The protocol follows the Extensible Authentication Protocol (RFC 3748 and RFC 5247) framework, which allows for the use of multiple authentication mechanisms. It utilizes Secure Remote Password protocol (RFC 2945), with strong, password-based cryptographic hashing. It utilizes the Secure Hashing Algorithm message digest algorithm as the hashing mechanism. The authentication protocol allows for one Server and one or more Clients. Where multiple Clients exist, each may communicate only with the Server. Clients initiate the authentication exchange process. Until the authentication completes successfully, the Server and Client ignore/discard any packets except those supporting the authentication process. The authentication algorithm is based on a username/password or passphrase pair. These are used to generate secure ephemeral keys. The Server has a store of all valid usernames and password hashes. Each Client stores its own username and password. The authentication algorithm provides for each side to prove to the other that it has a valid username/password or passphrase pair, in a way that a third-party monitoring the transactions could not use intercepted information to later successfully authenticate. This mutual authentication exchange consists of several pairs of interactions. The first is a request for authentication by the Client, containing the Client name, to which the Server responds with a challenge for its identity. The Client responds with the Server name for verification purposes. Thereafter, Client and Server each exchange three values consisting of password salts, ephemeral public keys, and hash values. These are generated and verified by Client and Server in accordance with SRP against the stored password/passphrase hashes. While any step in the process may be repeated to provide for dropped packets should a response not be received, the authentication process is terminated by any incorrect value received in any response. Multicast UDP authentication is also supported, with certain limitations. | ||||||||||||||||
| draft-eastlake-6man-hide-options-04.txt | |||||||||||||||||
| Transient Hiding of Hop-by-Hop Options | |||||||||||||||||
|
There are an increasing number of IPv6 hop-by-hop options but such IPv6 options are poorly handled, particularly by high-speed routers in the core Internet where packets having options may be discarded. This document proposes a simple method of transiently hiding such options for part of a packet's path to protect the packet from discard or mishandling. | ||||||||||||||||
| draft-eastlake-bess-enhance-evpn-all-active-10.txt | |||||||||||||||||
| EVPN All Active Usage Enhancement | |||||||||||||||||
|
A principal feature of EVPN is the ability to support multihoming from a customer equipment (CE) to multiple provider edge equipment (PE) active with all-active links. This draft specifies an improvement to load balancing such links. | ||||||||||||||||
| draft-eastlake-bess-evpn-vxlan-bypass-vtep-11.txt | |||||||||||||||||
| EVPN VXLAN Bypass VTEP | |||||||||||||||||
|
A principal feature of EVPN is the ability to support multihoming from a customer equipment (CE) to multiple provider edge equipment (PE) with all-active links. This draft specifies a mechanism to simplify PEs used with VXLAN tunnels and enhance VXLAN Active-Active reliability. | ||||||||||||||||
| draft-eastlake-cturi-08.txt | |||||||||||||||||
| Mapping Between MIME Types,Content-Types,and URIs | |||||||||||||||||
|
Multipurpose Internet Mail Extension (MIME) Content-Type headers, the MIME types used therein, and Uniform Resource Identifiers (URIs) are being used, in different contexts, to label entities. A mapping is specified from each kind of label into the other. This makes it possible to express the meaning of almost any URI or Content-Type in the syntax of the other. | ||||||||||||||||
| draft-eastlake-dnsop-expressing-qos-requirements-02.txt | |||||||||||||||||
| Expressing Quality of Service Requirements (QoS) in Domain Name System (DNS) Queries | |||||||||||||||||
|
A method of encoding quality of communication service (QoS) requirements in a Domain Name System (DNS) query is specified through inclusion of the requirements in one or more labels of the name being queried. This enables DNS responses that are dependent on such requirements without changes in the format of DNS protocol messages or DNS application program interfaces (APIs). | ||||||||||||||||
| draft-eastlake-dnsop-rfc2930bis-tkey-00.txt | |||||||||||||||||
| Secret Key Agreement for DNS (TKEY Resource Record) | |||||||||||||||||
|
RFC 8945 provides a means of efficiently authenticating Domain Name System (DNS) protocol messages using shared secret keys via the TSIG resource record (RR). However, it provides no mechanism for setting up such keys other than manual configuration. This document describes a TKEY RR that can be used in a number of different modes to establish shared secret keys between a DNS resolver and server. This document obsoletes RFC 2930. | ||||||||||||||||
| draft-eastlake-dnsop-rrtype-srv6-03.txt | |||||||||||||||||
| The IPv6 Segment Routing (SRv6) Domain Name System (DNS) Resource Record | |||||||||||||||||
|
A Domain Name System (DNS) Resource Record (RR) Type is specified for storing IPv6 Segment Routing (SRv6) Information in the DNS. | ||||||||||||||||
| draft-eastlake-dnsop-svcb-rr-tunnel-01.txt | |||||||||||||||||
| A Domain Name System (DNS) Service Parameter and Resource Record for Tunneling Information | |||||||||||||||||
|
A Domain Name System (DNS) Service Binding (SVCB) Service Parameter Type and a DNS Resource Record (RR) Type are specified for storing connection tunneling / encapsulation Information in the DNS. | ||||||||||||||||
| draft-eastlake-fnv-19.txt | |||||||||||||||||
| The FNV Non-Cryptographic Hash Algorithm | |||||||||||||||||
|
FNV (Fowler/Noll/Vo) is a fast, non-cryptographic hash algorithm with good dispersion. The purpose of this document is to make information on FNV and open source code performing FNV conveniently available to the Internet community. | ||||||||||||||||
| draft-eastlake-rfc3797bis-02.txt | |||||||||||||||||
| Publicly Verifiable Nominations Committee (NomCom) Random Selection | |||||||||||||||||
|
This document describes a method for making random selections in such a way that the unbiased nature of the choice is publicly verifiable. It focuses on the selection of the voting members of the IETF Nominations Committee (NomCom) from the pool of eligible volunteers; however, similar or, in some cases, identical techniques could be and have been applied to other cases. | ||||||||||||||||
| draft-eastlake-rfc9231bis-xmlsec-uris-00.txt | |||||||||||||||||
| Additional XML Security Uniform Resource Identifiers (URIs) | |||||||||||||||||
|
This document updates and corrects the IANA "XML Security URIs" registry that lists URIs intended for use with XML digital signatures, encryption, canonicalization, and key management. These URIs identify algorithms and types of information. This document also obsoletes RFC 9231. | ||||||||||||||||
| draft-eastlake-secdispatch-tenantid-consid-01.txt | |||||||||||||||||
| Security Considerations for Tenant ID and Similar Fields | |||||||||||||||||
|
Many protocols provide for header fields to be added to a packet on ingress to a network domain and removed on egress from that domain. Examples of such fields are Tenant ID for multi-tenant networks, ingress port ID and/or type, and other identity or handling directive fields. These fields mean that a packet may be accompanied by supplemental information as it transits the network domain that would not be present with the packet or not be visible if it were simply forwarded in a traditional manner. A particular concern is that these fields may harm privacy by identifying, in greater detail, the packet source and intended traffic handling. This document provides Security Considerations for the inclusion of such fields with a packet. | ||||||||||||||||
| draft-eastlake-sfc-parallel-04.txt | |||||||||||||||||
| Service Function Chaining (SFC) Parallelism and Diversions | |||||||||||||||||
|
Service Function Chaining (SFC) is the processing of packets through a sequence of Service Functions (SFs) within an SFC domain by the addition of path information and metadata on entry to that domain, the use and modification of that path information and metadata to step the packet through a sequence of SFs, and the removal of that path information and metadata on exit from that domain. The IETF has standardized a method for SFC using the Network Service Header specified in RFC 8300. There are requirements for SFC to process packets through parallel sequences of service functions and to easily splice in additional service functions or splice service functions out of a service chain. This document provides use cases for these requirements and extensions to SFC to support them. | ||||||||||||||||
| draft-eckel-edm-find-code-02.txt | |||||||||||||||||
| Find Code Related to an Internet-Draft or RFC | |||||||||||||||||
|
Code related to existing IETF standards and ongoing standardization efforts may exist and be publicly accessible in many places. This document provides a set of practices to make it easier to identify and find such code. | ||||||||||||||||
| draft-eckert-anima-grasp-dnssd-04.txt | |||||||||||||||||
| DNS-SD Compatible Service Discovery in GeneRic Autonomic Signaling Protocol (GRASP) | |||||||||||||||||
|
DNS Service Discovery (DNS-SD) defines a framework for applications to announce and discover services. This includes service names, service instance names, common parameters for selecting a service instance (weight or priority) as well as other service-specific parameters. For the specific case of autonomic networks, GeneRic Autonomic Signaling Protocol (GRASP) intends to be used for service discovery in addition to the setup of basic connectivity. Reinventing advanced service discovery for GRASP with a similar set of features as DNS-SD would result in duplicated work. To avoid that, this document defines how to use GRASP to announce and discover services relying upon DNS-SD features while maintaining the intended simplicity of GRASP. To that aim, the document defines name discovery and schemes for reusable elements in GRASP objectives. | ||||||||||||||||
| draft-eckert-anima-services-dns-autoconfig-02.txt | |||||||||||||||||
| Autoconfiguration of infrastructure services in ACP networks via DNS-SD over GRASP | |||||||||||||||||
|
This document defines standards that enable autoconfiguration of fundamental centralized or decentralized network infrastructure services on ACP network nodes via GRASP. These are primarily the services required for initial bootstrapping of a network but will persist through the lifecycles of the network. These services include secure remote access to zero-touch bootstrapped ANI devices via SSH/Netconf with Radius/Diameter authentication and authorization and provides lifecycle autoconfiguration for other crucial services such as syslog, NTP (clock synchronization) and DNS for operational purposes. | ||||||||||||||||
| draft-eckert-bier-rbs-00.txt | |||||||||||||||||
| Recursive BitString Structure (RBS) Addresses for BIER and MSR6 | |||||||||||||||||
|
This memo introduces a compact data-structure representation of multicast trees called "Recursive Bitstring Structure" (RBS) and its use for (stateless) forwarding of packets that include this structure in their header. It is intended as an alternative to "flat" bitstring addresses as used in BIER and BIER-TE or possible forwarding plane variations such as MSR6. RBS aims to improve performance and scalability over flat bitstrings and simplify operations. Operations is simplified because RBS does not require the use, management and optimization of network-wide configured address spaces BIFT-ID and SI and because one common RBS mechanism can replace flat bitstring addresses for both shortest-path forwarding and tree engineered forwarding. It intends to improve performance by allowing multicast to sparse set of receivers in larger networks with fewer packets and it intends to improve scalability by requiring less BIFT state on routers. | ||||||||||||||||
| draft-eckert-detnet-criteria-assessment-00.txt | |||||||||||||||||
| Criteria and Assessment for DetNet Services Forwarding Plane Methods | |||||||||||||||||
|
This memo proposes methods to define, document and assess common criteria for the evaluation of forwarding plane mechanisms intended to be used within the DetNet WG as well as by implementers, operators and vendors that need to compare and select such mechanisms. This document is not intended to become an RFC but does at this point in time soslely intend to help the process of documentation, assessment and comparison. The goals of this memo may change in later revisions. | ||||||||||||||||
| draft-eckert-detnet-tcqf-02.txt | |||||||||||||||||
| Deterministic Networking (DetNet) Data Plane - Tagged Cyclic Queuing and Forwarding (TCQF) for bounded latency with low jitter in large scale DetNets | |||||||||||||||||
|
This memo specifies a forwarding method for bounded latency for Deterministic Networks. It uses cycle tagging of packets for cyclic queuing and forwarding with multiple buffers (TCQF). This memo standardizes tagging via the MPLS packet Traffic Class (TC) field for MPLS links and the IP/IPv6 DSCPfield for IP/IPv6 links. The short- hand for this mechanism is Tagged Cyclic Queuing and Forwarding (TCQF). Target benefits of TCQF include low end-to-end jitter, ease of high- speed hardware implementation, optional ability to support large number of flow in large networks via DiffServ style aggregation by applying TCQF to the DetNet aggregate instead of each DetNet flow individually, and support of wide-area DetNet networks with arbitrary link latencies and latency variations. | ||||||||||||||||
| draft-eckert-ietf-and-energy-overview-04.txt | |||||||||||||||||
| An Overview of Energy-related Effort within the IETF | |||||||||||||||||
|
This memo provides an overview of work performed by or proposed within the IETF related to energy and/or green: awareness, management, control or reduction of consumption of energy, and sustainability as it related to the IETF. This document is written to help those unfamiliar with that work, but interested in it, in the hope to raise more interest in energy- related activities within the IETF, such as identifying gaps and investigating solutions as appropriate. | ||||||||||||||||
| draft-eckert-msr6-problem-statement-00.txt | |||||||||||||||||
| Yet another Problem Statement for IPv6 Multicast Source Routing (MSR6) | |||||||||||||||||
|
This draft summarizes additional personal opinions of the author for why existing stateless multicast solutions BIER/BIER-TE are not sufficient to support the operator, architecture and use-case goals that MSR6 proposes to solve. This document is complementary to problems outlined in I-D.liu-msr6- problem-statement and in no way affects any of them. Instead, it attempts to look more at lower-layer functional challenges of current stateless source routing multicast solutions (BIER/BIER-TE), as well as architectural, network and protocol design ecosystem requirements of operators. | ||||||||||||||||
| draft-eckert-msr6-rbs-01.txt | |||||||||||||||||
| Recursive Bitstring Structure (RBS) for Multicast Source Routing over IPv6 (MSR6) | |||||||||||||||||
|
This document defines an encoding and corresponding packet processing procedures for native IPv6 multicast source routing (MSR6) using a so-called "Recursive Bitstring" (RBS) address structure. The RBS address structure encodes the source-routed multicast tree as a tree of bitstrings. Each router on the tree only needs to examine and perform replication for the one bitstring destined for it. The MSR6/RBS IPv6 extension header encoding and processing is modeled after that of unicast source routing headers, RFC6554 and RFC8754, and shares all elements that can be shared. To support the RBS structure, it is replacing the "Segments Left" pointer to the next segment with two fields to point to the next sub-tree to parse. | ||||||||||||||||
| draft-eckert-pim-rfc1112bis-01.txt | |||||||||||||||||
| Host Extensions for "Any Source" IP Multicasting (ASM) | |||||||||||||||||
|
This memo specifies the extensions required of a host implementation of the Internet Protocol (IP) to support Any Source Multicast (ASM) IP Multicasting or abbreviated IP Multicast. Distribution of this memo is unlimited. | ||||||||||||||||
| draft-edwards-telnet-xon-xoff-state-control-00.txt | |||||||||||||||||
| Xon/Xoff State Control for Telnet Com Port Control Option | |||||||||||||||||
|
This document defines new values for use with the telnet com port control option's SET-CONTROL sub-command defined in RFC2217. These new values provide a mechanism for the telnet client to control and query the outbound Xon/Xoff flow control state of the telnet server's physical serial port. This capability is exposed in the serial port API on some operating systems and is needed by telnet clients that implement a port-redirector service which provides applications local to the redirector/telnet-client with transparent access to the remote serial port on the telnet server. | ||||||||||||||||
| draft-eggert-ietf-and-trust-00.txt | |||||||||||||||||
| The Relationship between the IETF and its Trust | |||||||||||||||||
|
This document describes the expectations the IETF community has on the structure and operation of the IETF Trust. | ||||||||||||||||
| draft-eip-arch-01.txt | |||||||||||||||||
| Extensible In-band Processing (EIP) Architecture and Framework | |||||||||||||||||
|
Extensible In-band Processing (EIP) extends the functionality of the IPv6 protocol considering the needs of future Internet services / 6G networks. This document discusses the architecture and framework of EIP. Two separate documents respectively analyze a number of use cases for EIP and provide the protocol specifications of EIP. | ||||||||||||||||
| draft-elkins-v6ops-eh-deepdive-cdn-01.txt | |||||||||||||||||
| Deep Dive into IPv6 Extension Header Testing: Behind a CDN | |||||||||||||||||
|
This document proposes a methodology for isolating the location and reasons for IPv6 Extension Headers blockage in a network where the operator has access to install products and run diagnostic tests on both the client and server. The client will be outside the Content Delivery Network (CDN) and the server inside the CDN. This document will discuss the testing and topology which need to be considered when testing using a CDN infrastructure. This document is a part of the Deep Dive into EH Testing set of documents. | ||||||||||||||||
| draft-elkins-v6ops-eh-deepdive-fw-01.txt | |||||||||||||||||
| Deep Dive into IPv6 Extension Header Testing | |||||||||||||||||
|
IPv6 Extension Header testing is a complex area. Studies have shown varying results. This document proposes a methodology for isolating the location and reasons for IPv6 Extension Headers blockage. This document outlines the basic framework and set of documents which will follow. | ||||||||||||||||
| draft-evan-amateur-radio-ipv6-04.txt | |||||||||||||||||
| A Method for Deriving Stable IPv6 Interface Identifiers from Amateur Radio Callsigns | |||||||||||||||||
|
This document defines a method for generating stable IPv6 Interface Identifiers for amateur packet radio nodes. This method is meant to be an alternative to hardware address based Interface Identifier generation such that the benefits of stable addressing may be achieved even on nodes that have unstable, changing, or experimental networking hardware. Instead of a physically-derived address, this method utilizes an amateur radio node's government-assigned callsign as the basis for its Interface Identifier. | ||||||||||||||||
| draft-fabbrini-algorithm-post-alien-cryptography-01.txt | |||||||||||||||||
| FC1 Algorithm Ushers In The Era Of Post-Alien Cryptography | |||||||||||||||||
|
This memo aims to introduce the concept of "post-alien cryptography", presenting a symmetric encryption algorithm which, in our opinion, can be considered the first ever designed to face the challenges posed by contact with an alien civilization. FC1 cipher offers an unprecedented grade of confidentiality. Based on the uniqueness of the modular multiplicative inverse of a positive integer a modulo n and on its computability in a polynomial time, this non-deterministic cipher can easily and quickly handle keys of millions or billions of bits that an attacker does not even know the length of. The algorithm's primary key is the modulo, while the ciphertext is given by the concatenation of the modular inverse of blocks of plaintext whose length is randomly chosen within a predetermined range. In addition to the full specification here defined, in a related work we present an implementation of it in Julia Programming Language, accompanied by real examples of encryption and decryption. | ||||||||||||||||
| draft-fabbrini-fc1-a-new-symmetric-key-cipher-01.txt | |||||||||||||||||
| FC1: A Non-Deterministic,Alien-Resistant,Cipher Where The Modulo Is The Symmetric Key | |||||||||||||||||
|
In this paper we describe a symmetric key algorithm that offers an unprecedented grade of confidentiality. Based on the uniqueness of the modular multiplicative inverse of a positive integer a modulo n and on its computability in a polynomial time, this non-deterministic cipher can easily and quickly handle keys of millions or billions of bits that an attacker does not even know the length of. The algorithm's primary key is the modulo, while the ciphertext is given by the concatenation of the modular inverse of blocks of plaintext whose length is randomly chosen within a predetermined range. In addition to the full specification here defined, in a related work we present an implementation of it in Julia Programming Language, accompanied by real examples of encryption and decryption. | ||||||||||||||||
| draft-faibish-iot-ddos-usecases-08.txt | |||||||||||||||||
| Test Tools for IoT DDoS vulnerability scanning | |||||||||||||||||
|
This document specifies several usecases related to the different ways IoT devices are exploited by malicious adversaries to instantiate Distributed Denial of Services (DDoS) attacks. The attacks are generted from IoT devices that have no proper protection against generating unsolicited communication messages targeting a certain network and creating large amounts of network traffic. The attackers take advantage of breaches in the configuration data in unprotected IoT devices exploited for DDoS attacks. The attackers take advantage of the IoT devices that can send network packets that were generated by malicious code that interacts with an OS implementation that runs on the IoT devices. The prupose of this draft is to present possible IoT DDoS usecases that need to be prevented by TEE. The major enabler of such attacks is related to IoT devices that have no OS or unprotected EE OS and run code that is downloaded to them from the TA and modified by man-in-the-middle that inserts malicious code in the OS. This draft adds list of MUD files for most IoT devices. | ||||||||||||||||
| draft-faibish-nfsv4-data-reduction-attributes-08.txt | |||||||||||||||||
| Support for Data Reduction Attributes in nfsv4 Version 2 | |||||||||||||||||
|
This document proposes extending NFSv4 operations to add new RECOMMENDED attributes to be used in the protocol to provide information about the data reduction properties of files. The new data reduction attributes are proposed to allow the client application to communicate to the NFSv4 server data reduction attributes associated with files and directories using new metadata, communicated to the Block Storage data reduction engines. Corresponding new RECOMMENDED attributes are proposed to allow clients and client applications to query the server for data reduction attributes support and allow to get and set data reduction attributes on files and directories. Such data reduction metadata is used as hints to the file server about what type of data reduction to apply. The proposed data reduction attributes include achievable ratios for compression and deduplication plus whether each data reduction technique applies to a file or directory. | ||||||||||||||||
| draft-fairhurst-tsvwg-cc-07.txt | |||||||||||||||||
| Guidelines for Internet Congestion Control at Endpoints | |||||||||||||||||
|
When published as an RFC, this document provides guidance on the design of methods to avoid congestion collapse and how an endpoint needs to react to incipient congestion. The IETF provides recommendations and requirements on this topic that is distributed across many documents in the RFC series. This document therefore gathers and consolidates these recommendations. Based on these, and Internet engineering experience, the document provides best current practice for the design of new congestion control methods in Internet protocols. When published, the document will update or replace the Best Current Practice in BCP 41, which currently includes "Congestion Control Principles" provided in RFC2914. | ||||||||||||||||
| draft-farinacci-lisp-decent-11.txt | |||||||||||||||||
| A Decent LISP Mapping System (LISP-Decent) | |||||||||||||||||
|
This draft describes how the LISP mapping system designed to be distributed for scale can also be decentralized for management and trust. | ||||||||||||||||
| draft-farinacci-lisp-lispers-net-nat-03.txt | |||||||||||||||||
| lispers.net LISP NAT-Traversal Implementation Report | |||||||||||||||||
|
This memo documents the lispers.net implementation of LISP NAT traversal functionality. The document describes message formats and protocol semantics necessary to interoperate with the implementation. | ||||||||||||||||
| draft-farinacci-lisp-mobile-network-16.txt | |||||||||||||||||
| LISP for the Mobile Network | |||||||||||||||||
|
This specification describes how the LISP architecture and protocols can be used in a LTE/5G mobile network to support session survivable EID mobility. A recommendation is provided to SDOs on how to integrate LISP into the mobile network. | ||||||||||||||||
| draft-farinacci-lisp-satellite-network-02.txt | |||||||||||||||||
| LISP for Satellite Networks | |||||||||||||||||
|
This specification describes how the LISP architecture and protocols can be used over satellite network systems. The LISP overlay runs on earth using the satellite network system in space as the underlay. | ||||||||||||||||
| draft-farinacci-lisp-telemetry-09.txt | |||||||||||||||||
| LISP Data-Plane Telemetry | |||||||||||||||||
|
This draft specs a JSON formatted RLOC-record for telemetry data which decapsulating xTRs include in RLOC-probe Map Reply messages. | ||||||||||||||||
| draft-farinacci-pim-gaap-04.txt | |||||||||||||||||
| Group Address Allocation Protocol (GAAP) | |||||||||||||||||
|
This document describes a design for a lightweight decentralized multicast group address allocation protocol (named GAAP and pronounced "gap" as in "mind the gap"). The protocol requires no configuration setup and no centralized services. The protocol runs among group participants which need a unique group address to send and receive multicast packets. | ||||||||||||||||
| draft-farrel-mpls-forwarder-poll-response-01.txt | |||||||||||||||||
| Anonymized Responses to a Poll on MPLS Forwarder Behavior | |||||||||||||||||
|
As part of he work on MPLS Network Actions (MNA) several questions arose concerning how existing MPLS implementations handle Special Purpose Labels (SPLs). The details of MNA protocol extensions may depend on how existing implementations may react when they see those extensions. In order to discover what deployed implementations currently do, the MPLS working group chairs polled participants to answer specific questions. This document is intended to report anonymized answers to that poll. It is not intended that this document should progress to publication as an RFC. | ||||||||||||||||
| draft-farrel-rtgwg-intro-to-semantic-networking-00.txt | |||||||||||||||||
| An Introduction to Semantic Networking | |||||||||||||||||
|
Many proposals have been made to add semantics to IP packets by placing additional information in existing fields, by adding semantics to IP addresses themselves, or by adding fields. The intent is to facilitate enhanced routing/forwarding decisions based on these additional semantics to provide differentiated forwarding paths for different packet flows distinct from simple shortest path first routing. The process is defined as Semantic Networking. This document provides a brief introduction to Semantic Networking. | ||||||||||||||||
| draft-farrell-tls-pemesni-04.txt | |||||||||||||||||
| PEM file format for ECH | |||||||||||||||||
|
Encrypted ClientHello (ECH) key pairs need to be configured into TLS servers, that can be built using different TLS libraries, so there is a benefit and little cost in documenting a file format to use for these key pairs, similar to how RFC7468 defines other PEM file formats. | ||||||||||||||||
| draft-fbnvv-v6ops-site-multihoming-00.txt | |||||||||||||||||
| IPv6 Site connection to many Carriers | |||||||||||||||||
|
Carrier resilience is a typical business requirement. IPv4 deployments have traditionally solved this challenge through private internal site addressing in combination with separate NAT engines attached to multiple redundant carriers. IPv6 brings support for true end-to-end connectivity on the Internet, and hence NAT is the least desirable option in such deployments. Native IPv6 solutions for carrier resiliency, however, have drawbacks. This document discusses all currently-available options to organize carrier resiliency for a site, their strengths and weaknesses, and provides a history of past IETF efforts approaching the issue. The views presented here are the summary of discussions on the v6ops mailing list and are not just the personal opinion of the authors. | ||||||||||||||||
| draft-fdb-rats-psa-endorsements-02.txt | |||||||||||||||||
| A CoRIM Profile for Arm's Platform Security Architecture (PSA) | |||||||||||||||||
|
PSA Endorsements include reference values, endorsed values, cryptographic key material and certification status information that a Verifier may need in order to appraise attestation Evidence produced by a PSA device. This memo defines PSA Endorsements as a profile of the CoRIM data model. | ||||||||||||||||
| draft-feng-opsawg-incident-management-00.txt | |||||||||||||||||
| Incident Management for Network Services | |||||||||||||||||
|
This document provides an architecture for the incident management system and related function interface requirements. This document also defines a YANG module to support the incident lifecycle management. This YANG module is meant to provide a standard way to report, diagnose, and resolve incidents for the sake of enhanced network services. | ||||||||||||||||
| draft-fetch-validation-vmc-wchuang-04.txt | |||||||||||||||||
| Fetch and Validation of Verified Mark Certificates | |||||||||||||||||
|
A description of how entities wishing to validate a Verified Mark Certificate (VMC) should retrieve and validate these documents. This document is a companion to BIMI core specification, which should be consulted alongside this document. | ||||||||||||||||
| draft-filsfils-spring-net-pgm-extension-srv6-usid-14.txt | |||||||||||||||||
| Network Programming extension: SRv6 uSID instruction | |||||||||||||||||
|
The SRv6 "micro segment" (SRv6 uSID or uSID for short) instruction is a straightforward extension of the SRv6 Network Programming model: * The SRv6 Control Plane is leveraged without any change * The SRH dataplane encapsulation is leveraged without any change * Any SID in the SID list can carry micro segments * Based on the Compressed SRv6 Segment List Encoding in SRH | ||||||||||||||||
| draft-filsfils-spring-path-tracing-03.txt | |||||||||||||||||
| Path Tracing in SRv6 networks | |||||||||||||||||
|
Path Tracing provides a record of the packet path as a sequence of interface ids. In addition, it provides a record of end-to-end delay, per-hop delay, and load on each egress interface along the packet delivery path. Path Tracing allows to trace 14 hops with only a 40-bytes IPv6 Hop- by-Hop extension header. Path Tracing supports fine grained timestamp. It has been designed for linerate hardware implementation in the base pipeline. | ||||||||||||||||
| draft-filsfils-spring-path-tracing-srmpls-01.txt | |||||||||||||||||
| Path Tracing in SR-MPLS networks | |||||||||||||||||
|
Path Tracing provides a record of the packet path as a sequence of interface ids. In addition, it provides a record of end-to-end delay, per-hop delay, and load on each interface that forwards the packet. Path Tracing has the lowest MTU overhead compared to alternative proposals such as [INT], [I-D.ietf-ippm-ioam-data], [I-D.song-opsawg-ifit-framework], and [I-D.kumar-ippm-ifa]. Path Tracing supports fine grained timestamp. It has been designed for linerate hardware implementation in the base pipeline. This document defines the Path Tracing specification for the SR-MPLS dataplane. The Path Tracing specification for the SRv6 dataplane is defined in [I-D.filsfils-spring-path-tracing]. | ||||||||||||||||
| draft-filsfils-spring-srv6-net-pgm-insertion-08.txt | |||||||||||||||||
| SRv6 NET-PGM extension: Insertion | |||||||||||||||||
|
Traffic traversing an SR domain is encapsulated in an outer IPv6 header for its journey through the SR domain. To implement transport services strictly within the SR domain, the SR domain may require insertion or deletion of an SRH after the outer IPv6 header of the SR domain. Any segment within the SRH is strictly contained within the SR domain. This document extends SRv6 Network Programming [RFC8986] with new SR endpoint and transit behaviors to be performed only within the SR domain in any packet owned by the domain. | ||||||||||||||||
| draft-filsfils-spring-srv6-stateless-slice-id-07.txt | |||||||||||||||||
| Stateless and Scalable Network Slice Identification for SRv6 | |||||||||||||||||
|
This document defines a stateless and scalable solution to achieve network slicing with SRv6. | ||||||||||||||||
| draft-fizgeer-pce-pcep-bfd-parameters-00.txt | |||||||||||||||||
| PCEP Extensions to support BFD parameters | |||||||||||||||||
|
This document proposes extension to PCEP to configure LSP parameters. Some of LSP parameters are needed to configure S-BFD for candidate paths. Each candidate path is identified in PCEP by its uniquely assigned PLSP-ID. The mechanism proposed in this document is applicable to to all path setup types. The need for these definitions first appeared for Segment Routing path setup type, both MPLS and IPv6 data planes of SR. | ||||||||||||||||
| draft-fluhrer-cfrg-ntru-00.txt | |||||||||||||||||
| NTRU Key Encapsulation | |||||||||||||||||
|
This draft documents NTRU as a post-quantum Key Encapsulation Mechanism (KEM) scheme. The NTRU method from KEM is believed to be IPR free and cryptographically sound for both classical and post- quantum threat environments. NIST has run a competition to select post-quantum primitives and preliminary selected Kyber for standarization as a KEM. Kyber unfortunately has plausible patent claims against it and there are currently undisclosed agreements with the patent holders and NIST. It is unknown whether those agreements would be universally acceptable; if not, there will be organizations for which Kyber is unusable until the patents expire. This lack of clarity around licensing or other restrictions on Kyber has provided the motivation to author this draft. This document does not define any new cryptography, only describes an existing cryptographic system. | ||||||||||||||||
| draft-fluhrer-lms-more-parm-sets-10.txt | |||||||||||||||||
| Additional Parameter sets for HSS/LMS Hash-Based Signatures | |||||||||||||||||
|
This note extends HSS/LMS (RFC 8554) by defining parameter sets by including additional hash functions. These include hash functions that result in signatures with significantly smaller size than the signatures using the current parameter sets, and should have sufficient security. This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF. | ||||||||||||||||
| draft-foglar-ipv6-ull-routing-12.txt | |||||||||||||||||
| IPv6 Source Routing for ultralow Latency | |||||||||||||||||
|
This Internet-Draft describes a hierarchical addressing scheme for IPv6, intentionally very much simplified to allow for ultralow latency source routing experimentation using simple forwarding nodes. Research groups evaluate achievable latency reduction for special applications such as radio access networks, industrial net- works or other networks requiring very low latency. | ||||||||||||||||
| draft-fossati-core-parametrized-cf-01.txt | |||||||||||||||||
| Parametrized Content-Format for CoAP | |||||||||||||||||
|
This document specifies a "parametrized" CoAP Content-Format data item that allows supplementing a Content-Format with additional media type parameters. This document also defines two new CoAP Options, Parmetrized-Content- Format and Parametrized-Multi-Valued-Accept, that build upon the "parametrized" Content-Format data item to work around some of the limitations of the existing Accept and Content-Format Options. | ||||||||||||||||
| draft-fossati-cose-profiles-00.txt | |||||||||||||||||
| COSE Profiles | |||||||||||||||||
|
COSE (STD96) is not an end-to-end system with guaranteed interoperability. It is designed to serve a range of use cases and therefore it has a lot of options. In general, two COSE implementations that want to interoperate require an agreement on which subset of COSE features they will use. This document provides a set of rules for specifying such agreements as "COSE profiles" and registers a new COSE header parameter for in-band signalling of profile information. | ||||||||||||||||
| draft-fossati-tls-attestation-03.txt | |||||||||||||||||
| Using Attestation in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) | |||||||||||||||||
|
Attestation is the process by which an entity produces evidence about itself that another party can use to evaluate the trustworthiness of that entity. In use cases that require the use of remote attestation, such as confidential computing or device onboarding, an attester has to convey evidence or attestation results to a relying party. This information exchange may happen at different layers in the protocol stack. This specification provides a generic way of passing evidence and attestation results in the TLS handshake. Functionality-wise this is accomplished with the help of key attestation. | ||||||||||||||||
| draft-fqdns-no-cache-bouaram-00.txt | |||||||||||||||||
| FQDNs resolution when the MAC and DNS cache are empty | |||||||||||||||||
|
This document specifies the procedures for resolving Fully Qualified Domain Names (FQDNs) in IPv6 and IPv4 networks when both the Media Access Control (MAC) and the Domain Name System (DNS) cache are empty. The procedures aim to reduce the latency and improve the efficiency of FQDN resolution in such scenarios. The procedures described in this document are relevant for both IPv6 and IPv4 networks, and they can be implemented in hosts and routers. | ||||||||||||||||
| draft-francois-grow-bmp-loc-peer-00.txt | |||||||||||||||||
| BMP Loc-RIB: Peer address | |||||||||||||||||
|
BMP Loc-RIB lets a BMP publisher set the Peer Address value of a path information to zero. This document introduces the option to communicate the actual peer from which a path was received when advertising that path with BMP Loc-RIB. | ||||||||||||||||
| draft-francois-nmrg-ai-challenges-02.txt | |||||||||||||||||
| Research Challenges in Coupling Artificial Intelligence and Network Management | |||||||||||||||||
|
This document is intended to introduce the challenges to overcome when network management problems may require to couple with AI solutions. On the one hand, there are many difficult problems in Network Management that to this date have no good solutions, or where any solutions come with significant limitations and constraints. Artificial Intelligence may help produce novel solutions to those problems. On the other hand, for several reasons (computational costs of AI solutions, privacy of data), distribution of AI tasks became primordial. It is thus also expected that network SHOULD be operated efficiently to support those tasks. To identify the right set of challenges, the document defines a method based on the evolution and nature of NM problems. This will be done in parallel with advances and the nature of existing solutions in AI in order to highlight where AI and NM have been already coupled together or could benefit from a higher integration. So, the method aims at evaluating the gap between NM problems and AI solutions. Challenges are derived accordingly, assuming solving these challenges will help to reduce the gap between NM and AI. | ||||||||||||||||
| draft-frank-purchase-exchange-format-01.txt | |||||||||||||||||
| Purchase Exchange Format (PEF) | |||||||||||||||||
|
This document defines the purchase exchange format (PEF), which consists of signed purchase records, to enable sharing, verification, and transfer of information about license ownership. This enables sharing of subscriptions, rentals, and one-time-purchases across platforms as well as deleting or switching accounts of (media) service providers without loosing or double-purchasing products. It can also be applied to non-media items and physical objects like family-shared rentals of tools or proof of purchase for guarantee claims. | ||||||||||||||||
| draft-freed-smtp-limits-04.txt | |||||||||||||||||
| The LIMITS SMTP Service Extension | |||||||||||||||||
|
This document defines a "Limits" extension for the Simple Mail Transfer Protocol (SMTP), including submission, as well as the Local Mail Transfer Protocol (LMTP). It also defines an associated limit registry. This extension provides the means for an SMTP, submission, or LMTP server to inform the client of limits the server intends to apply to the protocol during the current session. The client is then able to adapt its behavior in order to conform to those limits. | ||||||||||||||||
| draft-frost-rats-eat-collection-02.txt | |||||||||||||||||
| Entity Attestation Token (EAT) Collection Type | |||||||||||||||||
|
The default top-level definitions for an EAT [I-D.ietf-rats-eat] assume a hierarchy involving a leading signer within the Attester. Some token use cases do not match that model. This specification defines an extension to EAT allowing the top-level of the token to consist of a collection of otherwise defined tokens. | ||||||||||||||||
| draft-ftbs-rats-msg-wrap-02.txt | |||||||||||||||||
| RATS Conceptual Messages Wrapper | |||||||||||||||||
|
This document defines two encapsulation formats for RATS conceptual messages (i.e., evidence, attestation results, endorsements and reference values.) The first format uses a CBOR or JSON array with two members: one for the type, another for the value. The other format wraps the value in a CBOR byte string and prepends a CBOR tag to convey the type information. | ||||||||||||||||
| draft-fu-bess-evpn-umr-application-00.txt | |||||||||||||||||
| UMR application in Ethernet VPN(EVPN) | |||||||||||||||||
|
This document describes an application scenario that how unknown MAC- route(UMR) is used in the EVPN network. In particular, this document describes how MAC address route and UMR route are advertised on DC's GW or NVE. This document also describes the soloution that MAC mobility issue due to the lack of advertisement of specific MAC routes. However, some incremental work is required, which will be covered in a separate document. | ||||||||||||||||
| draft-fu-computing-resource-notification-domain-00.txt | |||||||||||||||||
| Computing resource notification domain in network | |||||||||||||||||
|
This document introduces the requirements of notification domain definition and the process of service scheduling decision based on the notification domain in the network. | ||||||||||||||||
| draft-fv-rats-ear-00.txt | |||||||||||||||||
| EAT Attestation Results | |||||||||||||||||
|
This document defines the EAT Attestation Result (EAR) message format. EAR is used by a verifier to encode the result of the appraisal over an attester's evidence. It embeds an AR4SI's "trustworthiness vector" to present a normalized view of the evaluation results, thus easing the task of defining and computing authorization policies by relying parties. Alongside the trustworthiness vector, EAR provides contextual information bound to the appraisal process. This allows a relying party (or an auditor) to reconstruct the frame of reference in which the trustworthiness vector was originally computed. EAR supports simple devices with one attester as well as composite devices that are made of multiple attesters, allowing the state of each attester to be separately examined. EAR can also accommodate registered and unregistered extensions. It can be serialized and protected using either CWT or JWT. | ||||||||||||||||
| draft-fz-spring-srv6-alt-mark-05.txt | |||||||||||||||||
| Segment Routing Header encapsulation for Alternate Marking Method | |||||||||||||||||
|
This document describes how the Alternate Marking Method can be used as the passive performance measurement tool in an SRv6 network. It defines how Alternate Marking data fields are transported as part of the Segment Routing with IPv6 data plane (SRv6) header. | ||||||||||||||||
| draft-gandhi-ippm-simple-direct-loss-04.txt | |||||||||||||||||
| Simple Two-Way Direct Loss Measurement Procedure | |||||||||||||||||
|
This document defines Simple Two-Way Direct Loss Measurement (DLM) procedure that can be used for Alternate-Marking Method for detecting accurate data packet loss in a network. Specifically, DLM probe packets are defined for both unauthenticated and authenticated modes and they are efficient for hardware-based implementation. | ||||||||||||||||
| draft-gandhi-mpls-ioam-10.txt | |||||||||||||||||
| MPLS Data Plane Encapsulation for In Situ OAM Data | |||||||||||||||||
|
In Situ Operations, Administration, and Maintenance (IOAM) is used for recording and collecting operational and telemetry information while the packet traverses a path between two points in the network. This document defines how IOAM data fields are transported with MPLS data plane encapsulation using MPLS Network Action (MNA). | ||||||||||||||||
| draft-gandhi-mpls-stamp-pw-03.txt | |||||||||||||||||
| Encapsulation of Simple TWAMP (STAMP) for Pseudowires in MPLS Networks | |||||||||||||||||
|
Pseudowires (PWs) are used in MPLS networks for various services including carrying layer 2 and layer 3 data packets. This document describes the procedure for encapsulation of the Simple Two-Way Active Measurement Protocol (STAMP) defined in RFC 8762 and its optional extensions defined in RFC 8972 for PWs in MPLS networks. The procedure uses PW Generic Associated Channel (G-ACh) to encapsulate the STAMP test packets with or without an IP/UDP header. | ||||||||||||||||
| draft-gandhi-spring-enhanced-srpm-04.txt | |||||||||||||||||
| Enhanced Performance Measurement Using Simple TWAMP in Segment Routing Networks | |||||||||||||||||
|
Segment Routing (SR) leverages the source routing paradigm. SR is applicable to both Multiprotocol Label Switching (SR-MPLS) and IPv6 (SRv6) data planes. This document defines procedure for Enhanced Performance Measurement of end-to-end SR paths including SR Policies for both SR-MPLS and SRv6 data planes using Simple Two-Way Active Measurement Protocol (STAMP) defined in RFC 8762. The procedure allows to improve the scale for number of sessions and the interval for failure detection. | ||||||||||||||||
| draft-gao-flexible-session-protocol-10.txt | |||||||||||||||||
| Flexible Session Protocol | |||||||||||||||||
|
FSP is a connection-oriented transport layer protocol that provides mobility and multihoming support by introducing the concept of 'upper layer thread ID', which is associated with some shared secret that is applied with some authenticated encryption algorithm to protect authenticity of the origin of the FSP packets. It is able to provide following services to the upper layer application: * Stream-oriented send-receive with native message boundary * Flexibility to exploit authenticated encryption * On-the-wire compression * Light-weight session management | ||||||||||||||||
| draft-gao-mpls-teas-rsvpte-state-update-05.txt | |||||||||||||||||
| State-updating mechanism in RSVP-TE for MPLS network | |||||||||||||||||
|
RSVP-TE has the following advantages: source routing capability, and the ability to reserve resources hop by hop along the LSP path. The two advantages are used by Deterministic Networking (DetNet) to provide DetNet Quality of Service (QoS) in a fully distributed control plane utilizing dynamic signaling protocols or in a Combined Control Plane (partly centralized, partly distributed). RSVP takes a "soft state" approach to manage the reservation state in routers and hosts. The use of 'Refresh messages' to cover many possible failures has resulted in a number of operational problems. One problem relates to scaling, another relates to the reliability and latency of RSVP Signaling. This document describes a number of mechanisms that can be used to reduce processing overhead requirements of refresh messages. These extension present no backwards compatibility issues. | ||||||||||||||||
| draft-gazdag-x509-hash-sigs-00.txt | |||||||||||||||||
| Algorithm Identifiers for Hash-based Signatures for Use in the Internet X.509 Public Key Infrastructure | |||||||||||||||||
|
This document specifies algorithm identifiers and ASN.1 encoding formats for the Hash-Based Signature (HBS) schemes Hierarchical Signature System (HSS), eXtended Merkle Signature Scheme (XMSS), and XMSS^MT, a multi-tree variant of XMSS, as well as SPHINCS+, the latter being the only stateless scheme. This specification applies to the Internet X.509 Public Key infrastructure (PKI) when digital signatures are used to sign certificates and certificate revocation lists (CRLs). | ||||||||||||||||
| draft-gcdrb-teas-5g-network-slice-application-02.txt | |||||||||||||||||
| IETF Network Slice Application in 3GPP 5G End-to-End Network Slice | |||||||||||||||||
|
Network Slicing is one of the core features in 5G, which provides different network service as independent logical networks. To provide 5G network slices service, an end-to-end network slice needs to consists of 3 major types of network segments: Radio Access Network (RAN), Mobile Core Network (CN) and Transport Network (TN). This document describes the application of IETF network slice in providing 5G end-to-end network slices, including the network slice identification mapping, network slice parameter mapping and 5G IETF Network Slice NBI. | ||||||||||||||||
| draft-geib-spring-oam-opt-04.txt | |||||||||||||||||
| An MPLS SR OAM option reducing the number of end-to-end path validations | |||||||||||||||||
|
MPLS traceroute implementations validate dataplane connectivity and isolate faults by sending messages along every end-to-end Label Switched Path (LSP) combination between a source and a destination node. This requires a growing number of path validations in networks with a high number of equal cost paths between origin and destination. Segment Routing (SR) introduces MPLS topology awareness combined with Source Routing. By this combination, SR can be used to implement an MPLS traceroute option lowering the total number of LSP validations as compared to commodity MPLS traceroute. | ||||||||||||||||
| draft-geng-detnet-dataplane-enchancment-encap-01.txt | |||||||||||||||||
| DetNet Enhancement Data Plane Encapsulation:Gap Analysis and Solution | |||||||||||||||||
|
This document introduces the Gap Analysis and Solution for DetNet Enhancement Data Plane Encapsulation in order to deploy scalable DetNet Data Plane solution in layer 3 network. | ||||||||||||||||
| draft-geng-idr-bgp-ls-enhanced-detnet-01.txt | |||||||||||||||||
| BGP - Link State (BGP-LS) Advertisement of IGP DetNet Extensions | |||||||||||||||||
|
This document defines extensions to BGP-LS to distribute the enhanced DetNet information | ||||||||||||||||
| draft-geng-idr-bgp-savnet-00.txt | |||||||||||||||||
| BGP Extensions for Source Address Validation Networks (BGP SAVNET) | |||||||||||||||||
|
Many source address validation (SAV) mechanisms have been proposed for preventing source address spoofing. However, existing SAV mechanisms are faced with the problems of inaccurate validation or high operational overhead in some cases. This paper proposes BGP SAVNET by extending BGP protocol for SAV. This protocol can propagate SAV-related information through BGP messages. The propagated information will help routers automatically generate accurate SAV rules which are for checking the validity of data packets. | ||||||||||||||||
| draft-geng-lsr-isis-te-extension-enhanced-detnet-01.txt | |||||||||||||||||
| ISIS-TE Extensions for Enhanced DetNet | |||||||||||||||||
|
This document defines extensions to ISIS to distribute the enhanced DetNet information at node and/or link granularity. | ||||||||||||||||
| draft-geng-msr6-rlb-segment-01.txt | |||||||||||||||||
| RLB (Replication through Local Bitstring) Segment for Multicast Source Routing over IPv6 | |||||||||||||||||
|
This document defines 2 new types of segment: End.RLB.X and End.RLB, and the corresponding packet processing procedures over the IPv6 data plane for the MSR6(Multicast Source Routing over IPv6) TE solutions. | ||||||||||||||||
| draft-geng-msr6-traffic-engineering-02.txt | |||||||||||||||||
| IPv6 Multicast Source Routing Traffic Engineering | |||||||||||||||||
|
This document defines 2 new types of segment: End.RL and End.RL.X , and the corresponding packet processing procedures over the IPv6 data plane for the MSR6(Multicast Source Routing over IPv6) TE solutions. | ||||||||||||||||
| draft-geng-sidrops-rtr-selective-sync-00.txt | |||||||||||||||||
| Selective Synchronization for RPKI to Router Protocol | |||||||||||||||||
|
The RPKI-to-Router (RTR) protocol synchronizes all the verified RPKI data to the router. This document proposes to extend the existing RTR protocol to support selective data synchronization. Selective synchronization can avoid some unnecessary synchronization overhead. The router can obtain only the data that it needs, and does not need to save the data that it does not need. | ||||||||||||||||
| draft-geng-spring-redundancy-policy-05.txt | |||||||||||||||||
| Redundancy Policy for Redundancy Protection | |||||||||||||||||
|
This document introduces a variant of SR Policy called Redundancy Policy, in order to instruct the replication of service packets and assign more than one redundancy forwarding paths used for redundancy protection. | ||||||||||||||||
| draft-geng-spring-sr-enhanced-detnet-01.txt | |||||||||||||||||
| Segment Routing for Enhanced DetNet | |||||||||||||||||
|
One of the goals of DetNet is to provide bounded end-to-end latency for critical flows. This document defines how to leverage Segment Routing(SR) and Segment Routing over IPv6 (SRv6) to implement bounded latency. Specifically, new SRv6 SID function is used to specify bounded latency information for a packet. When forwarding devices along the path follow the instructions carried in the packet, the bounded latency is achieved by different implementations based on bounded latency information. | ||||||||||||||||
| draft-ggalimbe-ccamp-flex-if-lmp-15.txt | |||||||||||||||||
| Extension to the Link Management Protocol (LMP/DWDM -rfc4209) for Dense Wavelength Division Multiplexing (DWDM) Optical Line Systems to manage the application code of optical interface parameters in DWDM application | |||||||||||||||||
|
This experimental memo defines extensions to LMP(rfc4209) for managing Optical parameters associated with Wavelength Division Multiplexing (WDM) adding a set of parameters related to multicarrier DWDM interfaces to be used in Spectrum Switched Optical Networks (sson). | ||||||||||||||||
| draft-ggalimbe-ccamp-flexigrid-carrier-label-14.txt | |||||||||||||||||
| Signaling extensions for Media Channel sub-carriers configuration in Spectrum Switched Optical Networks (SSON) in Lambda Switch Capable (LSC) Optical Line Systems. | |||||||||||||||||
|
This memo defines the signaling extensions for managing Spectrum Switched Optical Network (SSON) parameters shared between the Client and the Network and inside the Network in accordance to the model described in RFC7698. The extensions are in accordance and extending the parameters defined in ITU-T Recommendation G.694.1 and its extensions and G.872. | ||||||||||||||||
| draft-giraltyellamraju-alto-bsg-multidomain-00.txt | |||||||||||||||||
| Bottleneck Structure Graphs in Multidomain Networks: Introduction and Requirements for ALTO | |||||||||||||||||
|
This document proposes an extension to the base Application-Layer Traffic Optimization(ALTO) protocol to support the computation of bottleneck structure graphs [I-D.draft-giraltyellamraju-alto-bsg-requirements] under partial information. A primary application corresponds to the case of multi- domain networks, whereby each network domain is administered separately and lacks information about the other domains. A proposed border protocol is introduced that ensures each domain's independent convergence to the correct bottleneck substructure graph without the need to know private flow and topology information from other domains. Initial discussions are presented on the necessary requirements to integrate the proposed capability into the ALTO standard. | ||||||||||||||||
| draft-gong-lsr-exclusive-link-for-flex-algo-04.txt | |||||||||||||||||
| Advertising Exclusive Links for Flex-Algorithm in IGP | |||||||||||||||||
|
This document proposes the method to advertise exclusive links for Flex-Algorithm in IGP. | ||||||||||||||||
| draft-gong-lsr-ospf-unreachable-link-01.txt | |||||||||||||||||
| Advertising Unreachable Links in OSPF | |||||||||||||||||
|
This document proposes the method to advertise unreachable links in OSPF. | ||||||||||||||||
| draft-gong-teas-hierarchical-slice-solution-01.txt | |||||||||||||||||
| Segment Routing based Solution for Hierarchical IETF Network Slices | |||||||||||||||||
|
This document describes a Segment Routing based solution for two- level hierarchical IETF network slices. Level-1 network slice is realized by associating Flex-Algo with dedicated sub-interfaces, and level-2 network slice is realized by using SR Policy with additional NRP-ID on data plane. | ||||||||||||||||
| draft-gont-numeric-ids-sec-considerations-11.txt | |||||||||||||||||
| Security Considerations for Transient Numeric Identifiers Employed in Network Protocols | |||||||||||||||||
|
Poor selection of transient numerical identifiers in protocols such as the TCP/IP suite has historically led to a number of attacks on implementations, ranging from Denial of Service (DoS) to data injection and information leakage that can be exploited by pervasive monitoring. Due diligence in the specification of transient numeric identifiers is required even when cryptographic techniques are employed, since these techniques might not mitigate all the associated issues. This document formally updates RFC 3552, incorporating requirements for transient numeric identifiers, to prevent flaws in future protocols and implementations. | ||||||||||||||||
| draft-gont-opsec-ipv6-addressing-00.txt | |||||||||||||||||
| Implications of IPv6 Addressing on Security Operations | |||||||||||||||||
|
The increased address availability provided by IPv6 has concrete implications on security operations. This document discusses such implications, and sheds some light on how existing security operations techniques and procedures might need to be modified accommodate the increased IPv6 address availability. | ||||||||||||||||
| draft-gould-dnrd-name-mapping-01.txt | |||||||||||||||||
| Domain Name Registration Data (DNRD) .NAME Object Mapping | |||||||||||||||||
|
This document defines the data escrow structure of depositing objects specific to the .NAME Top Level Domain (TLD) as an extension to the objects deposited with DNRD Objects Mapping. The .NAME TLD-specific objects are Email Forwarding, Defensive Registration, and NameWatch. | ||||||||||||||||
| draft-gould-regext-rdap-versioning-00.txt | |||||||||||||||||
| Versioning in the Registration Data Access Protocol (RDAP) | |||||||||||||||||
|
This document describes an RDAP extension for identifying RDAP extension versions supported by the server, RDAP extension versions included in an RDAP response, and enabling a client to specify the desired RDAP extension versions to include in an RDAP response. | ||||||||||||||||
| draft-grayson-radext-rabble-00.txt | |||||||||||||||||
| RADIUS profile for Bonded Bluetooth Low Energy peripherals | |||||||||||||||||
|
This document specifies an extension to the Remote Authentication Dial-In User Service (RADIUS) protocol that enables a Bluetooth Low Energy (BLE) peripheral device that has previously formed a bonded, secure trusted relationship with a first "home" Bluetooth Low Energy Central device to operate with a second "visited" Bluetooth Low Energy Central device. | ||||||||||||||||
| draft-grothoff-taler-01.txt | |||||||||||||||||
| The 'taler' URI scheme for GNU Taler Wallet interactions | |||||||||||||||||
|
This document defines the 'taler' Uniform Resource Identifier (URI) scheme for triggering interactions with a GNU Taler wallet. This URI scheme allows applications to trigger interactions with the GNU Taler wallet, such as withdrawing money, making payments, receiving refunds and restoring a wallet from a backup. Applications may receive such URIs in many ways (including via NFC, QR codes, Web links or messaging applications), or might generate them internally to interact with a wallet. By having a Taler wallet handle the respective URIs, applications can integrate Taler payments without having to support the Taler protocol directly. Furthermore, by passing control to a Taler wallet process, the wallet's database with its financial data might be better protected from application failures. | ||||||||||||||||
| draft-grubto-dnsop-dns-out-of-protocol-signalling-01.txt | |||||||||||||||||
| DNS Out Of Protocol Signalling | |||||||||||||||||
|
This document seeks to specify a method for name servers to signal programs outside of the name server software, and which are not necessarily involved with the DNS protocol, about conditions that can arise within the name server. These signals can be used to invoke actions in areas that help provide the DNS service, such as routing. Currently this document serves as a requirements document to come to a signalling mechanism that will suit the use cases best. Part of that effort is to assemble a list of conditions with potential associated out of DNS protocol actions, as well as inventory and assess existing signalling mechanisms for suitability. | ||||||||||||||||
| draft-gruessing-moq-requirements-04.txt | |||||||||||||||||
| Media Over QUIC - Use Cases and Requirements for Media Transport Protocol Design | |||||||||||||||||
|
This document describes use cases and requirements that guide the specification of a simple, low-latency media delivery solution for ingest and distribution, using either the QUIC protocol or WebTransport. | ||||||||||||||||
| draft-gudumasu-avtcore-decoder-energy-reduction-00.txt | |||||||||||||||||
| RTP Control Protocol (RTCP) Messages for Decoder Energy Reduction | |||||||||||||||||
|
This document describes an RTCP feedback message format for the second type of green metadata defined by the ISO/IEC International Standard 23001-11, known as Energy Efficient Media Consumption (Green metadata), developed by the ISO/IEC JTC 1/SC 29/WG 3 MPEG System. The RTCP feedback messages specified in this specification is compatible and complimentary with the other draft on green metadata and enables receivers to provide feedback to the senders for decoder power reduction and thus allows feedback-based energy efficient mechanisms to be implemented. The feedback message has broad applicability in real-time video communication services. | ||||||||||||||||
| draft-gudumasu-avtcore-rtp-volumetric-media-roi-00.txt | |||||||||||||||||
| Viewport and Region-of-Interest-Dependent Delivery of Visual Volumetric Media | |||||||||||||||||
|
This document describes RTCP messages and RTP header extensions to enable partial access and support viewport- and region-of-interest- dependent delivery of visual volumetric media such as visual volumetric video-based coding (V3C). Partial access refers to the ability to access retrieve or deliver only a subset of the media content. The RTCP messages and RTP header extensions described in this document are useful for XR services which transport coded visual volumetric content, such as point clouds. | ||||||||||||||||
| draft-gundavelli-dispatch-e911-wifi-00.txt | |||||||||||||||||
| Emergency 911 Services over Wi-Fi | |||||||||||||||||
|
Proposed is an approach for supporting emergency 911 services over IEEE 802.11 based Wi-Fi access networks. This approach leverages the legal framework and the building blocks of the OpenRoaming federation for extending emergency 911 calling support to already deployed tens of thousands of OpenRoaming Wi-Fi hotspots. The proposal addresses the key issues in emergency calling, around discovery and authentication to access network supporting emergency services, emergency access credentials, location determination of the emergency caller, and delivering emergency voice service configuration to the device and call routing. | ||||||||||||||||
| draft-guo-detnet-vpfc-planning-01.txt | |||||||||||||||||
| Deterministic Networking (DetNet) Controller Plane - VPFC Planning Scheme Based on VPFP in Large-scale Deterministic Networks | |||||||||||||||||
|
The cycle-based queuing and forwarding is an effective method to ensure that the transmission has a definite upper bound of jitter, as well as latency. The prerequisite for this method is to ensure that queuing resources do not conflict. In large-scale deterministic networks (LDNs), how to avoid the queuing resources conflict of this method is an open problem. This document presents a scheme of planning virtue periodic forwarding channel (VPFC) based on virtual periodic forwarding path (VPFP) in LDNs. The scheme can solve the queuing resources conflict of cycle-specified queuing and forwarding in nonlinear topology domain, thus ensuring the bounded latency of DetNet flow in the same periodic forwarding domain. | ||||||||||||||||
| draft-guo-ffd-requirement-01.txt | |||||||||||||||||
| Requirement of Fast Fault Detection for IP-based Network | |||||||||||||||||
|
The IP-based distributed system and software application layer often use heartbeat to maintain the network topology status. However, the heartbeat setting is long, which prolongs the system fault detection time. This document describes the requirements for a fast fault detection solution of IP-based network. | ||||||||||||||||
| draft-guo-savnet-enhances-sav-security-00.txt | |||||||||||||||||
| Source Address Validation enhances its security using blockchain | |||||||||||||||||
|
The new Source Address Validation(SAV) mechanism must not introduce additional security vulnerabilities or risks, and the SAV mechanism should ensure the integrity and trusted origin of the protocol packets that deliver the required SAV information. This document explores the use of blockchain technology to enhance the security of the SAV mechanism itself without modifying existing protocols to ensure the accuracy of the generated SAV rules. | ||||||||||||||||
| draft-gutmann-ssh-preauth-00.txt | |||||||||||||||||
| A Pre-Authentication Mechanism for SSH | |||||||||||||||||
|
Devices running SSH are frequently exposed on the Internet, either because of operational considerations or through misconfiguration, making them vulnerable to the constant 3-degree background radiation of scanning and probing attacks that pervade the Internet. This document describes a simple pre-authentication mechanism that limits these attacks with minimal changes to SSH implementations and no changes to the SSH protocol itself. | ||||||||||||||||
| draft-gutmann-testkeys-03.txt | |||||||||||||||||
| Standard PKC Test Keys | |||||||||||||||||
|
This document provides a set of standard PKC test keys that may be used wherever pre-generated keys and associated operations like digitial signatures are required. Like the EICAR virus test and GTUBE spam test files, these publicly-known test keys can be detected and recognised by applications consuming them as being purely for testing purposes without assigning any security properties to them. | ||||||||||||||||
| draft-haas-netmod-unknown-bits-02.txt | |||||||||||||||||
| Representing Unknown YANG bits in Operational State | |||||||||||||||||
|
Protocols frequently have fields where the contents are a series of bits that have specific meaning. When modeling operational state for such protocols in YANG, the 'bits' YANG built-in type is a natural method for modeling such fields. The YANG 'bits' built-in type is best suited when the meaning of a bit assignment is clear. When bits that are currently RESERVED or otherwise unassigned by the protocol are received, being able to model them is necessary in YANG operational models. This cannot be done using the YANG 'bits' built- in type without assigning them a name. However, YANG versioning rules do not permit renaming of named bits. This draft proposes a methodology to represent unknown bits in YANG operational models and creates a YANG typedef to assist in uniformly naming such unknown bits. | ||||||||||||||||
| draft-haase-aucpace-07.txt | |||||||||||||||||
| (strong) AuCPace,an augmented PAKE | |||||||||||||||||
|
This document describes AuCPace which is an augmented PAKE protocol for two parties. The protocol was tailored for constrained devices and smooth migration for compatibility with legacy user credential databases. It is designed to be compatible with any group of both prime- and non-prime order and comes with a security proof providing composability guarantees. | ||||||||||||||||
| draft-haindl-lisp-gb-atn-09.txt | |||||||||||||||||
| Ground-Based LISP for the Aeronautical Telecommunications Network | |||||||||||||||||
|
This document describes the use of the LISP architecture and protocols to address the requirements of the worldwide Aeronautical Telecommunications Network with Internet Protocol Services, as articulated by the International Civil Aviation Organization. The ground-based LISP overlay provides mobility and multi-homing services to the IPv6 networks hosted on commercial aircrafts, to support Air Traffic Management communications with Air Traffic Controllers and Air Operation Controllers. The proposed architecture doesn't require support for LISP protocol in the airborne routers, and can be easily deployed over existing ground infrastructures. | ||||||||||||||||
| draft-halen-fed-tls-auth-05.txt | |||||||||||||||||
| Federated TLS Authentication | |||||||||||||||||
|
This document describes how to establish a secure end-to-end channel between two parties within a federation, where both client and server are mutually authenticated. The trust relationship is based upon a trust anchor held and published by the federation. A federation is a trusted third party that inter-connect different trust domains with a common set of policies and standards. | ||||||||||||||||
| draft-hallambaker-everything-00.txt | |||||||||||||||||
| Mathematical Mesh 3.0 Part X: Everything | |||||||||||||||||
|
https://mailarchive.ietf.org/arch/browse/mathmesh/ (http://whatever)Discussion of this draft should take place on the MathMesh mailing list (mathmesh@ietf.org), which is archived at . | ||||||||||||||||
| draft-hallambaker-jsonbcd-23.txt | |||||||||||||||||
| Binary Encodings for JavaScript Object Notation: JSON-B,JSON-C,JSON-D | |||||||||||||||||
|
Three binary encodings for JavaScript Object Notation (JSON) are presented. JSON-B (Binary) is a strict superset of the JSON encoding that permits efficient binary encoding of intrinsic JavaScript data types. JSON-C (Compact) is a strict superset of JSON-B that supports compact representation of repeated data strings with short numeric codes. JSON-D (Data) supports additional binary data types for integer and floating-point representations for use in scientific applications where conversion between binary and decimal representations would cause a loss of precision. This document is also available online at http://mathmesh.com/Documents/draft-hallambaker-jsonbcd.html. | ||||||||||||||||
| draft-hallambaker-mesh-architecture-21.txt | |||||||||||||||||
| Mathematical Mesh 3.0 Part I: Architecture Guide | |||||||||||||||||
|
The Mathematical Mesh is a Threshold Key Infrastructure that makes computers easier to use by making them more secure. Application of threshold cryptography to key generation and use enables users to make use of public key cryptography across multiple devices with minimal impact on the user experience. This document provides an overview of the Mesh data structures, protocols and examples of its use. [Note to Readers] Discussion of this draft takes place on the MATHMESH mailing list (mathmesh@ietf.org), which is archived at https://mailarchive.ietf.org/arch/search/?email_list=mathmesh. This document is also available online at http://mathmesh.com/Documents/draft-hallambaker-mesh- architecture.html. | ||||||||||||||||
| draft-hallambaker-mesh-callsign-02.txt | |||||||||||||||||
| Mathematical Mesh 3.0 Part VII: Mesh Callsign Service | |||||||||||||||||
|
The Mesh Callsign Registry is a name registry that provides a mapping from human-friendly callsigns to root of trusts and a service assigned by the callsign holder to service the account bound to that callsign. An append only sequence authenticated by means of a Merkle Tree and periodic third party notarizations provides ground truth for the integrity of the registry and for all the assertions enrolled in the sequence. https://mailarchive.ietf.org/arch/browse/mathmesh/ (http://whatever)Discussion of this draft should take place on the MathMesh mailing list (mathmesh@ietf.org), which is archived at . | ||||||||||||||||
| draft-hallambaker-mesh-cryptography-10.txt | |||||||||||||||||
| Mathematical Mesh 3.0 Part VIII: Cryptographic Algorithms | |||||||||||||||||
|
The Mathematical Mesh 'The Mesh' is an infrastructure that facilitates the exchange of configuration and credential data between multiple user devices and provides end-to-end security. This document describes the cryptographic algorithm suites used in the Mesh and the implementation of Multi-Party Encryption and Multi-Party Key Generation used in the Mesh. [Note to Readers] Discussion of this draft takes place on the MATHMESH mailing list (mathmesh@ietf.org), which is archived at https://mailarchive.ietf.org/arch/search/?email_list=mathmesh. This document is also available online at http://mathmesh.com/Documents/draft-hallambaker-mesh- cryptography.html. | ||||||||||||||||
| draft-hallambaker-mesh-dare-16.txt | |||||||||||||||||
| Mathematical Mesh 3.0 Part III : Data At Rest Encryption (DARE) | |||||||||||||||||
|
This document describes the Data At Rest Encryption (DARE) Envelope and Sequence syntax. The DARE Envelope syntax is used to digitally sign, digest, authenticate, or encrypt arbitrary content data. The DARE Sequence syntax describes an append-only sequence of entries, each containing a DARE Envelope. DARE Sequences may support cryptographic integrity verification of the entire data container content by means of a Merkle tree. [Note to Readers] Discussion of this draft takes place on the MATHMESH mailing list (mathmesh@ietf.org), which is archived at https://mailarchive.ietf.org/arch/search/?email_list=mathmesh. This document is also available online at http://mathmesh.com/Documents/draft-hallambaker-mesh-dare.html. | ||||||||||||||||
| draft-hallambaker-mesh-notarization-00.txt | |||||||||||||||||
| Mathematical Mesh 3.0 Part IX: Mesh Notarized Signatures | |||||||||||||||||
|
Creation and verification of Mesh Notarized Signatures is described . A notarized signature is a signature whose time of creation is attested by one or more parties in addition to the signer. In the case of Mesh Notarized Signatures, the attesting parties is the set of all parties participating in a Notarization Mesh. This ideally includes the relying parties. Each participant in a Notarization Mesh maintains their own notary log in the form of a DARE sequence authenticated by a Merkle tree. Participants periodically cross notarize their personal notary log with those maintained by other parties. A Mesh Notarized Signature is bound in time as having being created after time T1 by including one or more sequence apex values as signed attributes. A Mesh Notarized Signature is bound in time as having being created before time T2 by enrolling it in the signer's personal notarization log and engaging in cross-notarization with a sufficient number of Notarization Mesh participants to establish the desired proof. Defection is controlled through an accountability model. If a trusted notary produces multiple inconsistent signed cross Notarization tokens, this provides non-repudiable evidence of a default. https://mailarchive.ietf.org/arch/browse/mathmesh/ (http://whatever)Discussion of this draft should take place on the MathMesh mailing list (mathmesh@ietf.org), which is archived at . | ||||||||||||||||
| draft-hallambaker-mesh-presence-01.txt | |||||||||||||||||
| Mathematical Mesh 3.0 Part XI: Mesh Presence Service | |||||||||||||||||
|
https://mailarchive.ietf.org/arch/browse/mathmesh/ (http://whatever)Discussion of this draft should take place on the MathMesh mailing list (mathmesh@ietf.org), which is archived at . | ||||||||||||||||
| draft-hallambaker-mesh-protocol-14.txt | |||||||||||||||||
| Mathematical Mesh 3.0 Part V: Protocol Reference | |||||||||||||||||
|
The Mathematical Mesh 'The Mesh' is an end-to-end secure infrastructure that facilitates the exchange of configuration and credential data between multiple user devices. The core protocols of the Mesh are described with examples of common use cases and reference data. [Note to Readers] Discussion of this draft takes place on the MATHMESH mailing list (mathmesh@ietf.org), which is archived at https://mailarchive.ietf.org/arch/search/?email_list=mathmesh. This document is also available online at http://mathmesh.com/Documents/draft-hallambaker-mesh-protocol.html. | ||||||||||||||||
| draft-hallambaker-mesh-rud-02.txt | |||||||||||||||||
| Mathematical Mesh 3.0 Part VI: Reliable User Datagram | |||||||||||||||||
|
A presentation layer suitable for use in conjunction with HTTP and UDP transports is described. https://mailarchive.ietf.org/arch/browse/mathmesh/ (http://whatever)Discussion of this draft should take place on the MathMesh mailing list (mathmesh@ietf.org), which is archived at . | ||||||||||||||||
| draft-hallambaker-mesh-schema-11.txt | |||||||||||||||||
| Mathematical Mesh 3.0 Part IV: Schema Reference | |||||||||||||||||
|
The Mathematical Mesh 'The Mesh' is an end-to-end secure infrastructure that facilitates the exchange of configuration and credential data between multiple user devices. The core protocols of the Mesh are described with examples of common use cases and reference data. [Note to Readers] Discussion of this draft takes place on the MATHMESH mailing list (mathmesh@ietf.org), which is archived at https://mailarchive.ietf.org/arch/search/?email_list=mathmesh. This document is also available online at http://mathmesh.com/Documents/draft-hallambaker-mesh-schema.html. | ||||||||||||||||
| draft-hallambaker-mesh-udf-17.txt | |||||||||||||||||
| Mathematical Mesh 3.0 Part II: Uniform Data Fingerprint. | |||||||||||||||||
|
This document describes the underlying naming and addressing schemes used in the Mathematical Mesh. The means of generating Uniform Data Fingerprint (UDF) values and their presentation as text sequences and as URIs are described. A UDF consists of a binary sequence, the initial eight bits of which specify a type identifier code. For convenience, UDFs are typically presented to the user in the form of a Base32 encoded string. Type identifier codes have been selected so as to provide a useful mnemonic indicating their purpose when presented in Base32 encoding. Two categories of UDF are described. Data UDFs provide a compact presentation of a fixed length binary data value in a format that is convenient for data entry. A Data UDF may represent a cryptographic key, a nonce value or a share of a secret. Fingerprint UDFs provide a compact presentation of a Message Digest or Message Authentication Code value. A Strong Internet Name (SIN) consists of a DNS name which contains at least one label that is a UDF fingerprint of a policy document controlling interpretation of the name. SINs allow a direct trust model to be applied to achieve end-to-end security in existing Internet applications without the need for trusted third parties. UDFs may be presented as URIs to form either names or locators for use with the UDF location service. An Encrypted Authenticated Resource Locator (EARL) is a UDF locator URI presenting a service from which an encrypted resource may be obtained and a symmetric key that may be used to decrypt the content. EARLs may be presented on paper correspondence as a QR code to securely provide a machine- readable version of the same content. This may be applied to automate processes such as invoicing or to provide accessibility services for the partially sighted. [Note to Readers] Discussion of this draft takes place on the MATHMESH mailing list (mathmesh@ietf.org), which is archived at https://mailarchive.ietf.org/arch/search/?email_list=mathmesh. This document is also available online at http://mathmesh.com/Documents/draft-hallambaker-mesh-udf.html. | ||||||||||||||||
| draft-hallambaker-threshold-08.txt | |||||||||||||||||
| Threshold Modes in Elliptic Curves | |||||||||||||||||
|
Threshold cryptography operation modes are described with application to the Ed25519, Ed448, X25519 and X448 Elliptic Curves. Threshold key generation allows generation of keypairs to be divided between two or more parties with verifiable security guaranties. Threshold decryption allows elliptic curve key agreement to be divided between two or more parties such that all the parties must co-operate to complete a private key agreement operation. The same primitives may be applied to improve resistance to side channel attacks. A Threshold signature scheme is described in a separate document. https://mailarchive.ietf.org/arch/browse/cfrg/ (http://whatever)Discussion of this draft should take place on the CFRG mailing list (cfrg@irtf.org), which is archived at . | ||||||||||||||||
| draft-hallambaker-web-service-discovery-08.txt | |||||||||||||||||
| DNS Web Service Discovery | |||||||||||||||||
|
This document describes a standardized approach to discovering Web Service Endpoints from a DNS name. Services are advertised using the DNS SRV and TXT records and the HTTP Well Known Service conventions. This document is also available online at http://mathmesh.com/Documents/draft-hallambaker-web-service- discovery.html. | ||||||||||||||||
| draft-halpern-gendispatch-antitrust-05.txt | |||||||||||||||||
| Antitrust Guidelines for IETF Participants | |||||||||||||||||
|
This document provides education and guidance for IETF participants on compliance with antitrust laws and how to reduce antitrust risks in connection with IETF activities. | ||||||||||||||||
| draft-haluska-sipping-directory-assistance-11.txt | |||||||||||||||||
| Considerations for Information Services and Operator Services Using SIP | |||||||||||||||||
|
Information Services are services whereby information is provided in response to user requests, and may include involvement of a human or automated agent. A popular existing Information Service is Directory Assistance (DA). Moving ahead, Information Services providers envision exciting multimedia services that support simultaneous voice and data interactions with full operator backup at any time during the call. Information Services providers are planning to migrate to SIP based platforms, which will enable such advanced services, while continuing to support traditional DA services. Operator Services are traditional PSTN services which often involve providing human or automated assistance to a caller, and often require the specialized capabilities traditionally provided by an operator services switch. Market and/or regulatory factors in some jurisdictions dictate that some subset of Operator Services continue to be provided going forward. This document aims to identify how Operator and Information Services can be implemented using existing or currently proposed SIP mechanisms, to identity existing protocol gaps, and to provide a set of Best Current Practices to facilitate interoperability. For Operator Services, the intention is to describe how current operator services can continue to be provided to PSTN based subscribers via a SIP based operator services architecture. It also looks at how current operator services might be provided to SIP based subscribers via such an architecture, but does not consider the larger question of the need for or usefulness or suitability of each of these services for SIP based subscribers. This document addresses the needs of current Operator and Information Services providers; as such, the intended audience includes vendors of equipment and services to such providers. | ||||||||||||||||
| draft-han-mpls-sdi-sr-04.txt | |||||||||||||||||
| Signal Degrade Indication in Segment Routing over MPLS Network | |||||||||||||||||
|
This document describes a typical use case of MPLS-TP, where signal degrade defect needs to be correctly detected and transmitted via OAM messages within network. When MPLS-TP evolves to Segment Routing MPLS, transit node has no knowledge of labels to be encapsulated in MPLS label stack. Transit node cannot spread OAM messages with signal degrade defect indication. Thus, a solution is proposed in this draft. | ||||||||||||||||
| draft-han-spring-srv6-underlay-tunnel-programming-02.txt | |||||||||||||||||
| SRv6 Underlay tunnel Programming | |||||||||||||||||
|
This document defines a new SRv6 Endpoint behavior which can be used for SRv6 underlay tunnel (e.g.L1 channel) Programming, called END.BXC, this behavior are used to bind an underlay tunnel. | ||||||||||||||||
| draft-happel-sieve-filter-rule-metadata-00.txt | |||||||||||||||||
| Sieve Filter Rule Metadata | |||||||||||||||||
|
This document describes current practices in managing Sieve scripts and proposes a standardized way for storing filter rule metadata in Sieve comments. | ||||||||||||||||
| draft-happel-sml-problem-statement-00.txt | |||||||||||||||||
| Structured Email: Problem Statement and Areas of Work | |||||||||||||||||
|
This document discusses benefits of complementing existing email standards by means that allow to replace or extend text-based email messages with message parts that describe content (full or in parts) in a machine-readable way. This would enable rich and structured interaction for its recipients - may it be human users or agents on their behalf. | ||||||||||||||||
| draft-happel-structured-dynamic-email-00.txt | |||||||||||||||||
| Structured and Dynamic Email | |||||||||||||||||
|
This document outlines the state of the art for adding structured, machine-readable information to email content. It also discusses shortcomings of existing approaches and sketches possible solutions. | ||||||||||||||||
| draft-hardaker-iab-rfc7720-bis-00.txt | |||||||||||||||||
| DNS Root Name Service Protocol and Deployment Requirements | |||||||||||||||||
|
The DNS root name service is a critical part of the Internet architecture. The DNS root name service's DNS protocol and deployment requirements are defined in this document. Operational requirements for the root name service are out of scope. | ||||||||||||||||
| draft-hardjono-sat-architecture-03.txt | |||||||||||||||||
| Secure Asset Transfer (SAT) Interoperability Architecture | |||||||||||||||||
|
This document proposes an interoperability architecture for the secure transfer of assets between two networks or systems based on the gateway model. | ||||||||||||||||
| draft-haresh-sushrut-mib-classification-01.txt | |||||||||||||||||
| SNMPD to use cache and shared database based on MIB Classification | |||||||||||||||||
|
This memo defines classification of SNMP MIBs to either use SNMP cache database and shared database (SDB) mechanism to reduce high CPU usage while SNMP GET REQUEST, GETNEXT REQUEST, GETBULK REQUEST are continuously performed from network management system (NMS)/SNMP manager/SNMP MIB browser to managed device. | ||||||||||||||||
| draft-hargreaves-sat-core-02.txt | |||||||||||||||||
| Secure Asset Transfer Protocol (SATP) | |||||||||||||||||
|
This memo This memo describes the Secure Asset Transfer (SAT) Protocol for digital assets. SAT is a protocol operating between two gateways that conducts the transfer of a digital asset from one gateway to another. The protocol establishes a secure channel between the endpoints and implements a 2-phase commit to ensure the properties of transfer atomicity, consistency, isolation and durability. | ||||||||||||||||
| draft-haynes-nfsv4-layoutwcc-01.txt | |||||||||||||||||
| Add LAYOUT_WCC to NFSv4.2 | |||||||||||||||||
|
The Parallel Network File System (pNFS) Flexible File Layout allows for a file's metadata (MDS) and data (DS) to be on different servers. It does not provide a mechanism for the data server to update the metadata server of changes to the data part of the file. The client has knowledge of such updates, but lacks the ability to update the metadata server. This document presents a refinement to RFC8434 to allow the client to update the metadata server to changes on the data server. | ||||||||||||||||
| draft-haynes-nfsv4-layrec-00.txt | |||||||||||||||||
| Reporting of Errors via LAYOUTRETURN in NFSv4.2 | |||||||||||||||||
|
The Parallel Network File System (pNFS) allows for a file's metadata (MDS) and data (DS) to be on different servers. When the metadata server is restarted, the client can still modify the data file component. During the recovery phase of startup, the metadata server and the data servers work together to recover state (which files are open, last modification time, size, etc). A problem with servers which do client side mirroring there is no means by which the client can report errors to the metadata server. As such, the metadata server has to assume that file needs resilvering. This document presents a refinement to RFC8435 to allow the client to update the metadata | ||||||||||||||||
| draft-hc-lsr-sr-proxy-fw-02.txt | |||||||||||||||||
| LSR for SR Proxy Forwarding | |||||||||||||||||
|
This document describes extensions to OSPF and IS-IS to support SR proxy forwarding mechanism for fast protecting the failure of a node with segments on a SR-TE path. The segments of the node include adjacency, node or binding segments. | ||||||||||||||||
| draft-head-rift-auto-fr-02.txt | |||||||||||||||||
| RIFT Auto-Flood Reflection | |||||||||||||||||
|
This document specifies procedures where RIFT can automatically provision IS-IS Flood Reflection topologies by leveraging its native no-touch ZTP architecture. | ||||||||||||||||
| draft-heejin-domainbasedemailaddressing-00.txt | |||||||||||||||||
| Proposed Specification for Domain-based Email Addressing | |||||||||||||||||
|
This document proposes a new email addressing specification that allows email messages to be sent to all email addresses associated with a domain. The new format can simplify the email addressing process and reduce the risk of errors, while maintaining compatibility with existing email protocols and standards. This specification includes requirements, design, and security considerations for the new email addressing format. | ||||||||||||||||
| draft-hegde-idr-bgpls-ip-flex-algo-bw-con-00.txt | |||||||||||||||||
| BGP-LS extensions for IP Flexible Algorithms and Bandwidth,Delay,Metrics and Constraints | |||||||||||||||||
|
Flexible Algorithm is a mechanism that allows Link state routing protocols (viz. OSPF and IS-IS) to compute paths over a network based on user-defined (and hence, flexible) constraints and metrics. The computation is performed by routers participating in the specific network in a distributed manner using a Flexible Algorithm definition. This definition provisioned on one or more routers and propagated (viz. OSPF and IS- IS flooding) through the network. IP Flex-algo enables these constraint based paths to be built in a network which is purely IP and does not support MPLS or SRv6 forwarding plane. BGP Link-State (BGP-LS) enables the collection of various topology information from the network. This draft defines extensions to BGP- LS address-family to advertise bandwidth, delay and metric related constraints in Flexible algorithm definition. It also defines BGP-LS extensions required to advertise IP flexible algorithm related extensions in BGP-LS. | ||||||||||||||||
| draft-hegde-lsr-ospf-better-idbx-00.txt | |||||||||||||||||
| Improved OSPF Database Exchange Procedure | |||||||||||||||||
|
When an OSPF router undergoes restart, previous instances of LSAs belonging to that router may remain in the databases of other routers in the OSPF domain until such LSAs are aged out. Hence, when the restarting router joins the network again, neighboring routers re- establish adjacencies while the restarting router is still bringing- up its interfaces and adjacencies and generates LSAs with sequence numbers that may be lower than the stale LSAs. Such stale LSAs may be interpreted as bi-directional connectivity before the initial database exchanges are finished and genuine bi-directional LSA connectivity exists. Such incorrect interpretation may lead to, among other thiegs, transient traffic packect drops. This document suggests improvements in the OSPF database exchange process to prevent such problems due to stale LSA utilization. The solution does not preclude changes in the existing standard but presents an extension that will prevent this scenario. | ||||||||||||||||
| draft-hegde-spring-auto-edge-protection-00.txt | |||||||||||||||||
| Auto Edge Protection | |||||||||||||||||
|
This document specifies procedures to automatically establish context based forwarding for providing fast reroute during egress node and egress link failures. It describes how to detect multi-homed services and establish context for forwarding. It also defines procedures to avoid conflicts among routers while establishing context. | ||||||||||||||||
| draft-heitz-idr-wklc-06.txt | |||||||||||||||||
| BGP Well Known Large Community | |||||||||||||||||
|
A range of BGP Autonomous System Numbers is reserved to create a set of BGP Well Known Large Communities. | ||||||||||||||||
| draft-heiwin-intarea-reverse-traceroute-01.txt | |||||||||||||||||
| 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. | ||||||||||||||||
| draft-hendrickson-privacypass-public-metadata-00.txt | |||||||||||||||||
| Public Metadata Issuance | |||||||||||||||||
|
This document specifies a Privacy Pass token type that encodes public metadata visible to the Client, Attester, Issuer, and Origin. | ||||||||||||||||
| draft-henry-madinas-bcp-network-rcm-00.txt | |||||||||||||||||
| Best Current Practices for network services in an RCM context | |||||||||||||||||
|
End devices are implementing Randomized and Changing MAC addresses (RCM), with the advertised goal of improving the user privacy, by making the continued association between a MAC address and a personal device more difficult. RCM may be disruptive to some network services. This document is a collection of best practices for the general implementation of network services within an RCM context. | ||||||||||||||||
| draft-hoehlhubmer-https-addon-07.txt | |||||||||||||||||
| Informational Add-on for HTTP over the Secure Sockets Layer (SSL) Protocol and/or the Transport Layer Security (TLS) Protocol | |||||||||||||||||
|
This document describes an Add-on for websites providing encrypted connectivity (HTTP over TLS). The Add-on has two parts, one for the Domain Name System (DNS) - storing the X.509 certificate hashes - and one for the webserver itself - an additional webpage providing specific informations. | ||||||||||||||||
| draft-hoehrmann-cp-collation-01.txt | |||||||||||||||||
| The i;codepoint collation | |||||||||||||||||
|
This memo describes the "i;codepoint" collation. Character strings are compared based on the Unicode scalar values of the characters. The collation supports equality, substring, and ordering operations. | ||||||||||||||||
| draft-hoffman-rfc-format-framework-as-implemented-02.txt | |||||||||||||||||
| RFC Format Framework As Implemented | |||||||||||||||||
|
RFC 7990 "serves as the framework that provides the problem statement, lays out a road map of the documents that capture the specific requirements, and describes the transition plan" for the format of RFCs. The eventual implementation of the framework happened somewhat differently than was described in RFC 7990. This document describes how the framework was, and is being, implemented. This document makes RFC 7991 obsolete, but does not replace it. | ||||||||||||||||
| draft-hoffman-rfc7990-updates-02.txt | |||||||||||||||||
| Canonical Format for RFCs | |||||||||||||||||
|
This document updates RFC 7990 by changing the definition of the "canonical format" for RFCs. | ||||||||||||||||
| draft-hoffman-rfc7997bis-03.txt | |||||||||||||||||
| The Use of Non-ASCII Characters in RFCs | |||||||||||||||||
|
The RFC Series has evolved to allow for the use of non-ASCII characters in RFCs. While English remains the required language of the Series, the encoding of RFCs is now in UTF-8, allowing for a broader range of characters than typically used in the English language. This document describes requirements and guidelines for the RFC Production Center regarding the use of non-ASCII characters in RFCs. This document updates RFC 7997 to reflect changes in the practices of the RFC series since RFC 7997 was published, and makes further changes based on agreements in the IETF community about what characters are allowed in RFCs. [ A repository for this draft can be found here (https://github.com/ paulehoffman/7997bis). ] | ||||||||||||||||
| draft-hoffmann-gendispatch-policy-stakeholders-00.txt | |||||||||||||||||
| Policy experts are IETF stakeholders | |||||||||||||||||
|
At IETF115 a side meeting on policymaker engagement with the IETF was held. This meeting identified the significance of the IETF’s work for wider societal, economic, and political communities, as well as existing gaps and barriers to engagement for policy experts. This informational draft provides an overview of the side meeting and introduces the problem statement and gap analysis of existing initiatives in this space. It also poses questions we hope to work through with others in the IETF community regarding how to better enable policy expert engagement in IETF standardisation, and on how we can build a culture which better supports technical and policy experts working together to develop more robust standards. | ||||||||||||||||
| draft-hohendorf-secure-sctp-35.txt | |||||||||||||||||
| Secure SCTP | |||||||||||||||||
|
This document explains the reason for the integration of security functionality into SCTP, and gives a short description of S-SCTP and its services. S-SCTP is fully compatible with SCTP defined in RFC4960, it is designed to integrate cryptographic functions into SCTP. | ||||||||||||||||
| draft-homburg-dnsop-codcp-00.txt | |||||||||||||||||
| Control Options For DNS Client Proxies | |||||||||||||||||
|
The introduction of many new transport protocols for DNS in recent years (DoT, DoH, DoQ) significantly increases the complexity of DNS stub resolvers that want to support these protocols. A practical way forward is to have a DNS client proxy in the host operating system. This allows applications to communicate using Do53 and still get the privacy benefit from using more secure protocols over the internet. However, such a setup leaves the application with no control over which transport the proxy uses. This document introduces EDNS(0) options that allow a stub resolver to request certain transport and allow the proxy to report capabilities and actual transports that are available. | ||||||||||||||||
| draft-hong-nmrg-ai-deploy-03.txt | |||||||||||||||||
| Considerations of deploying AI services in a distributed approach | |||||||||||||||||
|
As the development of AI technology matured and AI technology began to be applied in various fields, AI technology is changed from running only on very high-performance servers with small hardware, including microcontrollers, low-performance CPUs and AI chipsets. In this document, we consider how to configure the network and the system in terms of AI inference service to provide AI service in a distributed approach. Also, we describe the points to be considered in the environment where a client connects to a cloud server and an edge device and requests an AI service. | ||||||||||||||||
| draft-hou-tvr-satellite-network-usecases-01.txt | |||||||||||||||||
| Satellite Network Routing Use Cases | |||||||||||||||||
|
Time-Variant Routing (TVR) is chartered and proposed to solve the problem of time-based, scheduled changes, including the variations of links, adjacencies, cost, and traffic volumes in some cases. In a satellite network, the network is in continual motion which will cause detrimental consequences on the routing issue. However, each network node in a satellite network follows a predefined orbit around the Earth and represents an appropriate example of time-based scheduled mobility. Therefore, TVR can be implemented to improve the routing and forwarding process in satellite networks. This document mainly focuses on the use cases in this scenario. | ||||||||||||||||
| draft-howard-gssapi-aead-01.txt | |||||||||||||||||
| AEAD Modes for Kerberos GSS-API | |||||||||||||||||
|
This document updates RFC4121 with support for encryption mechanisms that can authenticate associated data such as Counter with CBC-MAC (CCM) and Galois/Counter Mode (GCM). These mechanisms are often more performant and need not expand the message as much as conventional modes. | ||||||||||||||||
| draft-howard-krb-aead-01.txt | |||||||||||||||||
| AEAD Encryption Types for Kerberos 5 | |||||||||||||||||
|
This document updates RFC3961 to support encryption mechanisms that can authenticate associated data, such as Counter with CBC-MAC (CCM) and Galois/Counter Mode (GCM). These mechanisms are often more performant and need not expand the message as much as conventional modes. | ||||||||||||||||
| draft-hr-spring-intentaware-routing-using-color-01.txt | |||||||||||||||||
| Problem statement for Inter-domain Intent-aware Routing using Color | |||||||||||||||||
|
This draft describes the scope, set of use-cases and requirements for a distributed routing based solution to establish end-to-end intent- aware paths spanning multi-domain packet networks. The document focuses on BGP given its predominant use in inter-domain routing deployments, however the requirements may also apply to other solutions. | ||||||||||||||||
| draft-hsothers-iotsens-ps-03.txt | |||||||||||||||||
| The Need for New Authentication Methods for Internet of Things | |||||||||||||||||
|
In framework of future 6G the need for easy and secure connectivity between a great amount of small devices as sensors and household appliances will be essential. Such massive Internet of Things (mIoT) requires authentication methods which are reliable also in case of vulnerable wireless links and work for simple cheap (dumb) devices. Aim of this document is to lay ground for the need for new authentication models and admission methods in the framework of devices (e.g., machines in IoT communication) within a (wireless or wireline-based) network. Simple devices may only have a minimum amount of physical interfaces available. As an example for establishing an out-of-band channel for exchange of authentication material radio sensing technology may serve. This is currently under investigation for Wireless LAN and upcoming cellular radio at both IEEE and 3GPP. | ||||||||||||||||
| draft-hsyu-message-fragments-01.txt | |||||||||||||||||
| DNS message fragments | |||||||||||||||||
|
This document describes a method to transmit DNS messages over multiple UDP datagrams by fragmenting them at the application layer. The objective is to allow authoriative servers to successfully reply to DNS queries via UDP using multiple smaller datagrams, where larger datagrams may not pass through the network successfully. | ||||||||||||||||
| draft-hu-lsr-igp-link-mtu-00.txt | |||||||||||||||||
| IGP Extensions for Link MTU | |||||||||||||||||
|
Segment routing (SR) leverages the source routing mechanism. It allows for a flexible definition of end-to-end paths within IGP topologies by encoding paths as sequences of topological sub-paths which are called segments. These segments are advertised by the link-state routing protocols (IS-IS and OSPF). Unlike the MPLS, SR does not have the specific path construction signaling so that it cannot support the Path MTU. This draft provides the necessary IS-IS and OSPF extensions about the Path MTU that need to be used on SR. Here, the term "OSPF" means both OSPFv2 and OSPFv3. | ||||||||||||||||
| draft-hu-spring-segment-routing-proxy-forwarding-23.txt | |||||||||||||||||
| SR-TE Path Midpoint Restoration | |||||||||||||||||
|
Segment Routing Traffic Engineering (SR-TE) supports explicit paths using segment lists containing adjacency-SIDs, node-SIDs and binding- SIDs. The current SR FRR such as TI-LFA provides fast re-route protection for the failure of a node along a SR-TE path by the direct neighbor or say point of local repair (PLR) to the failure. However, once the IGP converges, the SR FRR is no longer sufficient to forward traffic of the path around the failure, since the non-neighbors of the failure will no longer have a route to the failed node. This document describes a mechanism for the restoration of the routes to the failure of a SR-MPLS TE path after the IGP converges. It provides the restoration of the routes to an adjacency segment, a node segment and a binding segment of the path. With the restoration of the routes to the failure, the traffic is continuously sent to the neighbor of the failure after the IGP converges. The neighbor as a PLR fast re-routes the traffic around the failure. | ||||||||||||||||
| draft-huang-alto-mowie-for-network-aware-app-05.txt | |||||||||||||||||
| MoWIE for Network Aware Application | |||||||||||||||||
|
With the deployment of 5G networks, cloud-based interactive services such as cloud gaming have gained substantial attention. To ensure users' quality of experience (QoE), a cloud interactive service may require not only high bandwidth (e.g., high-resolution media transmission) but also low delay (e.g., low latency and low lagging). However, the quality perceived by a user with mobile and wireless device may vary, as a function of many factors, and unhandled changes can substantially compromise the user's QoE. In this document, we investigate network-aware applications (NAA), which realize cloud- based interactive services with improved QoE, by efficient utilization of a solution named Mobile and Wireless Information Exposure (MoWIE). In particular, this document demonstrates, through realistic evaluations, that mobile network information such as MCS (Modulation and Coding Scheme) can effectively expose the dynamicity of the underlying network and can be made available to applications through MoWIE; using such an information, the applications can then adapt key control knobs such as media codec schemes, encapsulation, and application layer processing to minimize QoE distortion. Based on the evaluations, we discuss how the MoWIE features can define extensions of the ALTO protocol, to expose more lower-layer and finer grain network dynamics. | ||||||||||||||||
| draft-huang-cats-two-segment-routing-00.txt | |||||||||||||||||
| Hierarchical segment routing solution of CATS | |||||||||||||||||
|
CATS (Computing Aware Traffic Steering) is designed to enable the routing network to be aware of computing status thus deliver the service flow accordingly. Nevertheless, computing and networking is quite different in terms of resource granularity as well as its status stability. It would gain significant benefits to accommodate the computing status to that of networking by employing a hierarchical computing routing segment scheme. The network- accommodated computing status could be maintained at remote CATS nodes while the rest could reside at local CATS nodes. By enabling the network to schedule and route computing services in a compatible way with the current IP routing network, CATS would bring benefits to the industry by both efficiently pooling the computing resources and rendering services through perspective of converged networking and computing. | ||||||||||||||||
| draft-huang-detnet-rdi-00.txt | |||||||||||||||||
| BFD Extension for DetNet Remote Defect Indication (RDI) | |||||||||||||||||
|
This document provides a method of realizing remote defect indication for DetNet OAM. It takes advantage of and extends BFD to explicitly indicate DetNet-specific defects. | ||||||||||||||||
| draft-huang-intarea-san-framework-00.txt | |||||||||||||||||
| Service Aware Network Framework | |||||||||||||||||
|
Cloud has been migrating from concentrated center sites to edge nodes with responsive and agile services to the subscribers. This industry-wide trend would be reasonably expected to continue into the future which would enjoy geographically ubiquitous services. Rather than transmitting service data streams to the stable and limited service locations such as centered cloud sites, routing and forwarding network will have to adapt to the emerging scenarios where the service instances would be highly dynamic and distributed, and further more, demand more fine-grained networking policies than the current routing and forwarding scheme unaware of service SLA requirements. This proposal is to demonstrate a framework under which the above-mentioned requirements would be satisfied. | ||||||||||||||||
| draft-huang-savnet-sav-table-01.txt | |||||||||||||||||
| Source Address Validation Table Abstraction and Application | |||||||||||||||||
|
Source address validation (SAV) table consists of SAV rules that are manually configured or automatically generated. The table will take effect in data plane for checking the validity of source addresses. SAV mechanisms may enable SAV tables in data plane using different methods (e.g., ACL or FIB), and these tables are suitable for different application scenarios. This document aims to provide a systematic view of existing SAV tables, which makes it convenient for engineers or operators to improve existing SAV mechanisms or properly apply SAV on routers. The document first examines existing forms of SAV tables and provides a unified abstraction. Then, three validation modes are concluded as well as suggestions for application scenarios. Finally, diversified actions for each validity state are introduced for compliance of different operation requirements. | ||||||||||||||||
| draft-huang-spring-sr-hsfc-00.txt | |||||||||||||||||
| Hierarchical Service Function Chaining with Segment Routing | |||||||||||||||||
|
SFC offers ordered list of service functions applied to packets, include traditional network service functions and application- specific functions. hSFC defines a hierarchical architecture to deploy SFC in large networks, typically spanning multiple data centers or domains. This document complements RFC 8459 to enable SR-based hSFC. This document specifies and categorizes the interactions between upper- level domains and lower-level sub-domains and appends SR-specific support in constructing hSFC. | ||||||||||||||||
| draft-hui-stub-router-ra-flag-01.txt | |||||||||||||||||
| Stub Router Flag in ICMPv6 Router Advertisement Messages | |||||||||||||||||
|
This document defines a new Stub Router flag in the Router Advertisement message to distinguish configuration information sent by stub routers from infrastructure routers. For example, the Stub Router flag allows stub routers to easily identify when an infrastructure router is advertising a usable IPv6 prefix, triggering the stub router to not advertise its own routable prefix. | ||||||||||||||||
| draft-hunek-v6ops-nat64-srv-04.txt | |||||||||||||||||
| NAT64/DNS64 detection via SRV Records | |||||||||||||||||
|
This document specifies how to discover the NAT64 pools in use and DNS servers providing DNS64 service to the local Nodes. The discovery made via SRV records allows the assignment of priorities to the NAT64 pools and DNS64 servers. It also allows Nodes to have different DNS providers than NAT64 providers while providing a secure way via DNSSEC validation of provided SRV records. This way, it provides DNS64 service regardless of DNS operator and DNS transport protocol. | ||||||||||||||||
| draft-huque-dnsop-compact-lies-01.txt | |||||||||||||||||
| Compact Denial of Existence in DNSSEC | |||||||||||||||||
|
This document describes a technique to generate a signed DNS response on demand for a non-existent name by claiming that the name exists but doesn't have any data for the queried record type. Such answers require only one minimal NSEC record, allow online signing servers to minimize signing operations and response sizes, and prevent zone content disclosure. | ||||||||||||||||
| draft-hurst-sip-quic-00.txt | |||||||||||||||||
| SIP-over-QUIC: Session Initiation Protocol over QUIC Transport | |||||||||||||||||
|
This document describes a mapping of Session Initiation Protocol (SIP) semantics over QUIC Transport. It allows the creation, modification and termination of media sessions with one or more participants, possibly carried over the same QUIC transport connection, using RTP/AVP directly, or some mixture of both. SIP-over-QUIC enables a more efficient use of network resources by introducing field compression to the header fields carried in SIP transactions. | ||||||||||||||||
| draft-hwy-bfd-sdi-02.txt | |||||||||||||||||
| Signal Degrade Indication in BFD | |||||||||||||||||
|
To satisfy the requirements of signal degrade indication described in [I-D.yang-mpls-ps-sdi-sr], this document illustrates the extension of BFD protocol to support signal degrade indication. | ||||||||||||||||
| draft-hwy-opsawg-ifl-framework-02.txt | |||||||||||||||||
| Inband Flow Learning Framework | |||||||||||||||||
|
To deploy the inband performance measurement and flow information telemetry on live traffic, this document proposes a framework of an inband and flow based flow information learning mechanism called Inband Flow Learning (IFL). This document also provides different deployment approaches and considerations in practical network deployment. | ||||||||||||||||
| draft-iab-m-ten-workshop-00.txt | |||||||||||||||||
| Report from the IAB workshop on Management Techniques in Encrypted Networks (M-TEN) | |||||||||||||||||
|
The “Management Techniques in Encrypted Networks (M-TEN)” workshop was convened by the Internet Architecture Board (IAB) from 17 October 2022 to 19 October 2022 as a three-day online meeting. The workshop was organized in three parts to discuss ways to improve network management techniques in support of even broader adoption of encryption on the Internet. This report summarizes the workshop's discussion and identifies topics that warrant future work and consideration. Note that this document is a report on the proceedings of the workshop. The views and positions documented in this report are those of the workshop participants and do not necessarily reflect IAB views and positions. | ||||||||||||||||
| draft-iab-path-signals-collaboration-03.txt | |||||||||||||||||
| Considerations on Application - Network Collaboration Using Path Signals | |||||||||||||||||
|
This document discusses principles for designing mechanisms that use or provide path signals, and calls for standards action in specific valuable cases. RFC 8558 describes path signals as messages to or from on-path elements, and points out that visible information will be used whether it is intended as a signal or not. The principles in this document are intended as guidance for the design of explicit path signals, which are encouraged to be authenticated and include a minimal set of parties to minimize information sharing. These principles can be achieved through mechanisms like encryption of information and establishing trust relationships between entities on a path. | ||||||||||||||||
| draft-iab-privacy-partitioning-01.txt | |||||||||||||||||
| Partitioning as an Architecture for Privacy | |||||||||||||||||
|
This document describes the principle of privacy partitioning, which selectively spreads data and communication across multiple parties as a means to improve the privacy by separating user identity from user data. This document describes emerging patterns in protocols to partition what data and metadata is revealed through protocol interactions, provides common terminology, and discusses how to analyze such models. | ||||||||||||||||
| draft-iab-protocol-maintenance-12.txt | |||||||||||||||||
| Maintaining Robust Protocols | |||||||||||||||||
|
The main goal of the networking standards process is to enable the long term interoperability of protocols. This document describes active protocol maintenance, a means to accomplish that goal. By evolving specifications and implementations, it is possible to reduce ambiguity over time and create a healthy ecosystem. The robustness principle, often phrased as "be conservative in what you send, and liberal in what you accept", has long guided the design and implementation of Internet protocols. However, it has been interpreted in a variety of ways. While some interpretations help ensure the health of the Internet, others can negatively affect interoperability over time. When a protocol is actively maintained, protocol designers and implementers can avoid these pitfalls. | ||||||||||||||||
| draft-iab-ws-environmental-impacts-report-01.txt | |||||||||||||||||
| Report from the IAB Workshop on Environmental Impact of Internet Applications and Systems,2022 | |||||||||||||||||
|
Internet communications and applications have both environmental costs and benefits. The IAB ran an online workshop in December 2022 on exploring and understanding these impacts. The role of the workshop was to discuss the impacts, discuss the evolving needs from industry, and to identify areas for improvements and future work. A key goal of the workshop was to call further attention to the topic and to bring together a diverse stakeholder community to discuss these issues. This report summarises the workshop inputs and discussions. | ||||||||||||||||
| draft-iannone-ip-addressing-considerations-00.txt | |||||||||||||||||
| IP Addressing Considerations | |||||||||||||||||
|
The Internet Protocol (IP) has been the major technological success in information technology of the last half century. As the Internet becomes pervasive, IP has been replacing communication technology for many domain-specific solutions, but it also has been extended to better fit the specificities of the different use cases. For Internet addressing in particular, as it is defined in RFC 791 for IPv4 and RFC 8200 for IPv6, respectively, there exist many extensions. Those extensions have been developed to evolve the addressing capabilities beyond the basic properties of Internet addressing. This document proposes a set of use cases showcasing the continuing need to extend the Internet addressing model and the methods used for doing so. It further outlines the properties of Internet addressing as a baseline against which the extensions are categorized in terms of methodology used to extend the addressing model, together with examples of solutions doing so. The most important aspect of the analysis and discussion in this document is that it represents a snapshot of the discussion that took place in the IETF (on various mailing lists and several meetings) in the early 2020s. While the community did not converge on specific actions to be taken, the content of this document may nonetheless be of use at some point in the future should the community decides so. | ||||||||||||||||
| draft-iannone-routing-and-addressing-manifesto-02.txt | |||||||||||||||||
| Innovation in Internet Routing and Addressing | |||||||||||||||||
|
Despite the stability of the Internet technology, tremendous advances and important innovation are always happening. In particular, routing and addressing have profoundly changed during the years, with interesting research still ongoing and engineers willing to be hear about recent advance that may solve their operational problems. However, researchers and engineers lack a dedicated forum where they can meet and interact to discuss about routing and addressing. This document advocates the creation of such forum, to bring together these communities (researchers and engineers) and offer a dedicated venue. | ||||||||||||||||
| draft-icann-registrar-interfaces-10.txt | |||||||||||||||||
| ICANN Registrar Interfaces | |||||||||||||||||
|
This document describes the interfaces provided by ICANN to Registrars and Data Escrow Agents to fulfill the data escrow requirements of the Registrar Accreditation Agreement and the Registrar Data Escrow Specifications. | ||||||||||||||||
| draft-ietf-6lo-multicast-registration-14.txt | |||||||||||||||||
| IPv6 Neighbor Discovery Multicast and Anycast Address Listener Subscription | |||||||||||||||||
|
This document updates the 6LoWPAN extensions to IPv6 Neighbor Discovery (RFC 8505) to enable a listener to subscribe to an IPv6 anycast or multicast address; the document updates RPL (RFC 6550) to add a new Non-Storing Multicast Mode and a new support for anycast addresses in Storing and Non-Storing Modes. This document extends RFC 9010 to enable the 6LR to inject the anycast and multicast addresses in RPL. | ||||||||||||||||
| draft-ietf-6lo-nfc-22.txt | |||||||||||||||||
| Transmission of IPv6 Packets over Near Field Communication | |||||||||||||||||
|
Near Field Communication (NFC) is a set of standards for smartphones and portable devices to establish radio communication with each other by touching them together or bringing them into proximity, usually no more than 10 cm apart. NFC standards cover communications protocols and data exchange formats, and are based on existing radio-frequency identification (RFID) standards including ISO/IEC 14443 and FeliCa. The standards include ISO/IEC 18092 and those defined by the NFC Forum. The NFC technology has been widely implemented and available in mobile phones, laptop computers, and many other devices. This document describes how IPv6 is transmitted over NFC using 6LoWPAN techniques. | ||||||||||||||||
| draft-ietf-6lo-path-aware-semantic-addressing-00.txt | |||||||||||||||||
| Path-Aware Semantic Addressing (PASA) for Low power and Lossy Networks | |||||||||||||||||
|
This document specifies a topological addressing scheme, Path-Aware Semantic Addressing (PASA) that enables IP packet stateless forwarding. No routing table needs to be built, rather, the forwarding decision is based solely on the destination address structure. This document focuses on carrying IP packets across an LLN (Low power and Lossy Network), in which the topology is static, the location of the nodes is fixed, and the connection between the nodes is also rather stable. This specifications describes the PASA architecture, along with PASA address allocation, forwarding mechanism, header format design, and IPv6 interconnection support. | ||||||||||||||||
| draft-ietf-6lo-schc-15dot4-01.txt | |||||||||||||||||
| Transmission of SCHC-compressed packets over IEEE 802.15.4 networks | |||||||||||||||||
|
A framework called Static Context Header Compression and fragmentation (SCHC) has been designed with the primary goal of supporting IPv6 over Low Power Wide Area Network (LPWAN) technologies [RFC8724]. One of the SCHC components is a header compression mechanism. If used properly, SCHC header compression allows a greater compression ratio than that achievable with traditional 6LoWPAN header compression [RFC6282]. For this reason, it may make sense to use SCHC header compression in some 6LoWPAN environments, including IEEE 802.15.4 networks. This document specifies how a SCHC-compressed packet can be carried over IEEE 802.15.4 networks. The document also enables the transmission of SCHC-compressed UDP/ CoAP headers over 6LoWPAN-compressed IPv6 packets. | ||||||||||||||||
| draft-ietf-6lo-use-cases-16.txt | |||||||||||||||||
| IPv6 over Constrained Node Networks (6lo) Applicability & Use cases | |||||||||||||||||
|
This document describes the applicability of IPv6 over constrained node networks (6lo) and provides practical deployment examples. In addition to IEEE Std 802.15.4, various link layer technologies such as ITU-T G.9959 (Z-Wave), Bluetooth Low Energy (Bluetooth LE), Digital Enhanced Cordless Telecommunications-Ultra Low Energy (DECT- ULE), Master-Slave/Token Passing (MS/TP), Near Field Communication (NFC), and Power Line Communication (PLC) are used as examples. The document targets an audience who would like to understand and evaluate running end-to-end IPv6 over the constrained node networks for local or Internet connectivity. | ||||||||||||||||
| draft-ietf-6man-eh-limits-02.txt | |||||||||||||||||
| Limits on Sending and Processing IPv6 Extension Headers | |||||||||||||||||
|
This specification defines various limits that may be applied to receiving, sending, and otherwise processing packets that contain IPv6 extension headers. The need for such limits is pragmatic to facilitate interoperability amongst hosts and routers in the presence of extension headers and thereby increasing the feasibility of deployment of extension headers. The limits described herein establish the minimum baseline of support for use of extension headers in the Internet. If it is known that all communicating parties for a particular communication, including end hosts and any intermediate nodes in the path, are capable of supporting more than the baseline then these default limits may be freely exceeded. | ||||||||||||||||
| draft-ietf-6man-enhanced-vpn-vtn-id-03.txt | |||||||||||||||||
| Carrying Virtual Transport Network (VTN) Information in IPv6 Extension Header | |||||||||||||||||
|
Virtual Private Networks (VPNs) provide different customers with logically separated connectivity over a common network infrastructure. With the introduction and evolvement of 5G and other network scenarios, some existing or new customers may require connectivity services with advanced characteristics comparing to traditional VPNs. Such kind of network service is called enhanced VPNs (VPN+). VPN+ can be used to deliver IETF network slices, and could also be used for other application scenarios. A Virtual Transport Network (VTN) is a virtual underlay network which consists of a set of dedicated or shared network resources allocated from the physical underlay network, and is associated with a customized logical network topology. VPN+ services can be delivered by mapping one or a group of overlay VPNs to the appropriate VTNs as the virtual underlay. In packet forwarding, some fields in the data packet needs to be used to identify the VTN the packet belongs to, so that the VTN-specific processing can be performed on each node the packet traverses. This document proposes a new Hop-by-Hop option of IPv6 extension header to carry the VTN related information in data packets, which could used to identify the VTN specific processing to be performed on the packets. The procedure of processing the VTN option is also specified. | ||||||||||||||||
| draft-ietf-6man-hbh-processing-07.txt | |||||||||||||||||
| IPv6 Hop-by-Hop Options Processing Procedures | |||||||||||||||||
|
This document specifies procedures for how IPv6 Hop-by-Hop options are processed at routers and hosts. It modifies the procedures specified in the IPv6 Protocol Specification (RFC8200) to make processing of IPv6 Hop-by-Hop options practical with the goal of making IPv6 Hop-by-Hop options useful to deploy and use in the Internet. When published, this document updates RFC8200 and RFC7045. | ||||||||||||||||
| draft-ietf-6man-icmpv6-ioam-conf-state-00.txt | |||||||||||||||||
| IPv6 Query for Enabled In-situ OAM Capabilities | |||||||||||||||||
|
This document describes the IPv6 Node IOAM Information Query functionality, which uses the IPv6 Node Information messages, allowing the IOAM encapsulating node to discover the enabled IOAM capabilities of each IOAM transit and decapsulating node. This document updates RFCs 4620 and 4884. | ||||||||||||||||
| draft-ietf-6man-ipv6-over-wireless-00.txt | |||||||||||||||||
| Architecture and Framework for IPv6 over Non-Broadcast Access | |||||||||||||||||
|
This document presents an architecture for IPv6 access networks that decouples the network-layer concepts of Links, Interface, and Subnets from the link-layer concepts of links, ports, and broadcast domains, and limits the reliance on link-layer broadcasts. This architecture is suitable for IPv6 over any network, including non-broadcast networks. A study of the issues with ND-Classic over wireless media is presented, and a framework to solve those issues within the new architecture is proposed. | ||||||||||||||||
| draft-ietf-6man-rfc6874bis-07.txt | |||||||||||||||||
| Representing IPv6 Zone Identifiers in Address Literals and Uniform Resource Identifiers | |||||||||||||||||
|
This document describes how the zone identifier of an IPv6 scoped address, defined as | ||||||||||||||||
| draft-ietf-6man-sids-03.txt | |||||||||||||||||
| Segment Identifiers in SRv6 | |||||||||||||||||
|
The data plane for Segment Routing over IPv6 (SRv6) is built using IPv6 as the underlying forwarding plane. Due to this underlying use of IPv6, Segment Identifiers (SIDs) used by SRv6 can resemble IPv6 addresses and behave like them while exhibiting slightly different behaviors in some situations. This document explores the characteristics of SRv6 SIDs and to clarify the relationship of SRv6 SIDs to the IPv6 Addressing Architecture. | ||||||||||||||||
| draft-ietf-6man-slaac-renum-05.txt | |||||||||||||||||
| Improving the Robustness of Stateless Address Autoconfiguration (SLAAC) to Flash Renumbering Events | |||||||||||||||||
|
In renumbering scenarios where an IPv6 prefix suddenly becomes invalid, hosts on the local network will continue using stale prefixes for an unacceptably long period of time, thus resulting in connectivity problems. This document improves the reaction of IPv6 Stateless Address Autoconfiguration to such renumbering scenarios. | ||||||||||||||||
| draft-ietf-ace-cmpv2-coap-transport-09.txt | |||||||||||||||||
| CoAP Transfer for the Certificate Management Protocol | |||||||||||||||||
|
This document specifies the use of Constrained Application Protocol (CoAP) as a transfer mechanism for the Certificate Management Protocol (CMP). CMP defines the interaction between various PKI entities for the purpose of certificate creation and management. CoAP is an HTTP-like client-server protocol used by various constrained devices in the IoT space. | ||||||||||||||||
| draft-ietf-ace-edhoc-oscore-profile-01.txt | |||||||||||||||||
| Ephemeral Diffie-Hellman Over COSE (EDHOC) and Object Security for Constrained Environments (OSCORE) Profile for Authentication and Authorization for Constrained Environments (ACE) | |||||||||||||||||
|
This document specifies a profile for the Authentication and Authorization for Constrained Environments (ACE) framework. It utilizes Ephemeral Diffie-Hellman Over COSE (EDHOC) for achieving mutual authentication between an OAuth 2.0 Client and Resource Server, and it binds an authentication credential of the Client to an OAuth 2.0 access token. EDHOC also establishes an Object Security for Constrained RESTful Environments (OSCORE) Security Context, which is used to secure communications when accessing protected resources according to the authorization information indicated in the access token. A resource-constrained server can use this profile to delegate management of authorization information to a trusted host with less severe limitations regarding processing power and memory. | ||||||||||||||||
| draft-ietf-ace-extend-dtls-authorize-07.txt | |||||||||||||||||
| Extension of the Datagram Transport Layer Security (DTLS) Profile for Authentication and Authorization for Constrained Environments (ACE) to Transport Layer Security (TLS) | |||||||||||||||||
|
This document updates the Datagram Transport Layer Security (DTLS) Profile for Authentication and Authorization for Constrained Environments (ACE) specified in RFC 9202 by specifying that the profile applies to Transport Layer Security (TLS) as well as Datagram TLS (DTLS). | ||||||||||||||||
| draft-ietf-ace-key-groupcomm-16.txt | |||||||||||||||||
| Key Provisioning for Group Communication using ACE | |||||||||||||||||
|
This document defines how to use the Authentication and Authorization for Constrained Environments (ACE) framework to distribute keying material and configuration parameters for secure group communication. Candidate group members acting as Clients and authorized to join a group can do so by interacting with a Key Distribution Center (KDC) acting as Resource Server, from which they obtain the keying material to communicate with other group members. While defining general message formats as well as the interface and operations available at the KDC, this document supports different approaches and protocols for secure group communication. Therefore, details are delegated to separate application profiles of this document, as specialized instances that target a particular group communication approach and define how communications in the group are protected. Compliance requirements for such application profiles are also specified. | ||||||||||||||||
| draft-ietf-ace-key-groupcomm-oscore-16.txt | |||||||||||||||||
| Key Management for OSCORE Groups in ACE | |||||||||||||||||
|
This document defines an application profile of the ACE framework for Authentication and Authorization, to request and provision keying material in group communication scenarios that are based on CoAP and are secured with Group Object Security for Constrained RESTful Environments (Group OSCORE). This application profile delegates the authentication and authorization of Clients, that join an OSCORE group through a Resource Server acting as Group Manager for that group. This application profile leverages protocol-specific transport profiles of ACE to achieve communication security, server authentication and proof-of-possession for a key owned by the Client and bound to an OAuth 2.0 Access Token. | ||||||||||||||||
| draft-ietf-ace-mqtt-tls-profile-17.txt | |||||||||||||||||
| Message Queuing Telemetry Transport (MQTT)-TLS profile of Authentication and Authorization for Constrained Environments (ACE) Framework | |||||||||||||||||
|
This document specifies a profile for the ACE (Authentication and Authorization for Constrained Environments) framework to enable authorization in a Message Queuing Telemetry Transport (MQTT)-based publish-subscribe messaging system. Proof-of-possession keys, bound to OAuth2.0 access tokens, are used to authenticate and authorize MQTT Clients. The protocol relies on TLS for confidentiality and MQTT server (Broker) authentication. | ||||||||||||||||
| draft-ietf-ace-oscore-gm-admin-08.txt | |||||||||||||||||
| Admin Interface for the OSCORE Group Manager | |||||||||||||||||
|
Group communication for CoAP can be secured using Group Object Security for Constrained RESTful Environments (Group OSCORE). A Group Manager is responsible to handle the joining of new group members, as well as to manage and distribute the group keying material. This document defines a RESTful admin interface at the Group Manager, that allows an Administrator entity to create and delete OSCORE groups, as well as to retrieve and update their configuration. The ACE framework for Authentication and Authorization is used to enforce authentication and authorization of the Administrator at the Group Manager. Protocol-specific transport profiles of ACE are used to achieve communication security, proof-of- possession and server authentication. | ||||||||||||||||
| draft-ietf-ace-pubsub-profile-06.txt | |||||||||||||||||
| Publish-Subscribe Profile for Authentication and Authorization for Constrained Environments (ACE) | |||||||||||||||||
|
This document defines an application profile for enabling secure group communication for a constrained Publish-Subscribe (pub/sub) scenario, where Publishers and Subscribers communicate through a broker, using the ACE framework. This profile relies on transport layer or application layer security profiles of ACE to achieve communication security, server authentication and proof-of-possession for a key owned by the Client and bound to an OAuth 2.0 Access Token. The document describes how to request and provision keying material for group communication, and protect the content of the pub/sub client message exchange, focusing mainly on the pub/sub scenarios using the Constrained Application Protocol (CoAP) [I-D.ietf-core-coap-pubsub]. | ||||||||||||||||
| draft-ietf-ace-revoked-token-notification-04.txt | |||||||||||||||||
| Notification of Revoked Access Tokens in the Authentication and Authorization for Constrained Environments (ACE) Framework | |||||||||||||||||
|
This document specifies a method of the Authentication and Authorization for Constrained Environments (ACE) framework, which allows an Authorization Server to notify Clients and Resource Servers (i.e., registered devices) about revoked Access Tokens. The method allows Clients and Resource Servers to access a Token Revocation List on the Authorization Server, with the possible additional use of resource observation for the Constrained Application Protocol (CoAP). Resulting (unsolicited) notifications of revoked Access Tokens complement alternative approaches such as token introspection, while not requiring additional endpoints on Clients and Resource Servers. | ||||||||||||||||
| draft-ietf-ace-wg-coap-eap-08.txt | |||||||||||||||||
| EAP-based Authentication Service for CoAP | |||||||||||||||||
|
This document specifies an authentication service that uses the Extensible Authentication Protocol (EAP) transported employing Constrained Application Protocol (CoAP) messages. As such, it defines an EAP lower layer based on CoAP called CoAP-EAP. One of the main goals is to authenticate a CoAP-enabled IoT device (EAP peer) that intends to join a security domain managed by a Controller (EAP authenticator). Secondly, it allows deriving key material to protect CoAP messages exchanged between them based on Object Security for Constrained RESTful Environments (OSCORE), enable the establishment of a security association between them. | ||||||||||||||||
| draft-ietf-acme-ari-01.txt | |||||||||||||||||
| Automated Certificate Management Environment (ACME) Renewal Information (ARI) Extension | |||||||||||||||||
|
This document specifies how an ACME server may provide suggestions to ACME clients as to when they should attempt to renew their certificates. This allows servers to mitigate load spikes, and ensures clients do not make false assumptions about appropriate certificate renewal periods. | ||||||||||||||||
| draft-ietf-acme-authority-token-09.txt | |||||||||||||||||
| ACME Challenges Using an Authority Token | |||||||||||||||||
|
Some proposed extensions to the Automated Certificate Management Environment (ACME) rely on proving eligibility for certificates through consulting an external authority that issues a token according to a particular policy. This document specifies a generic Authority Token challenge for ACME which supports subtype claims for different identifiers or namespaces that can be defined separately for specific applications. | ||||||||||||||||
| draft-ietf-acme-authority-token-tnauthlist-13.txt | |||||||||||||||||
| TNAuthList profile of ACME Authority Token | |||||||||||||||||
|
This document defines a profile of the Automated Certificate Management Environment (ACME) Authority Token for the automated and authorized creation of certificates for VoIP Telephone Providers to support Secure Telephony Identity (STI) using the TNAuthList defined by STI certificates. | ||||||||||||||||
| draft-ietf-acme-client-06.txt | |||||||||||||||||
| ACME End User Client and Code Signing Certificates | |||||||||||||||||
|
Automated Certificate Management Environment (ACME) core protocol addresses the use case of web server certificates for TLS. This document extends the ACME protocol to support end user client, device client, and code signing certificates. | ||||||||||||||||
| draft-ietf-acme-dns-account-01-01.txt | |||||||||||||||||
| Automated Certificate Management Environment (ACME) DNS Labeled With ACME Account ID Challenge | |||||||||||||||||
|
This document outlines a new challenge for the ACME protocol, enabling an ACME client to answer a domain control validation challenge from an ACME server using a DNS resource linked to the ACME Account ID. This allows multiple systems or environments to handle challenge-solving for a single domain. | ||||||||||||||||
| draft-ietf-acme-dtnnodeid-10.txt | |||||||||||||||||
| Automated Certificate Management Environment (ACME) Delay-Tolerant Networking (DTN) Node ID Validation Extension | |||||||||||||||||
|
This document specifies an extension to the Automated Certificate Management Environment (ACME) protocol which allows an ACME server to validate the Delay-Tolerant Networking (DTN) Node ID for an ACME client. The DTN Node ID is encoded as a certificate Subject Alternative Name (SAN) of type otherName with a name form of BundleEID and as an ACME Identifier type "bundleEID". | ||||||||||||||||
| draft-ietf-acme-integrations-13.txt | |||||||||||||||||
| ACME Integrations for Device Certificate Enrollment | |||||||||||||||||
|
This document outlines multiple advanced use cases and integrations that ACME facilitates without any modifications or enhancements required to the base ACME specification. The use cases include ACME integration with EST, BRSKI and TEAP. | ||||||||||||||||
| draft-ietf-acme-subdomains-07.txt | |||||||||||||||||
| Automated Certificate Management Environment (ACME) for Subdomains | |||||||||||||||||
|
This document specifies how Automated Certificate Management Environment (ACME) can be used by a client to obtain a certificate for a subdomain identifier from a certification authority. This document specifies how a client can fulfill a challenge against an ancestor domain but may not need to fulfill a challenge against the explicit subdomain if certification authority policy allows issuance of the subdomain certificate without explicit subdomain ownership proof. | ||||||||||||||||
| draft-ietf-add-ddr-10.txt | |||||||||||||||||
| Discovery of Designated Resolvers | |||||||||||||||||
|
This document defines Discovery of Designated Resolvers (DDR), a mechanism for DNS clients to use DNS records to discover a resolver's encrypted DNS configuration. An encrypted DNS resolver discovered in this manner is referred to as a "Designated Resolver". This mechanism can be used to move from unencrypted DNS to encrypted DNS when only the IP address of a resolver is known. This mechanism is designed to be limited to cases where unencrypted DNS resolvers and their designated resolvers are operated by the same entity or cooperating entities. It can also be used to discover support for encrypted DNS protocols when the name of an encrypted DNS resolver is known. | ||||||||||||||||
| draft-ietf-add-dnr-15.txt | |||||||||||||||||
| DHCP and Router Advertisement Options for the Discovery of Network-designated Resolvers (DNR) | |||||||||||||||||
|
The document specifies new DHCP and IPv6 Router Advertisement options to discover encrypted DNS resolvers (e.g., DNS-over-HTTPS, DNS-over- TLS, DNS-over-QUIC). Particularly, it allows a host to learn an authentication domain name together with a list of IP addresses and a set of service parameters to reach such encrypted DNS resolvers. | ||||||||||||||||
| draft-ietf-add-resolver-info-01.txt | |||||||||||||||||
| DNS Resolver Information | |||||||||||||||||
|
This document specifies a method for DNS resolvers to publish information about themselves. DNS clients can use the resolver information to identify the capabilities of DNS resolvers. How such an information is then used by DNS clients is out of the scope of the document. | ||||||||||||||||
| draft-ietf-add-split-horizon-authority-04.txt | |||||||||||||||||
| Establishing Local DNS Authority in Validated Split-Horizon Environments | |||||||||||||||||
|
When split-horizon DNS is deployed by a network, certain domains can be resolved authoritatively by the network-provided DNS resolver. DNS clients that don't always use this resolver might wish to do so for these domains. This specification defines a mechanism for domain owners to inform clients about local resolvers that are authorized to answer authoritatively for certain subdomains. | ||||||||||||||||
| draft-ietf-add-svcb-dns-08.txt | |||||||||||||||||
| Service Binding Mapping for DNS Servers | |||||||||||||||||
|
The SVCB DNS resource record type expresses a bound collection of endpoint metadata, for use when establishing a connection to a named service. DNS itself can be such a service, when the server is identified by a domain name. This document provides the SVCB mapping for named DNS servers, allowing them to indicate support for encrypted transport protocols. | ||||||||||||||||
| draft-ietf-alto-new-transport-07.txt | |||||||||||||||||
| The ALTO Transport Information Publication Service | |||||||||||||||||
|
The ALTO Protocol (RFC 7285) leverages HTTP/1.x and is designed for the simple, sequential request-reply use case, in which an ALTO client requests a sequence of information resources, and the server responds with the complete content of each resource one at a time. ALTO incremental updates using Server-Sent Events (SSE) (RFC 8895) defines a multiplexing protocol on top of HTTP/1.x, so that an ALTO server can incrementally push resource updates to clients whenever monitored network information resources change, allowing the clients to monitor multiple resources at the same time. However, HTTP/2 and later versions already support concurrent, non-blocking transport of multiple streams in the same HTTP connection. To take advantage of newer HTTP features, this document introduces the ALTO Transport Information Publication Service (TIPS). TIPS uses an incremental RESTful design to give an ALTO client the new capability to explicitly, concurrently (non-blocking) request (pull) specific incremental updates using native HTTP/2 or HTTP/3, while still functioning for HTTP/1.x. TIPS also provides an ALTO server to concurrently push specific incremental updates using native HTTP/2 or HTTP/3 server push. | ||||||||||||||||
| draft-ietf-alto-oam-yang-06.txt | |||||||||||||||||
| YANG Data Models for the Application-Layer Traffic Optimization (ALTO) Protocol | |||||||||||||||||
|
This document defines YANG data models for Operations, Administration, and Maintenance (OAM) & Management of Application- Layer Traffic Optimization (ALTO) Protocol. The operator can use these data models to set up an ALTO server, create, update and remove ALTO information resources, manage the access control, configure server discovery, and collect statistical data. | ||||||||||||||||
| draft-ietf-alto-performance-metrics-28.txt | |||||||||||||||||
| ALTO Performance Cost Metrics | |||||||||||||||||
|
The cost metric is a basic concept in Application-Layer Traffic Optimization (ALTO), and different applications may use different types of cost metrics. Since the ALTO base protocol (RFC 7285) defines only a single cost metric (namely, the generic "routingcost" metric), if an application wants to issue a cost map or an endpoint cost request in order to identify a resource provider that offers better performance metrics (e.g., lower delay or loss rate), the base protocol does not define the cost metric to be used. This document addresses this issue by extending the specification to provide a variety of network performance metrics, including network delay, delay variation (a.k.a, jitter), packet loss rate, hop count, and bandwidth. There are multiple sources (e.g., estimation based on measurements or service-level agreement) to derive a performance metric. This document introduces an additional "cost-context" field to the ALTO "cost-type" field to convey the source of a performance metric. | ||||||||||||||||
| draft-ietf-anima-brski-ae-04.txt | |||||||||||||||||
| BRSKI-AE: Alternative Enrollment Protocols in BRSKI | |||||||||||||||||
|
This document defines an enhancement of Bootstrapping Remote Secure Key Infrastructure (BRSKI, RFC 8995) that supports alternative certificate enrollment protocols, such as CMP. This offers the following advantages. Using authenticated self-contained signed objects for certification requests and responses, their origin can be authenticated independently of message transfer. This supports end-to-end authentication (proof of origin) also over multiple hops, as well as asynchronous operation of certificate enrollment. This in turn provides architectural flexibility where to ultimately authenticate and authorize certification requests while retaining full-strength integrity and authenticity of certification requests. | ||||||||||||||||
| draft-ietf-anima-brski-cloud-05.txt | |||||||||||||||||
| BRSKI Cloud Registrar | |||||||||||||||||
|
This document specifies the behavior of a BRSKI Cloud Registrar, and how a pledge can interact with a BRSKI Cloud Registrar when bootstrapping. RFCED REMOVE: It is being actively worked on at https://github.com/ anima-wg/brski-cloud | ||||||||||||||||
| draft-ietf-anima-brski-prm-08.txt | |||||||||||||||||
| BRSKI with Pledge in Responder Mode (BRSKI-PRM) | |||||||||||||||||
|
This document defines enhancements to Bootstrapping a Remote Secure Key Infrastructure (BRSKI) [RFC8995] to enable bootstrapping in domains featuring no or only limited connectivity between a pledge and the domain registrar. It specifically changes the interaction model from a pledge-initiated mode, as used in BRSKI, to a pledge- responding mode, where the pledge is in server role. For this, BRSKI with Pledge in Responder Mode (BRSKI-PRM) introduces 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 domain CA. | ||||||||||||||||
| draft-ietf-anima-constrained-join-proxy-13.txt | |||||||||||||||||
| Constrained Join Proxy for Bootstrapping Protocols | |||||||||||||||||
|
This document extends the work of Bootstrapping Remote Secure Key Infrastructures (BRSKI) by replacing the (stateful) TLS Circuit proxy between Pledge and Registrar with a stateless or stateful Circuit proxy using CoAP which is called the constrained Join Proxy. The constrained Join Proxy is a mesh neighbor of the Pledge and can relay a DTLS session originating from a Pledge with only link-local addresses to a Registrar which is not a mesh neighbor of the Pledge. Like the BRSKI Circuit proxy, this constrained Join Proxy eliminates the need of Pledges to have routeable IP addresses before enrolment by utilizing link-local addresses. Use of the constrained Join Proxy also eliminates the need of the Pledge to authenticate to the network or perform network-wide Registrar discover before enrolment. | ||||||||||||||||
| draft-ietf-anima-constrained-voucher-20.txt | |||||||||||||||||
| Constrained Bootstrapping Remote Secure Key Infrastructure (BRSKI) | |||||||||||||||||
|
This document defines the Constrained Bootstrapping Remote Secure Key Infrastructure (Constrained BRSKI) protocol, which provides a solution for secure zero-touch bootstrapping of resource-constrained (IoT) devices into the network of a domain owner. This protocol is designed for constrained networks, which may have limited data throughput or may experience frequent packet loss. Constrained BRSKI is a variant of the BRSKI protocol, which uses an artifact signed by the device manufacturer called the "voucher" which enables a new device and the owner's network to mutually authenticate. While the BRSKI voucher is typically encoded in JSON, Constrained BRSKI uses a compact CBOR-encoded voucher. The BRSKI voucher is extended with new data types that allow for smaller voucher sizes. The Enrollment over Secure Transport (EST) protocol, used in BRSKI, is replaced with EST- over-CoAPS; and HTTPS used in BRSKI is replaced with CoAPS. This document Updates RFC 8366 and RFC 8995. | ||||||||||||||||
| draft-ietf-anima-grasp-distribution-07.txt | |||||||||||||||||
| Information Distribution over GRASP | |||||||||||||||||
|
This document analyzes the Information distribution models in the Autonomic Networks that are based on the ANI. Most of instantaneous modes and their requirements have been met by GRASP already. However, in order to effectively support the asynchronous information distribution modes, which is newly described in this document, several new GRASP extensions are defined. This document also describes the corresponding behaviors on processing these new extensions. | ||||||||||||||||
| draft-ietf-anima-jws-voucher-06.txt | |||||||||||||||||
| JWS signed Voucher Artifacts for Bootstrapping Protocols | |||||||||||||||||
|
[RFC8366] defines a digital artifact called voucher as a YANG-defined JSON document that is signed using a Cryptographic Message Syntax (CMS) structure. This document introduces a variant of the voucher artifact in which CMS is replaced by the JSON Object Signing and Encryption (JOSE) mechanism described in [RFC7515] to support deployments in which JOSE is preferred over CMS. In addition to explaining how the format is created, the "application/voucher-jws+json" media type is registered and examples are provided. | ||||||||||||||||
| draft-ietf-anima-network-service-auto-deployment-04.txt | |||||||||||||||||
| A Generic Autonomic Deployment and Management Mechanism for Resource-based Network Services | |||||||||||||||||
|
This document specifies an autonomic mechanism for resource-based network services deployment and management, using the GeneRic Autonomic Signaling Protocol (GRASP) to dynamically exchange the information among the autonomic nodes. It supports the coordination and consistently operations within an autonomic network domain. This mechanism is generic for most, if not all, of kinds of network resources, although this document only defines the process of quality transmission service deployment and management. It can be easily extended to support network services deployment and management that is based on other types ofnetwork resources. | ||||||||||||||||
| draft-ietf-anima-rfc8366bis-07.txt | |||||||||||||||||
| A Voucher Artifact for Bootstrapping Protocols | |||||||||||||||||
|
This document defines a strategy to securely assign a pledge to an owner using an artifact signed, directly or indirectly, by the pledge's manufacturer. This artifact is known as a "voucher". This document defines an artifact format as a YANG-defined JSON or CBOR document that has been signed using a variety of cryptographic systems. The voucher artifact is normally generated by the pledge's manufacturer (i.e., the Manufacturer Authorized Signing Authority (MASA)). This document updates RFC8366, merging a number of extensions into the YANG. The RFC8995 voucher request is also merged into this document. | ||||||||||||||||
| draft-ietf-asap-sip-auto-peer-07.txt | |||||||||||||||||
| Automatic Peering for SIP Trunks | |||||||||||||||||
|
This document specifies a framework that enables enterprise telephony Session Initiation Protocol (SIP) networks to solicit and obtain a capability set document from a SIP service provider. The capability set document encodes a set of characteristics that enable easy peering between enterprise and service provider SIP networks. | ||||||||||||||||
| draft-ietf-asap-siptrunkingcapability-link-03.txt | |||||||||||||||||
| The 'sip-trunking-capability' Link Relation Type | |||||||||||||||||
|
This specification defines the 'sip-trunking-capability' link relation type that may be used by an enterprise telephony Session Initiation Protocol (SIP) network to retrieve a SIP trunking capability set document, which contains the capabilities and configuration requirements of an Internet Telephony Service Provider (ITSP). These technical requirements allow for seamless peering between SIP-based enterprise telephony networks and the ITSP. | ||||||||||||||||
| draft-ietf-asdf-sdf-13.txt | |||||||||||||||||
| Semantic Definition Format (SDF) for Data and Interactions of Things | |||||||||||||||||
|
The Semantic Definition Format (SDF) is a format for domain experts to use in the creation and maintenance of data and interaction models in the Internet of Things. An SDF specification describes definitions of SDF Objects and their associated interactions (Events, Actions, Properties), as well as the Data types for the information exchanged in those interactions. Tools convert this format to database formats and other serializations as needed. // A JSON format representation of SDF 1.0 was defined in version // (-00) of this document; version (-05) was designated as an // _implementation draft_, labeled SDF 1.1, at the IETF110 meeting of // the ASDF WG (2021-03-11). The present version (-13) collects // smaller changes up to 2023-01-12. | ||||||||||||||||
| draft-ietf-avtcore-rfc7983bis-09.txt | |||||||||||||||||
| Multiplexing Scheme Updates for QUIC | |||||||||||||||||
|
RFC 7983 defines a scheme for a Real-time Transport Protocol (RTP) receiver to demultiplex Datagram Transport Layer Security (DTLS), Session Traversal Utilities for NAT (STUN), Secure Real-time Transport Protocol (SRTP) / Secure Real-time Transport Control Protocol (SRTCP), ZRTP and Traversal Using Relays around NAT (TURN) Channel packets arriving on a single port. This document updates RFC 7983 and RFC 5764 to also allow QUIC packets to be multiplexed on a single receiving socket. | ||||||||||||||||
| draft-ietf-avtcore-rtcp-green-metadata-01.txt | |||||||||||||||||
| RTP Control Protocol (RTCP) Messages for Temporal-Spatial Resolution | |||||||||||||||||
|
This specification describes an RTCP feedback message format for the ISO/IEC International Standard 23001-11, known as Energy Efficient Media Consumption (Green metadata), developed by the ISO/IEC JTC 1/SC 29/ WG 3 MPEG System. The RTCP payload format specified in this specification enables receivers to provide feedback to the senders and thus allows for short-term adaptation and feedback-based energy efficient mechanisms to be implemented. The payload format has broad applicability in real-time video communication services. | ||||||||||||||||
| draft-ietf-avtcore-rtp-evc-04.txt | |||||||||||||||||
| RTP Payload Format for Essential Video Coding (EVC) | |||||||||||||||||
|
This memo describes an RTP payload format for the Essential Video Coding (EVC) standard, published as ISO/IEC International Standard 23094-1. EVC was developed by the Moving Picture Experts Group (MPEG). The RTP payload format allows for the packetization of one or more Network Abstraction Layer (NAL) units in each RTP packet payload and the fragmentation of a NAL unit into multiple RTP packets. The payload format has broad applicability in videoconferencing, Internet video streaming, and high-bitrate entertainment-quality video, among other applications. | ||||||||||||||||
| draft-ietf-avtcore-rtp-over-quic-02.txt | |||||||||||||||||
| RTP over QUIC | |||||||||||||||||
|
This document specifies a minimal mapping for encapsulating Real-time Transport Protocol (RTP) and RTP Control Protocol (RTCP) packets within the QUIC protocol. It also discusses how to leverage state from the QUIC implementation in the endpoints, in order to reduce the need to exchange RTCP packets and how to implement congestion control and rate adaptation without relying on RTCP feedback. | ||||||||||||||||
| draft-ietf-avtcore-rtp-scip-05.txt | |||||||||||||||||
| RTP Payload Format for the Secure Communication Interoperability Protocol (SCIP) Codec | |||||||||||||||||
|
This document describes the RTP payload format of the Secure Communication Interoperability Protocol (SCIP). SCIP is an application layer protocol that defines the establishment of reliable SCIP endpoint to SCIP endpoint secure communications over the RTP channel provided by network equipment. The scope of this document is limited to defining the scip codecs and Session Description Protocol (SDP) and RTP parameters to be supported by network devices with minimal description of the SCIP Application Layer Protocol. Since the SCIP RTP payload is encrypted, it is considered "opaque" to network devices. | ||||||||||||||||
| draft-ietf-avtcore-rtp-v3c-01.txt | |||||||||||||||||
| RTP Payload Format for Visual Volumetric Video-based Coding (V3C) | |||||||||||||||||
|
This memo describes an RTP payload format for visual volumetric video-based coding (V3C) [ISO.IEC.23090-5]. A V3C bitstream is composed of V3C units that contain V3C video sub-bitstreams, V3C atlas sub-bitstreams, or a V3C parameter set. The RTP payload format for V3C video sub-bitstreams is defined by appropriate Internet Standards for the applicable video codec. The RTP payload format for V3C atlas sub-bitstreams is described by this memo. The V3C RTP payload format allows for packetization of one or more V3C Network Abstraction Layer (NAL) units in a RTP packet payload as well as fragmentation of a V3C NAL unit into multiple RTP packets. The memo also describes the mechanisms for grouping RTP streams of V3C component sub-bitstreams, providing a complete solution for streaming V3C content. | ||||||||||||||||
| draft-ietf-avtext-framemarking-14.txt | |||||||||||||||||
| Video Frame Marking RTP Header Extension | |||||||||||||||||
|
This document describes a Video Frame Marking RTP header extension used to convey information about video frames that is critical for error recovery and packet forwarding in RTP middleboxes or network nodes. It is most useful when media is encrypted, and essential when the middlebox or node has no access to the media decryption keys. It is also useful for codec-agnostic processing of encrypted or unencrypted media, while it also supports extensions for codec- specific information. | ||||||||||||||||
| draft-ietf-avtext-lrr-07.txt | |||||||||||||||||
| The Layer Refresh Request (LRR) RTCP Feedback Message | |||||||||||||||||
|
This memo describes the RTCP Payload-Specific Feedback Message "Layer Refresh Request" (LRR), which can be used to request a state refresh of one or more substreams of a layered media stream. It also defines its use with several RTP payloads for scalable media formats. | ||||||||||||||||
| draft-ietf-babel-mac-relaxed-04.txt | |||||||||||||||||
| Relaxed Packet Counter Verification for Babel MAC Authentication | |||||||||||||||||
|
This document relaxes packet verification rules defined in the Babel MAC Authentication protocol in order to make it more robust in the presence of packet reordering. | ||||||||||||||||
| draft-ietf-babel-yang-model-13.txt | |||||||||||||||||
| YANG Data Model for Babel | |||||||||||||||||
|
This document defines a data model for the Babel routing protocol. The data model is defined using the YANG data modeling language. | ||||||||||||||||
| draft-ietf-bess-bgp-sdwan-usage-09.txt | |||||||||||||||||
| BGP Usage for SD-WAN Overlay Networks | |||||||||||||||||
|
The document discusses the usage and applicability of BGP as the control plane for multiple SD-WAN scenarios. The document aims to demonstrate how the BGP-based control plane is used for large-scale SD-WAN overlay networks with little manual intervention. SD-WAN edge nodes are commonly interconnected by multiple types of underlay networks owned and managed by different network providers. | ||||||||||||||||
| draft-ietf-bess-ebgp-dmz-02.txt | |||||||||||||||||
| Cumulative DMZ Link Bandwidth and load-balancing | |||||||||||||||||
|
The DMZ Link Bandwidth draft provides a way to load-balance traffic to a destination which is reachable via more than one path according to the weight attahced. Typically, the link bandwidth (either configured on the link of the EBGP egress interface or set via a policy) is encoded in an extended community and then sent to the IBGP peer that employs multi-path. The link-bandwidth value is then extracted from the extended community and is used as a weight in the RIB/FIB, which does the load-balancing. This draft extends the usage of the DMZ link bandwidth to another setting where the ingress BGP speaker requires knowledge of the cumulative bandwidth while doing the load-balancing. The draft also proposes neighbor-level knobs to enable the link bandwidth extended community to be regenerated and then advertised to EBGP peers to override the default behavior of not advertising optional non-transitive attributes to EBGP peers. | ||||||||||||||||
| draft-ietf-bess-evpn-ac-aware-bundling-00.txt | |||||||||||||||||
| AC-Aware Bundling Service Interface in EVPN | |||||||||||||||||
|
EVPN provides an extensible and flexible multi-homing VPN solution over an MPLS/IP network for intra-subnet connectivity among Tenant Systems and End Devices that can be physical or virtual. EVPN multihoming with IRB is one of the common deployment scenarios. There are deployments which requires capability to have multiple subnets designated with multiple VLAN IDs in single Broadcast Domain. EVPN technology defines three different types of service interface which serve different requirements but none of them address the requirement of supporting multiple subnets within single Broadcast Domain. In this draft we define new service interface type to support multiple subnets in single Broadcast Domain. Service interface proposed in this draft will be applicable to multihoming case only. | ||||||||||||||||
| draft-ietf-bess-evpn-bfd-04.txt | |||||||||||||||||
| EVPN Network Layer Fault Management | |||||||||||||||||
|
This document specifies proactive, in-band network layer OAM mechanisms to detect loss of continuity faults that affect unicast and multi-destination paths (used by Broadcast, Unknown Unicast, and Multicast traffic) in an Ethernet VPN (RFC 7432) network. The mechanisms specified in the draft use the widely adopted Bidirectional Forwarding Detection (RFC 5880) protocol and other protocols as necessary. | ||||||||||||||||
| draft-ietf-bess-evpn-bum-procedure-updates-14.txt | |||||||||||||||||
| Updates on EVPN BUM Procedures | |||||||||||||||||
|
This document specifies updated procedures for handling broadcast, unknown unicast, and multicast (BUM) traffic in Ethernet VPNs (EVPN), including selective multicast, and provider tunnel segmentation. This document updates RFC 7432. | ||||||||||||||||
| draft-ietf-bess-evpn-fast-df-recovery-07.txt | |||||||||||||||||
| Fast Recovery for EVPN Designated Forwarder Election | |||||||||||||||||
|
The Ethernet Virtual Private Network (EVPN) solution provides Designated Forwarder election procedures for multihomed Ethernet Segments. These procedures have been enhanced further by applying Highest Random Weight (HRW) algorithm for Designated Forwarder (DF) election in order to avoid unnecessary DF status changes upon a failure. This document improves these procedures by providing a fast Designated Forwarder election upon recovery of the failed link or node associated with the multihomed Ethernet Segment. The solution is independent of the number of EVIs associated with that Ethernet Segment and it is performed via a simple signaling between the recovered PE and each of the other PEs in the multihoming group. | ||||||||||||||||
| draft-ietf-bess-evpn-geneve-05.txt | |||||||||||||||||
| EVPN control plane for Geneve | |||||||||||||||||
|
This document describes how Ethernet VPN (EVPN) control plane can be used with Network Virtualization Overlay over Layer 3 (NVO3) Generic Network Virtualization Encapsulation (Geneve) encapsulation for NVO3 solutions. EVPN control plane can also be used by Network Virtualization Edges (NVEs) to express Geneve tunnel option TLV(s) supported in the transmission and/or reception of Geneve encapsulated data packets. | ||||||||||||||||
| draft-ietf-bess-evpn-irb-extended-mobility-09.txt | |||||||||||||||||
| Extended Mobility Procedures for EVPN-IRB | |||||||||||||||||
|
Procedure to handle host mobility in a layer 2 Network with EVPN control plane is defined as part of RFC 7432. EVPN has since evolved to find wider applicability across various IRB use cases that include distributing both MAC and IP reachability via a common EVPN control plane. MAC Mobility procedures defined in RFC 7432 are extensible to IRB use cases if a fixed 1:1 mapping between VM IP and MAC is assumed across VM moves. Generic mobility support for IP and MAC that allows these bindings to change across moves is required to support a broader set of EVPN IRB use cases, and requires further consideration. EVPN all-active multi-homing further introduces scenarios that require additional consideration from mobility perspective. This document enumerates a set of design considerations applicable to mobility across these EVPN IRB use cases and defines generic sequence number assignment procedures to address these IRB use cases. | ||||||||||||||||
| draft-ietf-bess-evpn-irb-mcast-09.txt | |||||||||||||||||
| EVPN Optimized Inter-Subnet Multicast (OISM) Forwarding | |||||||||||||||||
|
Ethernet VPN (EVPN) provides a service that allows a single Local Area Network (LAN), comprising a single IP subnet, to be divided into multiple "segments". Each segment may be located at a different site, and the segments are interconnected by an IP or MPLS backbone. Intra-subnet traffic (either unicast or multicast) always appears to the end users to be bridged, even when it is actually carried over the IP or MPLS backbone. When a single "tenant" owns multiple such LANs, EVPN also allows IP unicast traffic to be routed between those LANs. This document specifies new procedures that allow inter-subnet IP multicast traffic to be routed among the LANs of a given tenant, while still making intra-subnet IP multicast traffic appear to be bridged. These procedures can provide optimal routing of the inter- subnet multicast traffic, and do not require any such traffic to egress a given router and then ingress that same router. These procedures also accommodate IP multicast traffic that originates or is destined external to the EVPN domain. | ||||||||||||||||
| draft-ietf-bess-evpn-l2gw-proto-03.txt | |||||||||||||||||
| EVPN Multi-Homing Mechanism for Layer-2 Gateway Protocols | |||||||||||||||||
|
The existing EVPN multi-homing load-balancing modes defined are Single-Active and All-Active. Neither of these multi-homing mechanisms adequately represent ethernet-segments facing access networks with Layer-2 Gateway protocols such as G.8032, (M)STP, REP, MPLS-TP, etc. These loop-preventing Layer-2 protocols require a new multi-homing mechanism defined in this document. | ||||||||||||||||
| draft-ietf-bess-evpn-lsp-ping-09.txt | |||||||||||||||||
| LSP-Ping Mechanisms for EVPN and PBB-EVPN | |||||||||||||||||
|
LSP Ping is a widely deployed Operation, Administration, and Maintenance mechanism in MPLS networks. This document describes mechanisms for detecting data plane failures using LSP Ping in MPLS based EVPN and PBB-EVPN networks. | ||||||||||||||||
| draft-ietf-bess-evpn-mh-split-horizon-05.txt | |||||||||||||||||
| EVPN Multi-Homing Extensions for Split Horizon Filtering | |||||||||||||||||
|
Ethernet Virtual Private Network (EVPN) is commonly used along with Network Virtualization Overlay (NVO) tunnels, as well as MPLS and Segment Routing tunnels. The EVPN multi-homing procedures may be different depending on the tunnel type used in the EVPN Broadcast Domain. In particular, there are two multi-homing Split Horizon procedures to avoid looped frames on the multi-homed CE: ESI Label based and Local Bias. ESI Label based Split Horizon is used for MPLSoX tunnels, E.g., MPLSoUDP, whereas Local Bias is used for other tunnels, E.g., VXLAN tunnels. The existing specifications do not allow the operator to decide which Split Horizon procedure to use for tunnel encapsulations that could support both. Examples of tunnels that may support both procedures are MPLSoGRE, MPLSoUDP, GENEVE or SRv6. This document updates the EVPN Multi-Homing procedures so that an operator can decide the Split Horizon procedure for a given tunnel depending on their own requirements. | ||||||||||||||||
| draft-ietf-bess-evpn-modes-interop-02.txt | |||||||||||||||||
| EVPN Interoperability Modes | |||||||||||||||||
|
Ethernet VPN (EVPN) provides different functional modes in the area of Service Interface, Integrated Route and Bridge (IRB) and IRB Core connectivity. This document specifies how the different EVPN functional modes and types can interoperate with each other. This document doesn't aim to redefine the existing functional modes but describe how there is interoperability. | ||||||||||||||||
| draft-ietf-bess-evpn-mvpn-seamless-interop-05.txt | |||||||||||||||||
| Seamless Multicast Interoperability between EVPN and MVPN PEs | |||||||||||||||||
|
Ethernet Virtual Private Network (EVPN) solution is becoming pervasive for Network Virtualization Overlay (NVO) services in data center (DC) and Enterprise networks as well as as the next generation VPN services in service provider (SP) networks. As service providers transform their networks in their Central Offices (COs) towards the next generation data center with Software Defined Networking (SDN) based fabric and Network Function Virtualization (NFV), they want to be able to maintain their offered services including Multicast VPN (MVPN) service between their existing network and their new Service Provider Data Center (SPDC) network seamlessly without the use of gateway devices. They want to have such seamless interoperability between their new SPDCs and their existing networks for a) reducing cost, b) having optimum forwarding, and c) reducing provisioning. This document describes a unified solution based on RFCs 6513 & 6514 for seamless interoperability of Multicast VPN between EVPN and MVPN PEs. Furthermore, it describes how the proposed solution can be used as a routed multicast solution in data centers with only EVPN PEs. | ||||||||||||||||
| draft-ietf-bess-evpn-optimized-ir-12.txt | |||||||||||||||||
| Optimized Ingress Replication Solution for Ethernet VPN (EVPN) | |||||||||||||||||
|
Network Virtualization Overlay networks using Ethernet VPN (EVPN) as their control plane may use Ingress Replication or PIM (Protocol Independent Multicast)-based trees to convey the overlay Broadcast, Unknown unicast and Multicast (BUM) traffic. PIM provides an efficient solution to avoid sending multiple copies of the same packet over the same physical link, however it may not always be deployed in the Network Virtualization Overlay core network. Ingress Replication avoids the dependency on PIM in the Network Virtualization Overlay network core. While Ingress Replication provides a simple multicast transport, some Network Virtualization Overlay networks with demanding multicast applications require a more efficient solution without PIM in the core. This document describes a solution to optimize the efficiency of Ingress Replication trees. | ||||||||||||||||
| draft-ietf-bess-evpn-per-mcast-flow-df-election-07.txt | |||||||||||||||||
| Per multicast flow Designated Forwarder Election for EVPN | |||||||||||||||||
|
[RFC7432] describes mechanism to elect designated forwarder (DF) at the granularity of (ESI, EVI) which is per VLAN (or per group of VLANs in case of VLAN bundle or VLAN-aware bundle service). However, the current level of granularity of per-VLAN is not adequate for some applications.[RFC8584] improves base line DF election by introducing HRW DF election. [RFC9251] introduces applicability of EVPN to Multicast flows, routes to sync them and a default DF election. This document is an extension to HRW base draft [RFC8584] and further enhances HRW algorithm for the Multicast flows to do DF election at the granularity of (ESI, VLAN, Mcast flow). | ||||||||||||||||
| draft-ietf-bess-evpn-pref-df-10.txt | |||||||||||||||||
| Preference-based EVPN DF Election | |||||||||||||||||
|
The Designated Forwarder (DF) in Ethernet Virtual Private Networks (EVPN) is defined as the PE responsible for sending Broadcast, Unknown unicast and Broadcast traffic (BUM) to a multi-homed device/ network in the case of an all-active multi-homing Ethernet Segment (ES), or BUM and unicast in the case of single-active multi-homing. The Designated Forwarder is selected out of a candidate list of PEs that advertise the same Ethernet Segment Identifier (ESI) to the EVPN network, according to the Default Designated Forwarder Election algorithm. While the Default Algorithm provides an efficient and automated way of selecting the Designated Forwarder across different Ethernet Tags in the Ethernet Segment, there are some use cases where a more 'deterministic' and user-controlled method is required. At the same time, Service Providers require an easy way to force an on- demand Designated Forwarder switchover in order to carry out some maintenance tasks on the existing Designated Forwarder or control whether a new active PE can preempt the existing Designated Forwarder PE. This document proposes a Designated Forwarder Election algorithm that meets the requirements of determinism and operation control. | ||||||||||||||||
| draft-ietf-bess-evpn-redundant-mcast-source-05.txt | |||||||||||||||||
| Multicast Source Redundancy in EVPN Networks | |||||||||||||||||
|
EVPN supports intra and inter-subnet IP multicast forwarding. However, EVPN (or conventional IP multicast techniques for that matter) do not have a solution for the case where the following two statements are true at the same time: a) a given multicast group carries more than one flow (i.e., more than one source), and b) it is desired that each receiver gets only one of the several flows. Existing multicast techniques assume there are no redundant sources sending the same flow to the same IP multicast group, and, in case there were redundant sources, the receiver's application would deal with the received duplicated packets. This document extends the existing EVPN specifications and assumes that IP Multicast source redundancy may exist. It also assumes that, in case two or more sources send the same IP Multicast flows into the tenant domain, the EVPN PEs need to avoid that the receivers get packet duplication by following the described procedures. | ||||||||||||||||
| draft-ietf-bess-evpn-unequal-lb-17.txt | |||||||||||||||||
| Weighted Multi-Path Procedures for EVPN Multi-Homing | |||||||||||||||||
|
EVPN enables all-active multi-homing for a CE device connected to two or more PEs via a LAG, such that bridged and routed traffic from remote PEs to hosts attached to the Ethernet Segment can be equally load balanced (it uses Equal Cost Multi Path) across the multi-homing PEs. EVPN also enables multi-homing for IP subnets advertised in IP Prefix routes, so that routed traffic from remote PEs to those IP subnets can be load balanced. This document defines extensions to EVPN procedures to optimally handle unequal access bandwidth distribution across a set of multi-homing PEs in order to: * provide greater flexibility, with respect to adding or removing individual multi-homed PE-CE links. * handle multi-homed PE-CE link failures that can result in unequal PE-CE access bandwidth across a set of multi-homing PEs. | ||||||||||||||||
| draft-ietf-bess-evpn-virtual-eth-segment-08.txt | |||||||||||||||||
| EVPN Virtual Ethernet Segment | |||||||||||||||||
|
EVPN and PBB-EVPN introduce a family of solutions for multipoint Ethernet services over MPLS/IP network with many advanced features among which their multi-homing capabilities. These solutions introduce Single-Active and All-Active for an Ethernet Segment (ES), itself defined as a set of physical links between the multi-homed device/network and a set of PE devices that they are connected to. This document extends the Ethernet Segment concept so that an ES can be associated to a set of EVCs (e.g., VLANs) or other objects such as MPLS Label Switch Paths (LSPs) or Pseudowires (PWs), referred to as Virtual Ethernet Segments (vES). This draft describes the requirements and the extensions needed to support vES in EVPN and PBB-EVPN. | ||||||||||||||||
| draft-ietf-bess-evpn-vpws-fxc-08.txt | |||||||||||||||||
| EVPN VPWS Flexible Cross-Connect Service | |||||||||||||||||
|
This document describes a new EVPN VPWS service type specifically for multiplexing multiple attachment circuits across different Ethernet Segments and physical interfaces into a single EVPN VPWS service tunnel and still providing Single-Active and All-Active multi-homing. This new service is referred to as flexible cross-connect service. After a description of the rationale for this new service type, the solution to deliver such service is detailed. | ||||||||||||||||
| draft-ietf-bess-extended-evpn-optimized-ir-03.txt | |||||||||||||||||
| Extended Procedures for EVPN Optimized Ingress Replication | |||||||||||||||||
|
[EVPN-AR] specifies an optimized ingress replication solution for more efficient multicast and broadcast delivery in a Network Virtualization Overlay (NVO) network for EVPN. This document extends the optimized ingress replication procedures specified in [EVPN-AR] to overcome the limitation that an AR- REPLICATOR may have. An AR-REPLICATOR may be unable to retain the source IP address or include the expected ESI label that is required for EVPN split horizon filtering when replicating the packet on behalf of its multihomed AR-LEAF. Under this circumstance, the extended procedures specified in this document allows the support of EVPN multihoming on the AR-LEAFs as well as optimized ingress replication for the rest of the EVPN overlay network. | ||||||||||||||||
| draft-ietf-bess-mvpn-evpn-aggregation-label-09.txt | |||||||||||||||||
| MVPN/EVPN Tunnel Aggregation with Common Labels | |||||||||||||||||
|
The MVPN specifications allow a single Point-to-Multipoint (P2MP) tunnel to carry traffic of multiple VPNs. The EVPN specifications allow a single P2MP tunnel to carry traffic of multiple Broadcast Domains (BDs). These features require the ingress router of the P2MP tunnel to allocate an upstream-assigned MPLS label for each VPN or for each BD. A packet sent on a P2MP tunnel then carries the label that is mapped to its VPN or BD (in some cases, a distinct upstream- assigned label is needed for each flow.) Since each ingress router allocates labels independently, with no coordination among the ingress routers, the egress routers may need to keep track of a large number of labels. The number of labels may need to be as large (or larger) than the product of the number of ingress routers times the number of VPNs or BDs. However, the number of labels can be greatly reduced if the association between a label and a VPN or BD is made by provisioning, so that all ingress routers assign the same label to a particular VPN or BD. New procedures are needed in order to take advantage of such provisioned labels. These new procedures also apply to Multipoint-to-Multipoint (MP2MP) tunnels. This document updates RFCs 6514, 7432 and 7582 by specifying the necessary procedures. | ||||||||||||||||
| draft-ietf-bess-pbb-evpn-isid-cmacflush-06.txt | |||||||||||||||||
| PBB-EVPN ISID-based CMAC-Flush | |||||||||||||||||
|
Provider Backbone Bridging (PBB) can be combined with Ethernet Virtual Private Networks (EVPN) to deploy Ethernet Local Area Network (ELAN) services in large Multi-Protocol Label Switching (MPLS) networks (PBB-EVPN). Single-Active Multi-homing and per-I-SID (per Service Instance Identifier) Load-Balancing can be provided to access devices and aggregation networks. In order to speed up the network convergence in case of failures on Single-Active Multi-Homed Ethernet Segments, PBB-EVPN defines a flush mechanism for Customer MACs (CMAC- flush) that works for different Ethernet Segment Backbone MAC (BMAC) address allocation models. This document complements those CMAC- flush procedures for cases in which no PBB-EVPN Ethernet Segments are defined (the attachment circuit is associated to a zero Ethernet Segment Identifier) and a Service Instance Identifier based (I-SID- based) CMAC-flush granularity is required. | ||||||||||||||||
| draft-ietf-bess-rfc7432bis-07.txt | |||||||||||||||||
| BGP MPLS-Based Ethernet VPN | |||||||||||||||||
|
This document describes procedures for BGP MPLS-based Ethernet VPNs (EVPN). The procedures described here meet the requirements specified in [RFC7209] -- "Requirements for Ethernet VPN (EVPN)". Note to Readers _RFC EDITOR: please remove this section before publication_ The complete and detailed set of all changes between this version and [RFC7432] may be found as an Annotated Diff (rfcdiff) here (https://tools.ietf.org/rfcdiff?url1=https://www.rfc- editor.org/rfc/rfc7432.txt&url2=https://www.ietf.org/archive/id/ draft-ietf-bess-rfc7432bis-07.txt). | ||||||||||||||||
| draft-ietf-bess-weighted-hrw-00.txt | |||||||||||||||||
| Weighted HRW and its applications | |||||||||||||||||
|
Rendezvous Hashing also known as Highest Random Weight (HRW) has been used in many load balancing applications where the central problem is how to map an object to as server such that the mapping is uniform and also minimally affected by the change in the server set. Recently, it has found use in DF election algorithms in the EVPN context and load balancing using DMZ. This draft deals with the problem of achieving load balancing with minimal disruption when the servers have different weights. It provides an algorithm to do so and also describes a few use-case scenarios where this algorithmic technique can apply. | ||||||||||||||||
| draft-ietf-bfd-secure-sequence-numbers-10.txt | |||||||||||||||||
| Secure BFD Sequence Numbers | |||||||||||||||||
|
This document describes a new BFD Authentication mechanism, Meticulous Keyed ISAAC. This mechanism can be used to authenticate BFD packets with less CPU time cost than using MD5 or SHA1, with the tradeoff of decreased security. This mechanism cannot be used to signal state changes, but it can be used as an authenticated signal to maintain a session in the the "Up" state. This document updates RFC 5880. | ||||||||||||||||
| draft-ietf-bfd-unaffiliated-echo-06.txt | |||||||||||||||||
| Unaffiliated BFD Echo | |||||||||||||||||
|
Bidirectional Forwarding Detection (BFD) is a fault detection protocol that can quickly determine a communication failure between two forwarding engines. This document proposes a use of the BFD Echo where the local system supports BFD but the neighboring system does not support BFD. BFD Async procedures can be executed over the BFD Echo port where the neighboring system only loops packets back to the local system. This document updates RFC 5880. | ||||||||||||||||
| draft-ietf-bfd-unsolicited-14.txt | |||||||||||||||||
| Unsolicited BFD for Sessionless Applications | |||||||||||||||||
|
For operational simplification of "sessionless" applications using Bidirectional Forwarding Detection (BFD), in this document we present procedures for "unsolicited BFD" that allow a BFD session to be initiated by only one side, and established without explicit per- session configuration or registration by the other side (subject to certain per-interface or global policies). We also introduce a new YANG module to configure and manage "unsolicited BFD". The YANG module in this document 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. This document augments RFC 9314. | ||||||||||||||||
| draft-ietf-bier-bfd-03.txt | |||||||||||||||||
| BIER BFD | |||||||||||||||||
|
Point to multipoint (P2MP) BFD is designed to verify multipoint connectivity. This document specifies the application of P2MP BFD in BIER network. | ||||||||||||||||
| draft-ietf-bier-bgp-ls-bier-ext-14.txt | |||||||||||||||||
| BGP Link-State extensions for BIER | |||||||||||||||||
|
Bit Index Explicit Replication (BIER) is an architecture that provides optimal multicast forwarding through a "BIER domain" without requiring intermediate routers to maintain any multicast related per- flow state. BIER also does not require any explicit tree-building protocol for its operation. A multicast data packet enters a BIER domain at a "Bit-Forwarding Ingress Router" (BFIR), and leaves the BIER domain at one or more "Bit-Forwarding Egress Routers" (BFERs). The BFIR router adds a BIER header to the packet. The BIER header contains a bitstring in which each bit represents exactly one BFER to forward the packet to. The set of BFERs to which the multicast packet needs to be forwarded is expressed by setting the bits that correspond to those routers in the BIER header. BGP Link-State (BGP-LS) enables the collection of various topology informations from the network, and the topology informations are used by the controller to calculate the fowarding tables and then propagate them onto the BFRs(instead of having each node to calculate on its own) and that can be for both inter-as and intra-as situations. This document specifies extensions to the BGP Link-state address- family in order to advertise the BIER informations. | ||||||||||||||||
| draft-ietf-bier-bierin6-07.txt | |||||||||||||||||
| Supporting BIER in IPv6 Networks (BIERin6) | |||||||||||||||||
|
BIER is a multicast forwarding architecture that does not require per-flow state inside the network yet still provides optimal replication. This document describes how the existing BIER encapsulation specified in RFC 8296 works in a non-MPLS IPv6 network, which is referred to as BIERin6. Specifically, like in an IPv4 network, BIER can work over L2 links directly or over tunnels. In case of IPv6 tunneling, a new IP "Next Header" type is to be assigned for BIER. | ||||||||||||||||
| draft-ietf-bier-evpn-08.txt | |||||||||||||||||
| EVPN BUM Using BIER | |||||||||||||||||
|
This document specifies protocols and procedures for forwarding broadcast, unknown unicast and multicast (BUM) traffic of Ethernet VPNs (EVPN) using Bit Index Explicit Replication (BIER). | ||||||||||||||||
| draft-ietf-bier-frr-01.txt | |||||||||||||||||
| BIER Fast ReRoute | |||||||||||||||||
|
BIER is a scalable multicast overlay that utilizes a routing underlay, e.g., IP, to build up its Bit Index Forwarding Tables (BIFTs). This document proposes Fast Reroute for BIER (BIER-FRR). It protects BIER traffic after detecting the failure of a link or node in the core of a BIER domain until affected BIFT entries are recomputed after reconvergence of the routing underlay. BIER-FRR is applied locally at the point of local repair (PLR) and does not introduce any per-flow state. The document specifies nomenclature for BIER-FRR and gives examples for its integration in BIER forwarding. Furthermore, it presents operation modes for BIER-FRR. Link and node protection may be chosen as protection level. Moreover, the backup strategies tunnel-based BIER-FRR and LFA-based BIER-FRR are defined and compared. | ||||||||||||||||
| draft-ietf-bier-idr-extensions-09.txt | |||||||||||||||||
| BGP Extensions for BIER | |||||||||||||||||
|
Bit Index Explicit Replication (BIER) is a new multicast forwarding architecture which doesn't require an explicit tree-building protocol and doesn't require intermediate routers to maintain any multicast state. BIER is applicable in a multi-tenant data center network environment for efficient delivery of Broadcast, Unknown-unicast and Multicast (BUM) traffic while eliminating the need for maintaining a huge amount of multicast state in the underlay. This document describes BGP extensions for advertising the BIER-specific information. | ||||||||||||||||
| draft-ietf-bier-mldp-signaling-over-bier-02.txt | |||||||||||||||||
| M-LDP Signaling Through BIER Core | |||||||||||||||||
|
Consider an end-to-end Multipoint LDP (mLDP) network, where it is desirable to deploy BIER in a segment of this network. It might be desirable to deploy BIER with minimal disruption to the mLDP network or a redesign of the network. This document describes a procedure needed for mLDP tunnels to be signaled over and stitched through a BIER core, allowing LDP routers to run traditional mLDP services through a BIER core. | ||||||||||||||||
| draft-ietf-bier-multicast-as-a-service-02.txt | |||||||||||||||||
| Multicast/BIER As A Service | |||||||||||||||||
|
This document describes a framework for providing multicast as a service via Bit Index Explicit Replication (BIER) [RFC7279], and specifies a few enhancements to [draft-ietf-bier-idr-extensions] [RFC8279] [RFC8401] [RFC8444] to enable multicast/BIER as a service. | ||||||||||||||||
| draft-ietf-bier-oam-requirements-12.txt | |||||||||||||||||
| Operations,Administration and Maintenance (OAM) Requirements for Bit Index Explicit Replication (BIER) Layer | |||||||||||||||||
|
This document describes a list of functional requirements toward Operations, Administration and Maintenance (OAM) toolset in Bit Index Explicit Replication (BIER) layer of a network. | ||||||||||||||||
| draft-ietf-bier-ospfv3-extensions-07.txt | |||||||||||||||||
| OSPFv3 Extensions for BIER | |||||||||||||||||
|
Bit Index Explicit Replication (BIER) is an architecture that provides multicast forwarding through a "BIER domain" without requiring intermediate routers to maintain multicast related per-flow state. BIER architecture uses MPLS or other encapsulation to steer the multicast traffic towards the receivers. This document describes the OSPFv3 protocol extensions required for BIER with MPLS encapsulation. Support for other encapsulation types is outside the scope of this document. The use of multiple encapsulation types is outside the scope of this document. | ||||||||||||||||
| draft-ietf-bier-path-mtu-discovery-14.txt | |||||||||||||||||
| Path Maximum Transmission Unit Discovery (PMTUD) for Bit Index Explicit Replication (BIER) Layer | |||||||||||||||||
|
This document describes Path Maximum Transmission Unit Discovery (PMTUD) in Bit Indexed Explicit Replication (BIER) layer. | ||||||||||||||||
| draft-ietf-bier-php-10.txt | |||||||||||||||||
| BIER Penultimate Hop Popping | |||||||||||||||||
|
Bit Index Explicit Replication (BIER) can be used as provider tunnel for Multicast Virtual Private Network (MVPN), Global Table Multicast or Ethernet Virtual Private Network (EVPN). It is possible that not all routers in the provider network support BIER and there are various methods to handle BIER-incapable transit routers. However those methods assume the MVPN/EVPN Provider Edges (PEs) are BIER- capable. This document specifies a method to allow BIER-incapable routers to act as MVPN/EVPN PEs with BIER as the transport, by having the upstream BIER Forwarding Router (BFR) that is connected directly or indirectly via a tunnel to a BIER-incapable PE remove the BIER header and send the payload to the PE. | ||||||||||||||||
| draft-ietf-bier-ping-08.txt | |||||||||||||||||
| BIER Ping and Trace | |||||||||||||||||
|
Bit Index Explicit Replication (BIER) is an architecture that provides optimal multicast forwarding through a "BIER domain" without requiring intermediate routers to maintain any multicast related per- flow state. BIER also does not require any explicit tree-building protocol for its operation. A multicast data packet enters a BIER domain at a "Bit-Forwarding Ingress Router" (BFIR), and leaves the BIER domain at one or more "Bit-Forwarding Egress Routers" (BFERs). The BFIR router adds a BIER header to the packet. The BIER header contains a bit-string in which each bit represents exactly one BFER to forward the packet to. The set of BFERs to which the multicast packet needs to be forwarded is expressed by setting the bits that correspond to those routers in the BIER header. This document describes the mechanism and basic BIER OAM packet format that can be used to perform failure detection and isolation on the BIER data plane. | ||||||||||||||||
| draft-ietf-bier-pmmm-oam-13.txt | |||||||||||||||||
| Performance Measurement (PM) with Marking Method in Bit Index Explicit Replication (BIER) Layer | |||||||||||||||||
|
This document describes the applicability of a hybrid performance measurement method for packet loss and packet delay measurements of a multicast service through a Bit Index Explicit Replication domain. | ||||||||||||||||
| draft-ietf-bier-prefix-redistribute-04.txt | |||||||||||||||||
| BIER Prefix Redistribute | |||||||||||||||||
|
This document defines a BIER proxy function to support a single BIER sub-domain over multiple underlay routing protocol regions (Autonomous Systems or IGP areas). A new BIER proxy range sub-TLV is defined to redistribute BIER BFR-id information across the routing regions. | ||||||||||||||||
| draft-ietf-bier-source-protection-04.txt | |||||||||||||||||
| BIER (Bit Index Explicit Replication) Redundant Ingress Router Failover | |||||||||||||||||
|
This document describes a failover in the Bit Index Explicit Replication domain with a redundant ingress router. | ||||||||||||||||
| draft-ietf-bier-te-isis-04.txt | |||||||||||||||||
| IS-IS Extensions for BIER-TE | |||||||||||||||||
|
This document describes IS-IS extensions for distributing BitPositions configured on the links in "Bit Index Explicit Replication Traffic Engineering" (BIER-TE) domain. | ||||||||||||||||
| draft-ietf-bier-te-ospf-04.txt | |||||||||||||||||
| OSPF Extensions for BIER-TE | |||||||||||||||||
|
This document describes OSPF extensions for distributing BitPositions configured on the links in "Bit Index Explicit Replication Traffic Engineering" (BIER-TE) domain. | ||||||||||||||||
| draft-ietf-bier-te-ospfv3-04.txt | |||||||||||||||||
| OSPFv3 Extensions for BIER-TE | |||||||||||||||||
|
This document describes OSPFv3 extensions for distributing BitPositions configured on the links in "Bit Index Explicit Replication Traffic Engineering" (BIER-TE) domain. | ||||||||||||||||
| draft-ietf-bier-tether-03.txt | |||||||||||||||||
| Tethering A BIER Router To A BIER incapable Router | |||||||||||||||||
|
This document specifies optional procedures to optimize the handling of Bit Index Explicit Replication (BIER) incapable routers, by attaching (tethering) a BIER router to a BIER incapable router. | ||||||||||||||||
| draft-ietf-bmwg-benchmarking-stateful-02.txt | |||||||||||||||||
| Benchmarking Methodology for Stateful NATxy Gateways using RFC 4814 Pseudorandom Port Numbers | |||||||||||||||||
|
RFC 2544 has defined a benchmarking methodology for network interconnect devices. RFC 5180 addressed IPv6 specificities and it also provided a technology update, but excluded IPv6 transition technologies. RFC 8219 addressed IPv6 transition technologies, including stateful NAT64. However, none of them discussed how to apply RFC 4814 pseudorandom port numbers to any stateful NATxy (NAT44, NAT64, NAT66) technologies. We discuss why using pseudorandom port numbers with stateful NATxy gateways is a difficult problem. We recommend a solution limiting the port number ranges and using two phases: the preliminary test phase and the real test phase. We show how the classic performance measurement procedures (e.g. throughput, frame loss rate, latency, etc.) can be carried out. We also define new performance metrics and measurement procedures for maximum connection establishment rate, connection tear down rate and connection tracking table capacity measurements. | ||||||||||||||||
| draft-ietf-bmwg-mlrsearch-03.txt | |||||||||||||||||
| Multiple Loss Ratio Search | |||||||||||||||||
|
This document proposes improvements to [RFC2544] throughput search by defining a new methodology called Multiple Loss Ratio search (MLRsearch). The main objectives for MLRsearch are to minimize the total test duration, search for multiple loss ratios and improve results repeatibility and comparability. The main motivation behind MLRsearch is the new set of challenges and requirements posed by testing Network Function Virtualization (NFV) systems and other software based network data planes. MLRsearch offers several ways to address these challenges, giving user configuration options to select their way. | ||||||||||||||||
| draft-ietf-bmwg-network-tester-cfg-02.txt | |||||||||||||||||
| A YANG Data Model for Network Tester Management | |||||||||||||||||
|
This document introduces new YANG model for use in network interconnect testing containing modules of traffic generator and traffic analyzer. | ||||||||||||||||
| draft-ietf-calext-ical-tasks-06.txt | |||||||||||||||||
| Task Extensions to iCalendar | |||||||||||||||||
|
This document defines extensions to the Internet Calendaring and Scheduling Core Object Specification (iCalendar) (RFC5545) to provide improved status tracking, scheduling and specification of tasks. It also defines how Calendaring Extensions to WebDAV (CalDAV) (RFC 4791) servers can be extended to support certain automated task management behaviours. | ||||||||||||||||
| draft-ietf-calext-jscalendarbis-01.txt | |||||||||||||||||
| JSCalendar: A JSON Representation of Calendar Data | |||||||||||||||||
|
This specification defines a data model and JSON representation of calendar data that can be used for storage and data exchange in a calendaring and scheduling environment. It aims to be an alternative and, over time, successor to the widely deployed iCalendar data format. It also aims to be unambiguous, extendable, and simple to process. In contrast to the jCal format, which is also based on JSON, JSCalendar is not a direct mapping from iCalendar but defines the data model independently and expands semantics where appropriate. This specification obsoletes [RFC8984]. | ||||||||||||||||
| draft-ietf-calext-jscontact-10.txt | |||||||||||||||||
| JSContact: A JSON representation of contact data | |||||||||||||||||
|
This specification defines a data model and JSON representation of contact card information that can be used for data storage and exchange in address book or directory applications. It aims to be an alternative to the vCard data format and to be unambiguous, extendable and simple to process. In contrast to the JSON-based jCard format, it is not a direct mapping from the vCard data model and expands semantics where appropriate. | ||||||||||||||||
| draft-ietf-calext-jscontact-vcard-08.txt | |||||||||||||||||
| JSContact: Converting from and to vCard | |||||||||||||||||
|
This document defines how to convert contact information between the JSContact and vCard data formats. To achieve this, it updates [I-D.ietf-calext-jscontact] by registering new JSContact properties. Similarly, it updates [RFC6350] by registering new vCard properties and parameters. | ||||||||||||||||
| draft-ietf-calext-subscription-upgrade-08.txt | |||||||||||||||||
| Calendar subscription upgrades | |||||||||||||||||
|
This specification updates RFC5545 to add the value DELETED to the STATUS property. This specification also adds values to the Preferences Registry defined in RFC7240 to add the subscribe-enhanced-get and limit preferences and to the link relations directory defined in RFC8288. | ||||||||||||||||
| draft-ietf-calext-vcard-jscontact-extensions-06.txt | |||||||||||||||||
| vCard Format Extension for JSContact | |||||||||||||||||
|
This document defines a set of new properties for vCard and extends the use of existing ones. Their primary purpose is to align the same set of features between the JSContact and vCard formats, but the new definitions also aim to be useful within just the vCard format. This document updates [RFC6350]. | ||||||||||||||||
| draft-ietf-calext-vpoll-04.txt | |||||||||||||||||
| VPOLL: Consensus Scheduling Component for iCalendar | |||||||||||||||||
|
This specification introduces a new RFC5545 iCalendar component which allows for consensus scheduling, that is, voting on a number of alternative meeting or task alternatives. | ||||||||||||||||
| draft-ietf-cbor-packed-08.txt | |||||||||||||||||
| Packed CBOR | |||||||||||||||||
|
The Concise Binary Object Representation (CBOR, RFC 8949 == STD 94) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. CBOR does not provide any forms of data compression. CBOR data items, in particular when generated from legacy data models, often allow considerable gains in compactness when applying data compression. While traditional data compression techniques such as DEFLATE (RFC 1951) can work well for CBOR encoded data items, their disadvantage is that the receiver needs to decompress the compressed form to make use of the data. This specification describes Packed CBOR, a simple transformation of a CBOR data item into another CBOR data item that is almost as easy to consume as the original CBOR data item. A separate decompression step is therefore often not required at the receiver. // The present version (-08) is a refresh update to -07, which added // the concept of Tag Equivalence as initially discussed at the CBOR // Interim meeting 12 in 2022 and at IETF 114. | ||||||||||||||||
| draft-ietf-cbor-time-tag-05.txt | |||||||||||||||||
| Concise Binary Object Representation (CBOR) Tags for Time,Duration,and Period | |||||||||||||||||
|
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 defines two tags for time: CBOR tag 0 (RFC3339 time as a string) and tag 1 (Posix time as int or float). Since then, additional requirements have become known. The present document defines a CBOR tag for time that allows a more elaborate representation of time, as well as related CBOR tags for duration and time period. It is intended as the reference document for the IANA registration of the CBOR tags defined. // The present version (-05) adds CDDL definitions; this should now // address all WGLC comments. | ||||||||||||||||
| draft-ietf-ccamp-bwa-topo-yang-00.txt | |||||||||||||||||
| A YANG Data Model for Bandwidth Availability Topology | |||||||||||||||||
|
This document defines a YANG data model to describe bandwidth availability for a link in a network topology. Discussion Venues This note is to be removed before publishing as an RFC. Source for this draft and an issue tracker can be found at https://github.com/ietf-ccamp-wg/draft-ietf-ccamp-mw-topo-yang. | ||||||||||||||||
| draft-ietf-ccamp-client-signal-yang-08.txt | |||||||||||||||||
| A YANG Data Model for Transport Network Client Signals | |||||||||||||||||
|
A transport network is a server-layer network to provide connectivity services to its client. The topology and tunnel information in the transport layer has already been defined by generic Traffic- engineered models and technology-specific models (e.g., OTN, WSON). However, how the client signals are accessing to the network has not been described. These information is necessary to both client and provider. This draft describes how the client signals are carried over transport network and defines YANG data models which are required during configuration procedure. More specifically, several client signal (of transport network) models including ETH, STM-n, FC and so on, are defined in this draft. | ||||||||||||||||
| draft-ietf-ccamp-dwdm-if-lmp-07.txt | |||||||||||||||||
| Extension to the Link Management Protocol (LMP/DWDM -rfc4209) for Dense Wavelength Division Multiplexing (DWDM) Optical Line Systems to manage the application code of optical interface parameters in DWDM application | |||||||||||||||||
|
This memo defines extensions to LMP RFC4209 for managing Optical parameters associated with Wavelength Division Multiplexing (WDM) systems in accordance with the Interface Application Identifier approach defined in ITU-T Recommendation G.694.1 and its extensions. | ||||||||||||||||
| draft-ietf-ccamp-dwdm-if-param-yang-09.txt | |||||||||||||||||
| A YANG model to manage the optical interface parameters for an external transponder in a WDM network | |||||||||||||||||
|
This memo defines a Yang model related to the Optical Transceiver parameters characterising coherent 100G and above interfaces. 100G and above Transceivers support coherent modulation, multiple modulation formats, multiple FEC codes including some not yet specified (or by in phase of specification by) ITU-T G.698.2 or any other ITU-T recommendation. Use cases are described in RFC7698. The Yang model defined in this memo can be used for Optical Parameters monitoring and/or configuration of the endpoints of a multi-vendor IaDI optical link. The use of this model does not guarantee interworking of transceivers over a DWDM. Optical path feasibility and interoperability has to be determined by tools and algorithms outside the scope of this document. The purpose of this model is to program interface parameters to consistently configure the mode of operation of transceivers. | ||||||||||||||||
| draft-ietf-ccamp-eth-client-te-topo-yang-04.txt | |||||||||||||||||
| A YANG Data Model for Ethernet TE Topology | |||||||||||||||||
|
A transport network is a server-layer network to provide connectivity services to its client. In this draft the topology of Ethernet with TE is described with YANG data model. | ||||||||||||||||
| draft-ietf-ccamp-flexe-yang-cm-01.txt | |||||||||||||||||
| YANG Data Model for FlexE Management | |||||||||||||||||
|
This document defines a service provider targeted YANG data model for the configuration and management of a Flex Ethernet (FlexE) network, including FlexE group and FlexE client. The YANG module in this document conforms to the Network Management Datastore Architecture (NMDA). | ||||||||||||||||
| draft-ietf-ccamp-flexigrid-tunnel-yang-02.txt | |||||||||||||||||
| A YANG Data Model for Flexi-Grid Tunnels | |||||||||||||||||
|
This document defines a YANG model for managing flexi-grid optical tunnels (media-channels), complementing the information provided by the flexi-grid topology model. The YANG data model defined in this document conforms to the Network Management Datastore Architecture (NMDA). | ||||||||||||||||
| draft-ietf-ccamp-flexigrid-yang-14.txt | |||||||||||||||||
| A YANG Data Model for Flexi-Grid Optical Networks | |||||||||||||||||
|
This document defines a YANG module for managing flexi-grid optical networks. The model defined in this document specifies a flexi-grid traffic engineering database that is used to describe the topology of a flexi-grid network. It is based on and augments existing YANG models that describe network and traffic engineering topologies. The YANG data model defined in this document conforms to the Network Management Datastore Architecture (NMDA). | ||||||||||||||||
| draft-ietf-ccamp-if-ref-topo-yang-00.txt | |||||||||||||||||
| A YANG Data Model for Interface Reference Topology | |||||||||||||||||
|
This document defines a YANG data model to provide a reference from a termination point in a topology model to interface management information. Discussion Venues This note is to be removed before publishing as an RFC. Source for this draft and an issue tracker can be found at https://github.com/ietf-ccamp-wg/draft-ietf-ccamp-mw-topo-yang. | ||||||||||||||||
| draft-ietf-ccamp-l1csm-yang-23.txt | |||||||||||||||||
| A YANG Data Model for L1 Connectivity Service Model (L1CSM) | |||||||||||||||||
|
This document provides a YANG Layer 1 Connectivity Service Model (L1CSM). This model can be utilized by a customer network controller to initiate a connectivity service request as well as to retrieve service states for a Layer 1 network controller communicating with its customer network controller. This YANG model is in compliance of Network Management Datastore Architecture (NMDA). | ||||||||||||||||
| draft-ietf-ccamp-layer1-types-15.txt | |||||||||||||||||
| A YANG Data Model for Layer 1 Types | |||||||||||||||||
|
This document defines a collection of common data types and groupings in the YANG data modeling language for use with layer 1 networks. These derived common types and groupings are intended to be imported by modules that specify OTN networks, such as topology, tunnel, client signal adaptation and service. | ||||||||||||||||
| draft-ietf-ccamp-mw-topo-yang-05.txt | |||||||||||||||||
| A YANG Data Model for Microwave Topology | |||||||||||||||||
|
This document defines a YANG data model to describe microwave/ millimeter radio links in a network topology. Discussion Venues This note is to be removed before publishing as an RFC. Source for this draft and an issue tracker can be found at https://github.com/ietf-ccamp-wg/draft-ietf-ccamp-mw-topo-yang. | ||||||||||||||||
| draft-ietf-ccamp-network-inventory-yang-01.txt | |||||||||||||||||
| A YANG Data Model for Network Hardware Inventory | |||||||||||||||||
|
This document defines a YANG data model for network hardware inventory data information. The YANG data model presented in this document is intended to be used as the basis toward a generic YANG data model for network hardware inventory data information which can be augmented, when required, with technology-specific (e.g., optical) inventory data, to be defined either in a future version of this document or in another document. The YANG data model defined in this document conforms to the Network Management Datastore Architecture (NMDA). | ||||||||||||||||
| draft-ietf-ccamp-optical-impairment-topology-yang-12.txt | |||||||||||||||||
| A YANG Data Model for Optical Impairment-aware Topology | |||||||||||||||||
|
In order to provision an optical connection through optical networks, a combination of path continuity, resource availability, and impairment constraints must be met to determine viable and optimal paths through the network. The determination of appropriate paths is known as Impairment-Aware Routing and Wavelength Assignment (IA-RWA) for WSON, while it is known as Impairment-Aware Routing and Spectrum Assignment (IA-RSA) for SSON. This document provides a YANG data model for the impairment-aware TE topology in optical networks. | ||||||||||||||||
| draft-ietf-ccamp-optical-path-computation-yang-00.txt | |||||||||||||||||
| YANG Data Models for requesting Path Computation in Optical Networks | |||||||||||||||||
|
This document provides a mechanism to request path computation in Optical Networks (WSON and Flexi-grid) by augmenting the Remote Procedure Calls (RPCs) defined in RFC YYYY. [RFC EDITOR NOTE: Please replace RFC YYYY with the RFC number of draft-ietf-teas-yang-path-computation once it has been published. | ||||||||||||||||
| draft-ietf-ccamp-otn-path-computation-yang-00.txt | |||||||||||||||||
| A YANG Data Model for requesting Path Computation in an Optical Transport Network (OTN) | |||||||||||||||||
|
This document provides a mechanism to request path computation in an Optical Transport Network (OTN) by augmenting the Remote Procedure Calls (RPCs) defined in RFC YYYY. [RFC EDITOR NOTE: Please replace RFC YYYY with the RFC number of draft-ietf-teas-yang-path-computation once it has been published. | ||||||||||||||||
| draft-ietf-ccamp-otn-topo-yang-16.txt | |||||||||||||||||
| A YANG Data Model for Optical Transport Network Topology | |||||||||||||||||
|
This document describes a YANG data model to describe the topologies of an Optical Transport Network (OTN). It is independent of control plane protocols and captures topological and resource-related information pertaining to OTN. This model enables clients, which interact with a transport domain controller, for OTN topology-related operations such as obtaining the relevant topology resource information. | ||||||||||||||||
| draft-ietf-ccamp-otn-tunnel-model-18.txt | |||||||||||||||||
| OTN Tunnel YANG Model | |||||||||||||||||
|
This document describes the YANG data model for tunnels in OTN TE networks. The model can be used to do the configuration in order to establish the tunnel in OTN network. This work is independent with the control plane protocols. | ||||||||||||||||
| draft-ietf-ccamp-rfc9093-bis-04.txt | |||||||||||||||||
| A YANG Data Model for Layer 0 Types | |||||||||||||||||
|
This document defines a collection of common data types and groupings in the YANG data modeling language. These derived common types and groupings are intended to be imported by modules that model Layer 0 optical Traffic Engineering (TE) configuration and state capabilities such as Wavelength Switched Optical Networks (WSONs) and flexi-grid Dense Wavelength Division Multiplexing (DWDM) networks. This document obsoletes RFC 9093. | ||||||||||||||||
| draft-ietf-ccamp-wson-tunnel-model-08.txt | |||||||||||||||||
| A Yang Data Model for WSON Tunnel | |||||||||||||||||
|
This document provides a YANG data model for WSON TE tunnel. | ||||||||||||||||
| draft-ietf-ccamp-yang-otn-slicing-04.txt | |||||||||||||||||
| Framework and Data Model for OTN Network Slicing | |||||||||||||||||
|
The requirement of slicing network resources with desired quality of service is emerging at every network technology, including the Optical Transport Networks (OTN). As a part of the transport network, OTN can provide hard pipes with guaranteed data isolation and deterministic low latency, which are highly demanded in the Service Level Agreement (SLA). This document describes a framework for OTN network slicing and defines YANG data models with OTN technology-specific augments deployed at both the north and south bound of the OTN network slice controller. Additional YANG data model augmentations will be defined in a future version of this draft. | ||||||||||||||||
| draft-ietf-cdni-additional-footprint-types-11.txt | |||||||||||||||||
| Content Delivery Network Interconnection (CDNI) Footprint Types: Subdivision Code and Footprint Union | |||||||||||||||||
|
Open Caching architecture is a use case of Content Delivery Networks Interconnection (CDNI) in which the commercial Content Delivery Network (CDN) is the upstream CDN (uCDN) and the ISP caching layer serves as the downstream CDN (dCDN). This document supplements the CDNI Metadata Footprint Types defined in RFC 8006. The Footprint Types defined in this document can be used for Footprint objects as part of the Metadata interface (MI) defined in RFC 8006 and for the Footprint & Capabilities Advertisement interface (FCI) defined in RFC 8008. By defining the footprint union Footprint Type, this document updates RFC 8008, allowing an additive semantic over the narrowing semantics defined in Appendix B of RFC 8008. This document also supplements RFC 9241 with relevant ALTO entity domain types. The defined Footprint Types are derived from requirements raised by Open Caching but are also applicable to CDNI use cases in general. | ||||||||||||||||
| draft-ietf-cdni-capacity-insights-extensions-01.txt | |||||||||||||||||
| CDNI Capacity Capability Advertisement Extensions | |||||||||||||||||
|
Open Caching architecture is a use case of Content Delivery Networks Interconnection (CDNI) in which the commercial Content Delivery Network (CDN) is the upstream CDN (uCDN) and the ISP caching layer serves as the downstream CDN (dCDN). This document supplements to the CDNI Capability Objects defined in RFC 8008 the defined capability objects structure and interface for advertisements and management of a downstream CDN capacity. | ||||||||||||||||
| draft-ietf-cdni-ci-triggers-rfc8007bis-04.txt | |||||||||||||||||
| Content Delivery Network Interconnection (CDNI) Control Interface / Triggers 2nd Edition | |||||||||||||||||
|
This document obsoletes RFC8007. This document describes the part of the Content Delivery Network Interconnection (CDNI) Control interface that allows a CDN to trigger activity in an interconnected CDN that is configured to deliver content on its behalf. The upstream CDN can use this mechanism to request that the downstream CDN pre-position metadata or content or to request that it invalidate or purge metadata or content. The upstream CDN can monitor the status of activity that it has triggered in the downstream CDN. | ||||||||||||||||
| draft-ietf-cdni-delegation-acme-01.txt | |||||||||||||||||
| CDNI delegation using Automated Certificate Management Environment | |||||||||||||||||
|
This document defines metadata to support delegating the delivery of HTTPS content between two or more interconnected CDNs. Specifically, this document defines a CDNI Metadata interface object to enable delegation of X.509 certificates leveraging delegation schemes defined in RFC9115. RFC9115 allows delegating entities to remain in full control of the delegation and be able to revoke it any time and this avoids the need to share private cryptographic key material between the involved entities. | ||||||||||||||||
| draft-ietf-cdni-https-delegation-subcerts-02.txt | |||||||||||||||||
| CDNI Metadata for Delegated Credentials | |||||||||||||||||
|
The delivery of content over HTTPS involving multiple CDNs raises credential management issues. This document defines metadata in CDNI Control and Metadata interface to setup HTTPS delegation using Delegated Credentials from an Upstream CDN (uCDN) to a Downstream CDN (dCDN). | ||||||||||||||||
| draft-ietf-cellar-chapter-codecs-02.txt | |||||||||||||||||
| Matroska Media Container Chapter Codecs Specifications | |||||||||||||||||
|
This document defines common Matroska Chapter Codecs, the basic Matroska Script and the DVD inspired DVD menu [DVD-Video]. | ||||||||||||||||
| draft-ietf-cellar-codec-10.txt | |||||||||||||||||
| Matroska Media Container Codec Specifications | |||||||||||||||||
|
This document defines the Matroska codec mappings, including the codec ID, layout of data in a Block Element and in an optional CodecPrivate Element. | ||||||||||||||||
| draft-ietf-cellar-control-02.txt | |||||||||||||||||
| Matroska Media Container Control Track Specifications | |||||||||||||||||
|
This document defines the Control Track usage found in the Matroska container. | ||||||||||||||||
| draft-ietf-cellar-ffv1-v4-20.txt | |||||||||||||||||
| FFV1 Video Coding Format Version 4 | |||||||||||||||||
|
This document defines FFV1, a lossless, intra-frame video encoding format. FFV1 is designed to efficiently compress video data in a variety of pixel formats. Compared to uncompressed video, FFV1 offers storage compression, frame fixity, and self-description, which makes FFV1 useful as a preservation or intermediate video format. | ||||||||||||||||
| draft-ietf-cellar-flac-08.txt | |||||||||||||||||
| Free Lossless Audio Codec | |||||||||||||||||
|
This document defines the Free Lossless Audio Codec (FLAC) format and its streamable subset. FLAC is designed to reduce the amount of computer storage space needed to store digital audio signals without losing information in doing so (i.e. lossless). FLAC is free in the sense that its specification is open and its reference implementation is open-source. Compared to other lossless (audio) coding formats, FLAC is a format with low complexity and can be coded to and from with little computing resources. Decoding of FLAC has seen many independent implementations on many different platforms, and both encoding and decoding can be implemented without needing floating- point arithmetic. | ||||||||||||||||
| draft-ietf-cellar-matroska-16.txt | |||||||||||||||||
| Matroska Media Container Format Specifications | |||||||||||||||||
|
This document defines the Matroska audiovisual data container structure, including definitions of its structural elements, as well as its terminology, vocabulary, and application. | ||||||||||||||||
| draft-ietf-cellar-tags-10.txt | |||||||||||||||||
| Matroska Media Container Tag Specifications | |||||||||||||||||
|
This document defines the Matroska tags, namely the tag names and their respective semantic meaning. | ||||||||||||||||
| draft-ietf-core-attacks-on-coap-02.txt | |||||||||||||||||
| Attacks on the Constrained Application Protocol (CoAP) | |||||||||||||||||
|
Being able to securely read information from sensors, to securely control actuators, and to not enable distributed denial-of-service attacks are essential in a world of connected and networking things interacting with the physical world. Using a security protocol such as DTLS, TLS, or OSCORE to protect CoAP is a requirement for secure operation and protects against many attacks. This document summarizes a number of known attacks on CoAP deployments and show that just using CoAP with a security protocol like DTLS, TLS, or OSCORE is not enough for secure operation. Several of the discussed attacks can be mitigated with the solutions in RFC 9175. | ||||||||||||||||
| draft-ietf-core-coap-pm-00.txt | |||||||||||||||||
| Constrained Application Protocol (CoAP) Performance Measurement Option | |||||||||||||||||
|
This document specifies a method for the Performance Measurement of the Constrained Application Protocol (CoAP). A new CoAP option is defined in order to enable network telemetry both end-to-end and hop- by-hop. The endpoints cooperate by marking and, possibly, mirroring information on the round-trip connection. | ||||||||||||||||
| draft-ietf-core-coap-pubsub-12.txt | |||||||||||||||||
| A publish-subscribe architecture for the Constrained Application Protocol (CoAP) | |||||||||||||||||
|
This document describes a publish-subscribe architecture for CoAP that extends the capabilities of CoAP for supporting nodes with long breaks in connectivity and/or up-time. The Constrained Application Protocol (CoAP) is used by CoAP clients both to publish and to subscribe via a known topic resource. | ||||||||||||||||
| draft-ietf-core-comi-12.txt | |||||||||||||||||
| CoAP Management Interface (CORECONF) | |||||||||||||||||
|
This document describes a network management interface for constrained devices and networks, called CoAP Management Interface (CORECONF). The Constrained Application Protocol (CoAP) is used to access datastore and data node resources specified in YANG, or SMIv2 converted to YANG. CORECONF uses the YANG to CBOR mapping and converts YANG identifier strings to numeric identifiers for payload size reduction. CORECONF extends the set of YANG based protocols, NETCONF and RESTCONF, with the capability to manage constrained devices and networks. | ||||||||||||||||
| draft-ietf-core-conditional-attributes-06.txt | |||||||||||||||||
| Conditional Attributes for Constrained RESTful Environments | |||||||||||||||||
|
This specification defines Conditional Notification and Control Attributes that work with CoAP Observe (RFC7641). Editor note The git repository for the draft is found at https://github.com/core- wg/conditional-attributes/ | ||||||||||||||||
| draft-ietf-core-dns-over-coap-02.txt | |||||||||||||||||
| DNS over CoAP (DoC) | |||||||||||||||||
|
This document defines a protocol for sending DNS messages over the Constrained Application Protocol (CoAP). These CoAP messages are protected by DTLS-Secured CoAP (CoAPS) or Object Security for Constrained RESTful Environments (OSCORE) to provide encrypted DNS message exchange for constrained devices in the Internet of Things (IoT). | ||||||||||||||||
| draft-ietf-core-fasor-02.txt | |||||||||||||||||
| Fast-Slow Retransmission Timeout and Congestion Control Algorithm for CoAP | |||||||||||||||||
|
This document specifies an alternative retransmission timeout (RTO) and congestion control back off algorithm for the CoAP protocol, called Fast-Slow RTO (FASOR). The algorithm specified in this document employs an appropriate and large enough back off of RTO as the major congestion control mechanism to allow acquiring unambiguous RTT samples with high probability and to prevent building a persistent queue when retransmitting. The algorithm also aims to retransmit quickly using an accurately managed RTO when link-errors are occuring, basing RTO calculation on unambiguous round-trip time (RTT) samples. | ||||||||||||||||
| draft-ietf-core-groupcomm-bis-08.txt | |||||||||||||||||
| Group Communication for the Constrained Application Protocol (CoAP) | |||||||||||||||||
|
This document specifies the use of the Constrained Application Protocol (CoAP) for group communication, including the use of UDP/IP multicast as the default underlying data transport. Both unsecured and secured CoAP group communication are specified. Security is achieved by use of the Group Object Security for Constrained RESTful Environments (Group OSCORE) protocol. The target application area of this specification is any group communication use cases that involve resource-constrained devices or networks that support CoAP. This document replaces RFC 7390, while it updates RFC 7252 and RFC 7641. | ||||||||||||||||
| draft-ietf-core-href-12.txt | |||||||||||||||||
| Constrained Resource Identifiers | |||||||||||||||||
|
The Constrained Resource Identifier (CRI) is a complement to the Uniform Resource Identifier (URI) that serializes the URI components in Concise Binary Object Representation (CBOR) instead of a sequence of characters. This simplifies parsing, comparison and reference resolution in environments with severe limitations on processing power, code size, and memory size. // The present revision -12 of this draft adds a registry that is // intended to provide full coverage for representing a URI scheme // (and certain text strings used in their place) as negative // integers. | ||||||||||||||||
| draft-ietf-core-observe-multicast-notifications-05.txt | |||||||||||||||||
| Observe Notifications as CoAP Multicast Responses | |||||||||||||||||
|
The Constrained Application Protocol (CoAP) allows clients to "observe" resources at a server, and receive notifications as unicast responses upon changes of the resource state. In some use cases, such as based on publish-subscribe, it would be convenient for the server to send a single notification addressed to all the clients observing a same target resource. This document updates RFC7252 and RFC7641, and defines how a server sends observe notifications as response messages over multicast, synchronizing all the observers of a same resource on a same shared Token value. Besides, this document defines how Group OSCORE can be used to protect multicast notifications end-to-end between the server and the observer clients. | ||||||||||||||||
| draft-ietf-core-oscore-edhoc-07.txt | |||||||||||||||||
| Using EDHOC with CoAP and OSCORE | |||||||||||||||||
|
The lightweight authenticated key exchange protocol EDHOC can be run over CoAP and used by two peers to establish an OSCORE Security Context. This document details this use of the EDHOC protocol, by specifying a number of additional and optional mechanisms. These especially include an optimization approach for combining the execution of EDHOC with the first OSCORE transaction. This combination reduces the number of round trips required to set up an OSCORE Security Context and to complete an OSCORE transaction using that Security Context. | ||||||||||||||||
| draft-ietf-core-oscore-groupcomm-17.txt | |||||||||||||||||
| Group OSCORE - Secure Group Communication for CoAP | |||||||||||||||||
|
This document defines Group Object Security for Constrained RESTful Environments (Group OSCORE), providing end-to-end security of CoAP messages exchanged between members of a group, e.g., sent over IP multicast. In particular, the described approach defines how OSCORE is used in a group communication setting to provide source authentication for CoAP group requests, sent by a client to multiple servers, and for protection of the corresponding CoAP responses. Group OSCORE also defines a pairwise mode where each member of the group can efficiently derive a symmetric pairwise key with any other member of the group for pairwise OSCORE communication. | ||||||||||||||||
| draft-ietf-core-oscore-key-limits-00.txt | |||||||||||||||||
| Key Usage Limits for OSCORE | |||||||||||||||||
|
Object Security for Constrained RESTful Environments (OSCORE) uses AEAD algorithms to ensure confidentiality and integrity of exchanged messages. Due to known issues allowing forgery attacks against AEAD algorithms, limits should be followed on the number of times a specific key is used for encryption or decryption. Among other reasons, approaching key usage limits requires updating the OSCORE keying material before communications can securely continue. This document defines how two OSCORE peers can follow these key usage limits and what steps they should take to preserve the security of their communications. | ||||||||||||||||
| draft-ietf-core-oscore-key-update-04.txt | |||||||||||||||||
| Key Update for OSCORE (KUDOS) | |||||||||||||||||
|
This document defines Key Update for OSCORE (KUDOS), a lightweight procedure that two CoAP endpoints can use to update their keying material by establishing a new OSCORE Security Context. Accordingly, it updates the use of the OSCORE flag bits in the CoAP OSCORE Option as well as the protection of CoAP response messages with OSCORE, and it deprecates the key update procedure specified in Appendix B.2 of RFC 8613. Thus, this document updates RFC 8613. Also, this document defines a procedure that two endpoints can use to update their OSCORE identifiers, run either stand-alone or during a KUDOS execution. | ||||||||||||||||
| draft-ietf-core-sid-20.txt | |||||||||||||||||
| YANG Schema Item iDentifier (YANG SID) | |||||||||||||||||
|
YANG Schema Item iDentifiers (YANG SID) are globally unique 63-bit unsigned integers used to identify YANG items, as a more compact method to identify YANG items that can be used for efficiency and in constrained environments (RFC 7228). This document defines the semantics, the registration, and assignment processes of YANG SIDs for IETF managed YANG modules. To enable the implementation of these processes, this document also defines a file format used to persist and publish assigned YANG SIDs. // The present version (-20) is intended to address all IESG // feedback. It has significantly progressed from -16, which was the // original submission to the IESG. | ||||||||||||||||
| draft-ietf-core-target-attr-04.txt | |||||||||||||||||
| CoRE Target Attributes Registry | |||||||||||||||||
|
The Constrained RESTful Environments (CoRE) specifications apply Web technologies to constrained environments. One important such technology is Web Linking (RFC 8288), which CoRE uses as the basis for a number of discovery protocols, such as the Link Format (RFC 6690) in CoAP's Resource Discovery Protocol (Section 7.2 of RFC7252) and the Resource Directory (RFC 9176). Web Links can have target attributes, the names of which are not generally coordinated by the Web Linking specification (Section 2.2 of RFC 8288). This document introduces an IANA registry for coordinating names of target attributes when used in Constrained RESTful Environments. It updates the RD Parameters Registry of RFC 9176 to coordinate with this registry. | ||||||||||||||||
| draft-ietf-core-transport-indication-02.txt | |||||||||||||||||
| CoAP Protocol Indication | |||||||||||||||||
|
The Constrained Application Protocol (CoAP, [RFC7252]) is available over different transports (UDP, DTLS, TCP, TLS, WebSockets), but lacks a way to unify these addresses. This document provides terminology and provisions based on Web Linking [RFC8288] to express alternative transports available to a device, and to optimize exchanges using these. | ||||||||||||||||
| draft-ietf-cose-aes-ctr-and-cbc-03.txt | |||||||||||||||||
| CBOR Object Signing and Encryption (COSE): AES-CTR and AES-CBC | |||||||||||||||||
|
The Concise Binary Object Representation (CBOR) data format is designed for small code size and small message size. CBOR Object Signing and Encryption (COSE) is specified in RFC 9052 to provide basic security services using the CBOR data format. This document specifies the conventions for using AES-CTR and AES-CBC as Content Encryption algorithms with COSE. | ||||||||||||||||
| draft-ietf-cose-bls-key-representations-02.txt | |||||||||||||||||
| Barreto-Lynn-Scott Elliptic Curve Key Representations for JOSE and COSE | |||||||||||||||||
|
This specification defines how to represent cryptographic keys for the pairing-friendly elliptic curves known as Barreto-Lynn-Scott (BLS), for use with the key representation formats of JSON Web Key (JWK) and COSE (COSE_Key). Discussion Venues This note is to be removed before publishing as an RFC. Source for this draft and an issue tracker can be found at https://github.com/tplooker/draft-ietf-cose-bls-key-representations. | ||||||||||||||||
| draft-ietf-cose-cbor-encoded-cert-05.txt | |||||||||||||||||
| CBOR Encoded X.509 Certificates (C509 Certificates) | |||||||||||||||||
|
This document specifies a CBOR encoding of X.509 certificates. The resulting certificates are called C509 Certificates. The CBOR encoding supports a large subset of RFC 5280 and all certificates compatible with the RFC 7925, IEEE 802.1AR (DevID), CNSA, RPKI, GSMA eUICC, and CA/Browser Forum Baseline Requirements profiles. When used to re-encode DER encoded X.509 certificates, the CBOR encoding can in many cases reduce the size of RFC 7925 profiled certificates with over 50%. The CBOR encoded structure can alternatively be signed directly ("natively signed"), which does not require re- encoding for the signature to be verified. The document also specifies C509 COSE headers, a C509 TLS certificate type, and a C509 file format. | ||||||||||||||||
| draft-ietf-cose-cwt-claims-in-headers-03.txt | |||||||||||||||||
| CBOR Web Token (CWT) Claims in COSE Headers | |||||||||||||||||
|
This document describes how to include CBOR Web Token (CWT) claims in the header parameters of any COSE structure. This functionality helps to facilitate applications that wish to make use of CBOR Web Token (CWT) claims in encrypted COSE structures and/or COSE structures featuring detached signatures, while having some of those claims be available before decryption and/or without inspecting the detached payload. | ||||||||||||||||
| draft-ietf-cose-dilithium-00.txt | |||||||||||||||||
| JOSE and COSE Encoding for Dilithium | |||||||||||||||||
|
This document describes JSON and CBOR serializations for CRYSTALS Dilithium, a Post-Quantum Cryptography (PQC) based suite. This document does not define any new cryptography, only seralizations of existing cryptographic systems. This document registers key types for JOSE and COSE, specifically LWE. Key types in this document are specified by the cryptographic algorithm family in use by a particular algorithm as discussed in RFC7517. This document registers signature algorithms types for JOSE and COSE, specifically CRYDI3 and others as required for use of various parameterizations of the post-quantum signature scheme CRYSTALS Dilithium. | ||||||||||||||||
| draft-ietf-cose-falcon-00.txt | |||||||||||||||||
| JOSE and COSE Encoding for Falcon | |||||||||||||||||
|
This document describes JSON and CBOR serializations for Falcon, a Post-Quantum Cryptography (PQC) signature suite. This document does not define any new cryptography, only seralizations of existing cryptographic systems. This document registers key types for JOSE and COSE, specifically NTRU. Key types in this document are specified by the cryptographic algorithm family in use by a particular algorithm as discussed in RFC7517. This document registers signature algorithms types for JOSE and COSE, specifically FALCON1024 and others as required for use of various parameterizations of the Falcon post-quantum signature scheme. | ||||||||||||||||
| draft-ietf-cose-hpke-05.txt | |||||||||||||||||
| Use of Hybrid Public-Key Encryption (HPKE) with CBOR Object Signing and Encryption (COSE) | |||||||||||||||||
|
This specification defines hybrid public-key encryption (HPKE) for use with CBOR Object Signing and Encryption (COSE). HPKE offers a variant of public-key encryption of arbitrary-sized plaintexts for a recipient public key. HPKE works for any combination of an asymmetric key encapsulation mechanism (KEM), key derivation function (KDF), and authenticated encryption with additional data (AEAD) function. Authentication for HPKE in COSE is provided by COSE-native security mechanisms. This document defines the use of the HPKE base mode with COSE. Other modes are supported by HPKE but not by this specification. | ||||||||||||||||
| draft-ietf-cose-sphincs-plus-00.txt | |||||||||||||||||
| JOSE and COSE Encoding for SPHINCS+ | |||||||||||||||||
|
This document describes JSON and CBOR serializations for SPHINCS+, a Post-Quantum Cryptography (PQC) signature suite. This document does not define any new cryptography, only seralizations of existing cryptographic systems. This document registers key types for JOSE and COSE, specifically HASH. Key types in this document are specified by the cryptographic algorithm family in use by a particular algorithm as discussed in RFC7517. This document registers signature algorithms types for JOSE and COSE, specifically SPHINCS+256s and others as required for use of various parameterizations of the SPHINCS+ post-quantum signature scheme. | ||||||||||||||||
| draft-ietf-dance-architecture-01.txt | |||||||||||||||||
| An Architecture for DNS-Bound Client and Sender Identities | |||||||||||||||||
|
This architecture document defines terminology, interaction, and authentication patterns, related to the use of DANE DNS records for TLS client and messaging peer identity, within the context of existing object security and TLS-based protocols. | ||||||||||||||||
| draft-ietf-dance-client-auth-01.txt | |||||||||||||||||
| TLS Client Authentication via DANE TLSA records | |||||||||||||||||
|
The DANE TLSA protocol [RFC6698] [RFC7671] describes how to publish Transport Layer Security (TLS) server certificates or public keys in the DNS. This document updates RFC 6698 and RFC 7671. It describes how to additionally use the TLSA record to publish client certificates or public keys, and also the rules and considerations for using them with TLS. | ||||||||||||||||
| draft-ietf-dance-tls-clientid-01.txt | |||||||||||||||||
| TLS Extension for DANE Client Identity | |||||||||||||||||
|
This document specifies a TLS and DTLS extension to convey a DNS- Based Authentication of Named Entities (DANE) Client Identity to a TLS or DTLS server. This is useful for applications that perform TLS client authentication via DANE TLSA records. | ||||||||||||||||
| draft-ietf-detnet-controller-plane-framework-04.txt | |||||||||||||||||
| Deterministic Networking (DetNet) Controller Plane Framework | |||||||||||||||||
|
This document provides a framework overview for the Deterministic Networking (DetNet) controller plane. It discusses concepts and requirements for DetNet controller plane which could be basis for future solution specification. | ||||||||||||||||
| draft-ietf-detnet-ip-oam-06.txt | |||||||||||||||||
| Operations,Administration and Maintenance (OAM) for Deterministic Networks (DetNet) with IP Data Plane | |||||||||||||||||
|
This document defines the principles for using Operations, Administration, and Maintenance protocols and mechanisms in the Deterministic Networking networks with the IP data plane. | ||||||||||||||||
| draft-ietf-detnet-mpls-oam-11.txt | |||||||||||||||||
| Operations,Administration and MaintenVersion field is neededance (OAM) for Deterministic Networks (DetNet) with MPLS Data Plane | |||||||||||||||||
|
This document defines format and use principles of the Deterministic Network (DetNet) service Associated Channel (ACH) over a DetNet network with the MPLS data plane. The DetNet service ACH can be used to carry test packets of active Operations, Administration, and Maintenance protocols that are used to detect DetNet failures and measure performance metrics. | ||||||||||||||||
| draft-ietf-detnet-mpls-over-ip-preof-02.txt | |||||||||||||||||
| Deterministic Networking (DetNet): DetNet PREOF via MPLS over UDP/IP | |||||||||||||||||
|
This document describes how DetNet IP data plane can support the Packet Replication, Elimination, and Ordering Functions (PREOF) built on the existing MPLS PREOF solution [RFC8939] and the mechanisms defined in [RFC9025]. | ||||||||||||||||
| draft-ietf-detnet-oam-framework-08.txt | |||||||||||||||||
| Framework of Operations,Administration and Maintenance (OAM) for Deterministic Networking (DetNet) | |||||||||||||||||
|
Deterministic Networking (DetNet), as defined in RFC 8655, is aimed to provide a bounded end-to-end latency on top of the network infrastructure, comprising both Layer 2 bridged and Layer 3 routed segments. This document's primary purpose is to detail the specific requirements of the Operation, Administration, and Maintenance (OAM) recommended to maintain a deterministic network. The document will be used in future work that defines the applicability of and extension of OAM protocols for a deterministic network. With the implementation of the OAM framework in DetNet, an operator will have a real-time view of the network infrastructure regarding the network's ability to respect the Service Level Objective, such as packet delay, delay variation, and packet loss ratio, assigned to each DetNet flow. | ||||||||||||||||
| draft-ietf-detnet-pof-01.txt | |||||||||||||||||
| Deterministic Networking (DetNet): Packet Ordering Function | |||||||||||||||||
|
Replication and Elimination functions of DetNet [RFC8655] may result in out-of-order packets, which may not be acceptable for some time- sensitive applications. The Packet Ordering Function (POF) algorithm described herein enables to restore the correct packet order when replication and elimination functions are used in DetNet networks. | ||||||||||||||||
| draft-ietf-detnet-scaling-requirements-01.txt | |||||||||||||||||
| Requirements for Scaling Deterministic Networks | |||||||||||||||||
|
Aiming at scaling deterministic networks, this document describes the technical and operational requirements when the network has large variation in latency among hops, great number of flows and/or multiple domains without the same time source. Different deterministic levels of applications co-exist and are transported in such a network. This document also describes the corresponding Deterministic Networking (DetNet) data plane enhancement requirements. | ||||||||||||||||
| draft-ietf-detnet-topology-yang-01.txt | |||||||||||||||||
| Deterministic Networking (DetNet) Topology YANG Model | |||||||||||||||||
|
This document defines a YANG data model for Deterministic Networking (DetNet) topology discovery and capability configuration. The YANG module defined in this document conforms to the Network Management Datastore Architecture (NMDA). | ||||||||||||||||
| draft-ietf-detnet-yang-17.txt | |||||||||||||||||
| Deterministic Networking (DetNet) YANG Model | |||||||||||||||||
|
This document contains the specification for the Deterministic Networking YANG Model for configuration and operational data of DetNet Flows. The model allows for provisioning of end-to-end DetNet service on devices along the path without dependency on any signaling protocol. It also specifies operational status for flows. The YANG module defined in this document conforms to the Network Management Datastore Architecture (NMDA). | ||||||||||||||||
| draft-ietf-dhc-rfc8415bis-00.txt | |||||||||||||||||
| Dynamic Host Configuration Protocol for IPv6 (DHCPv6) | |||||||||||||||||
|
This document describes the Dynamic Host Configuration Protocol for IPv6 (DHCPv6): an extensible mechanism for configuring nodes with network configuration parameters, IP addresses, and prefixes. Parameters can be provided statelessly, or in combination with stateful assignment of one or more IPv6 addresses and/or IPv6 prefixes. DHCPv6 can operate either in place of or in addition to stateless address autoconfiguration (SLAAC). This document replaces RFC8415 to incorporate reported errata and to deprecate assignment of temporary addresses (the IA_TA option) and the server unicast capability (the Server Unicast option). | ||||||||||||||||
| draft-ietf-dime-group-signaling-14.txt | |||||||||||||||||
| Diameter Group Signaling | |||||||||||||||||
|
In large network deployments, a single Diameter node can support over a million concurrent Diameter sessions. In some use cases, Diameter nodes need to apply the same operation to a large group of Diameter sessions concurrently. The Diameter base protocol commands operate on a single session so these use cases could result in many thousands of command exchanges to enforce the same operation on each session in the group. In order to reduce signaling, it would be desirable to enable bulk operations on all (or part of) the sessions managed by a Diameter node using a single or a few command exchanges. This document specifies the Diameter protocol extensions to achieve this signaling optimization. | ||||||||||||||||
| draft-ietf-dmarc-aggregate-reporting-08.txt | |||||||||||||||||
| DMARC Aggregate Reporting | |||||||||||||||||
|
DMARC allows for domain holders to request aggregate reports from receivers. This report is an XML document, and contains extensible elements that allow for other types of data to be specified later. The aggregate reports can be submitted to the domain holder's specified destination as supported by the receiver. This document (along with others) obsoletes RFC7489. | ||||||||||||||||
| draft-ietf-dmarc-dmarcbis-27.txt | |||||||||||||||||
| Domain-based Message Authentication,Reporting,and Conformance (DMARC) | |||||||||||||||||
|
This document describes the Domain-based Message Authentication, Reporting, and Conformance (DMARC) protocol. DMARC permits the owner of an email author's domain name to enable verification of the domain's use, to indicate the Domain Owner's or Public Suffix Operator's message handling preference regarding failed verification, and to request reports about the use of the domain name. Mail receiving organizations can use this information when evaluating handling choices for incoming mail. This document obsoletes RFCs 7489 and 9091. | ||||||||||||||||
| draft-ietf-dmarc-failure-reporting-07.txt | |||||||||||||||||
| Domain-based Message Authentication,Reporting,and Conformance (DMARC) Failure Reporting | |||||||||||||||||
|
Domain-based Message Authentication, Reporting, and Conformance (DMARC) is a scalable mechanism by which a domain owner can request feedback about email messages using their domain in the From: address field. This document describes "failure reports," or "failed message reports," which provide details about individual messages that failed to authenticate according to the DMARC mechanism. | ||||||||||||||||
| draft-ietf-dmm-srv6-mobile-uplane-24.txt | |||||||||||||||||
| Segment Routing IPv6 for Mobile User Plane | |||||||||||||||||
|
This document discusses the applicability of SRv6 (Segment Routing IPv6) to the user-plane of mobile networks. The network programming nature of SRv6 accomplishes mobile user-plane functions in a simple manner. The statelessness of SRv6 and its ability to control both service layer path and underlying transport can be beneficial to the mobile user-plane, providing flexibility, end-to-end network slicing, and SLA control for various applications. This document discusses how SRv6 (Segment Routing over IPv6) could be used as user-plane of mobile networks. This document also specifies the SRv6 Segment Endpoint behaviors required for mobility use-cases. | ||||||||||||||||
| draft-ietf-dmm-tn-aware-mobility-06.txt | |||||||||||||||||
| Mobility aware Transport Network Slicing for 5G | |||||||||||||||||
|
Network slicing in 5G enables the multiplexing of logical networks over the same infrastructure. 5G signaling and user's data plane packets over the radio access network (RAN) and mobile core network (5GC) use IP transport in many segments of the end-to-end 5G slice. When end-to-end slices in a 5G system use IP network resources, they are mapped to corresponding IP transport network slice(s) which in turn provide the bandwidth, latency, isolation and other criteria requested by the 5G slice. This document describes mapping of 5G slices to IP or Layer 2 transport network slices when the IP transport network (slice provider) is separated from the networks in which the 5G network functions are deployed (for example, 5G functions distributed across data centers). The slice mapping proposed here is supported transparently when a 5G user device moves across 5G attachment points and session anchors. | ||||||||||||||||
| draft-ietf-dnsop-alt-tld-23.txt | |||||||||||||||||
| The ALT Special Use Top Level Domain | |||||||||||||||||
|
This document reserves a TLD label, "alt" to be used in non-DNS contexts. It also provides advice and guidance to developers developing alternative namespaces. [ This document is being collaborated on in Github at | ||||||||||||||||
| draft-ietf-dnsop-avoid-fragmentation-12.txt | |||||||||||||||||
| Fragmentation Avoidance in DNS | |||||||||||||||||
|
EDNS0 enables a DNS server to send large responses using UDP and is widely deployed. Large DNS/UDP responses are fragmented, and IP fragmentation has exposed weaknesses in application protocols. It is possible to avoid IP fragmentation in DNS by limiting response size where possible, and signaling the need to upgrade from UDP to TCP transport where necessary. This document proposes techniques to avoid IP fragmentation in DNS. | ||||||||||||||||
| draft-ietf-dnsop-caching-resolution-failures-02.txt | |||||||||||||||||
| Negative Caching of DNS Resolution Failures | |||||||||||||||||
|
In the DNS, resolvers employ caching to reduce both latency for end users and load on authoritative name servers. The process of resolution may result in one of three types of responses: (1) a response containing the requested data; (2) a response indicating the requested data does not exist; or (3) a non-response due to a resolution failure in which the resolver does not receive any useful information regarding the data's existence. This document concerns itself only with the third type. RFC 2308 specifies requirements for DNS negative caching. There, caching of type (1) and (2) responses is mandatory and caching of type (3) responses is optional. This document updates RFC 2308 to require negative caching for DNS resolution failures. | ||||||||||||||||
| draft-ietf-dnsop-dns-catalog-zones-09.txt | |||||||||||||||||
| DNS Catalog Zones | |||||||||||||||||
|
This document describes a method for automatic DNS zone provisioning among DNS primary and secondary nameservers by storing and transferring the catalog of zones to be provisioned as one or more regular DNS zones. | ||||||||||||||||
| draft-ietf-dnsop-dns-error-reporting-04.txt | |||||||||||||||||
| DNS Error Reporting | |||||||||||||||||
|
DNS error reporting is a lightweight reporting mechanism that provides the operator of an authoritative server with reports on DNS resource records that fail to resolve or validate. A domain owner or DNS hosting organization can use these reports to improve domain hosting. The reports are based on extended DNS errors as described in RFC 8914. When a domain name fails to resolve or validate due to a misconfiguration or an attack, the operator of the authoritative server may be unaware of this. To mitigate this lack of feedback, this document describes a method for a validating recursive resolver to automatically signal an error to a monitoring agent specified by the authoritative server. | ||||||||||||||||
| draft-ietf-dnsop-dnssec-automation-01.txt | |||||||||||||||||
| DNSSEC automation | |||||||||||||||||
|
This document describes an algorithm and a protocol to automate DNSSEC Multi-Signer [RFC8901] "Multi-Signer DNSSEC Models" setup, operations and decomissioning. Using Model 2 of the Multi-Signer specification, where each operator has their own distinct KSK and ZSK sets (or CSK sets), [RFC8078] "Managing DS Records from the Parent via CDS/CDNSKEY" and [RFC7477] "Child-to-Parent Synchronization in DNS" to accomplish this. | ||||||||||||||||
| draft-ietf-dnsop-dnssec-bootstrapping-03.txt | |||||||||||||||||
| Automatic DNSSEC Bootstrapping using Authenticated Signals from the Zone's Operator | |||||||||||||||||
|
This document introduces an in-band method for DNS operators to publish arbitrary information about the zones they are authoritative for, in an authenticated fashion and on a per-zone basis. The mechanism allows managed DNS operators to securely announce DNSSEC key parameters for zones under their management, including for zones that are not currently securely delegated. Whenever DS records are absent for a zone's delegation, this signal enables the parent's registry or registrar to cryptographically validate the CDS/CDNSKEY records found at the child's apex. The parent can then provision DS records for the delegation without resorting to out-of-band validation or weaker types of cross-checks such as "Accept after Delay" ([RFC8078]). This document deprecates the DS enrollment methods described in Section 3 of [RFC8078] in favor of Section 3 of this document. [ Ed note: This document is being collaborated on at https://github.com/desec-io/draft-ietf-dnsop-dnssec-bootstrapping/ (https://github.com/desec-io/draft-ietf-dnsop-dnssec-bootstrapping/). The authors gratefully accept pull requests. ] | ||||||||||||||||
| draft-ietf-dnsop-dnssec-validator-requirements-04.txt | |||||||||||||||||
| Recommendations for DNSSEC Resolvers Operators | |||||||||||||||||
|
The DNS Security Extensions (DNSSEC) define a process for validating received data and assert them authentic and complete as opposed to forged. This document clarifies the scope and responsibilities of DNSSEC Resolver Operators (DRO) as well as operational recommendations that DNSSEC validators operators SHOULD put in place in order to implement sufficient trust that makes DNSSEC validation output accurate. The recommendations described in this document include, provisioning mechanisms as well as monitoring and management mechanisms. | ||||||||||||||||
| draft-ietf-dnsop-domain-verification-techniques-01.txt | |||||||||||||||||
| Domain Verification Techniques using DNS | |||||||||||||||||
|
Many services on the Internet need to verify ownership or control of a domain in the Domain Name System (DNS). This verification is often done by requesting a specific DNS record to be visible in the domain. There are a variety of techniques in use today, with different pros and cons. This document proposes some practices to avoid known problems. | ||||||||||||||||
| draft-ietf-dnsop-glue-is-not-optional-08.txt | |||||||||||||||||
| DNS Glue Requirements in Referral Responses | |||||||||||||||||
|
The DNS uses glue records to allow iterative clients to find the addresses of name servers that are contained within a delegated zone. Authoritative Servers are expected to return all available glue records for in-domain name servers in a referral response. If message size constraints prevent the inclusion of all glue records for in-domain name servers, the server MUST set the TC flag to inform the client that the response is incomplete, and that the client SHOULD use another transport to retrieve the full response. This document updates RFC 1034 to clarify correct server behavior. | ||||||||||||||||
| draft-ietf-dnsop-ns-revalidation-04.txt | |||||||||||||||||
| Delegation Revalidation by DNS Resolvers | |||||||||||||||||
|
This document recommends improved DNS [RFC1034] [RFC1035] resolver behavior with respect to the processing of Name Server (NS) resource record sets (RRset) during iterative resolution. When following a referral response from an authoritative server to a child zone, DNS resolvers should explicitly query the authoritative NS RRset at the apex of the child zone and cache this in preference to the NS RRset on the parent side of the zone cut. Resolvers should also periodically revalidate the child delegation by re-quering the parent zone at the expiration of the TTL of the parent side NS RRset. | ||||||||||||||||
| draft-ietf-dnsop-rfc5933-bis-13.txt | |||||||||||||||||
| Use of GOST 2012 Signature Algorithms in DNSKEY and RRSIG Resource Records for DNSSEC | |||||||||||||||||
|
This document describes how to produce digital signatures and hash functions using the GOST R 34.10-2012 and GOST R 34.11-2012 algorithms for DNSKEY, RRSIG, and DS resource records, for use in the Domain Name System Security Extensions (DNSSEC). This document obsoletes RFC 5933 and updates RFC 8624. | ||||||||||||||||
| draft-ietf-dnsop-rfc8499bis-07.txt | |||||||||||||||||
| DNS Terminology | |||||||||||||||||
|
The Domain Name System (DNS) is defined in literally dozens of different RFCs. The terminology used by implementers and developers of DNS protocols, and by operators of DNS systems, has sometimes changed in the decades since the DNS was first defined. This document gives current definitions for many of the terms used in the DNS in a single document. This document obsoletes RFC 8499 and updates RFC 2308. | ||||||||||||||||
| draft-ietf-dnsop-structured-dns-error-01.txt | |||||||||||||||||
| Structured Error Data for Filtered DNS | |||||||||||||||||
|
DNS filtering is widely deployed for network security, but filtered DNS responses lack information for the end user to understand the reason for the filtering. Existing mechanisms to provide detail to end users cause harm especially if the blocked DNS response is to an HTTPS website. This document updates RFC 8914 by structuring the EXTRA-TEXT field of the Extended DNS Error to provide details on the DNS filtering. Such details can be parsed by the client and displayed, logged, or used for other purposes. Other than that, this document does not change any thing written in RFC 8914. | ||||||||||||||||
| draft-ietf-dnsop-svcb-dane-00.txt | |||||||||||||||||
| Using Service Bindings with DANE | |||||||||||||||||
|
Service Binding records introduce a new form of name indirection in DNS. This document specifies DNS-Based Authentication of Named Entities (DANE) interaction with Service Bindings to secure endpoints including use of ports and transports discovered via Service Parameters. 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/bemasc/svcb-dane. | ||||||||||||||||
| draft-ietf-dnsop-svcb-https-12.txt | |||||||||||||||||
| Service binding and parameter specification via the DNS (DNS SVCB and HTTPS RRs) | |||||||||||||||||
|
This document specifies the "SVCB" and "HTTPS" DNS resource record (RR) types to facilitate the lookup of information needed to make connections to network services, such as for HTTP origins. SVCB records allow a service to be provided from multiple alternative endpoints, each with associated parameters (such as transport protocol configuration), and are extensible to support future uses (such as keys for encrypting the TLS ClientHello). They also enable aliasing of apex domains, which is not possible with CNAME. The HTTPS RR is a variation of SVCB for use with HTTP [HTTP]. By providing more information to the client before it attempts to establish a connection, these records offer potential benefits to both performance and privacy. TO BE REMOVED: This document is being collaborated on in Github at: https://github.com/MikeBishop/dns-alt-svc (https://github.com/MikeBishop/dns-alt-svc). The most recent working version of the document, open issues, etc. should all be available there. The authors (gratefully) accept pull requests. | ||||||||||||||||
| draft-ietf-dnsop-zoneversion-02.txt | |||||||||||||||||
| The "ZONEVERSION" EDNS option for the version token of a RR's zone | |||||||||||||||||
|
The "ZONEVERSION" EDNS option allows a DNS querier to request a DNS authoritative server to add an EDNS option in the answer of such query with a token field representing the version of the zone which contains the answered Resource Record, such as the SOA serial field in zones when this number corresponds to the zone version. This "ZONEVERSION" data allows to debug and diagnose problems by helping to recognize the data source of an answer in an atomic single query, by associating the response with a respective zone version. | ||||||||||||||||
| draft-ietf-dnssd-advertising-proxy-02.txt | |||||||||||||||||
| Advertising Proxy for DNS-SD Service Registration Protocol | |||||||||||||||||
|
An Advertising Proxy advertises the contents of a DNS zone, for example maintained using the DNSSD Service Registration Protocol (SRP), using multicast DNS. This allows legacy clients to discover services registered with SRP using multicast DNS. | ||||||||||||||||
| draft-ietf-dnssd-srp-19.txt | |||||||||||||||||
| Service Registration Protocol for DNS-Based Service Discovery | |||||||||||||||||
|
The Service Registration Protocol for DNS-Based Service Discovery uses the standard DNS Update mechanism to enable DNS-Based Service Discovery using only unicast packets. This makes it possible to deploy DNS Service Discovery without multicast, which greatly improves scalability and improves performance on networks where multicast service is not an optimal choice, particularly 802.11 (Wi-Fi) and 802.15.4 (IoT) networks. DNS-SD Service registration uses public keys and SIG(0) to allow services to defend their registrations against attack. | ||||||||||||||||
| draft-ietf-dnssd-srp-replication-00.txt | |||||||||||||||||
| Automatic Replication of DNS-SD Service Registration Protocol Zones | |||||||||||||||||
|
This document describes a protocol that can be used for ad-hoc replication of a DNS zone by multiple servers where a single primary DNS authoritative server is not available and the use of stable storage is not desirable. | ||||||||||||||||
| draft-ietf-dnssd-update-lease-06.txt | |||||||||||||||||
| An EDNS(0) option to negotiate Leases on DNS Updates | |||||||||||||||||
|
This document describes an EDNS(0) option that can be used by DNS Update requestors and DNS servers to include a lease lifetime in a DNS Update or response, allowing a server to garbage collect stale resource records that have been added by DNS Updates | ||||||||||||||||
| draft-ietf-dots-telemetry-use-cases-16.txt | |||||||||||||||||
| Use Cases for DDoS Open Threat Signaling (DOTS) Telemetry | |||||||||||||||||
|
DDoS Open Threat Signaling (DOTS) Telemetry enriches the base DOTS protocols to assist the mitigator in using efficient DDoS attack mitigation techniques in a network. This document presents sample use cases for DOTS Telemetry. It discusses what components are deployed in the network, how they cooperate, and what information is exchanged to effectively use these techniques. | ||||||||||||||||
| draft-ietf-dprive-unilateral-probing-05.txt | |||||||||||||||||
| Unilateral Opportunistic Deployment of Encrypted Recursive-to-Authoritative DNS | |||||||||||||||||
|
This document sets out steps that DNS servers (recursive resolvers and authoritative servers) can take unilaterally (without any coordination with other peers) to defend DNS query privacy against a passive network monitor. The steps in this document can be defeated by an active attacker, but should be simpler and less risky to deploy than more powerful defenses. The goal of this document is to simplify and speed deployment of opportunistic encrypted transport in the recursive-to-authoritative hop of the DNS ecosystem. With wider easy deployment of the underlying transport on an opportunistic basis, we hope to facilitate the future specification of stronger cryptographic protections against more powerful attacks. | ||||||||||||||||
| draft-ietf-drip-arch-31.txt | |||||||||||||||||
| Drone Remote Identification Protocol (DRIP) Architecture | |||||||||||||||||
|
This document describes an architecture for protocols and services to support Unmanned Aircraft System (UAS) Remote Identification (RID) and tracking, plus UAS RID-related communications. This architecture adheres to the requirements listed in the DRIP Requirements document (RFC 9153). | ||||||||||||||||
| draft-ietf-drip-auth-30.txt | |||||||||||||||||
| DRIP Entity Tag Authentication Formats & Protocols for Broadcast Remote ID | |||||||||||||||||
|
This document describes how to add trust into the Broadcast Remote ID (RID) specification discussed in the DRIP Architecture; first trust in the RID ownership and second in the source of the RID messages. The document defines message types and associated formats (sent within the Authentication Message) that can be used to authenticate past messages sent by an unmanned aircraft (UA) and provide proof of UA trustworthiness even in the absence of Internet connectivity at the receiving node. | ||||||||||||||||
| draft-ietf-drip-registries-09.txt | |||||||||||||||||
| DRIP Entity Tag (DET) Identity Management Architecture | |||||||||||||||||
|
This document describes the high level architecture for the registration and discovery of DRIP Entity Tags (DETs) using DNS. Discovery of DETs and their artifacts are through the existing DNS structure and methods. A general overview of the interfaces required between involved components is described in this document with future supporting documents giving technical specifications. | ||||||||||||||||
| draft-ietf-dtn-bpsec-cose-00.txt | |||||||||||||||||
| DTN Bundle Protocol Security (BPSec) COSE Context | |||||||||||||||||
|
This document defines a security context suitable for using CBOR Object Signing and Encryption (COSE) algorithms within Bundle Protocol Security (BPSec) integrity and confidentiality blocks. A profile for COSE, focused on asymmetric-keyed algorithms, and for PKIX certificates are also defined for BPSec interoperation. | ||||||||||||||||
| draft-ietf-dtn-bpv7-admin-iana-01.txt | |||||||||||||||||
| Bundle Protocol Version 7 Administrative Record Types Registry | |||||||||||||||||
|
This document clarifies that a Bundle Protocol Version 7 agent is intended to use an IANA sub-registry for Administrative Record types. It also makes a code point reservation for private or experimental use. | ||||||||||||||||
| draft-ietf-dtn-dtnma-05.txt | |||||||||||||||||
| DTN Management Architecture | |||||||||||||||||
|
The Delay-Tolerant Networking (DTN) architecture describes a type of challenged network in which communications may be significantly affected by long signal propagation delays, frequent link disruptions, or both. The unique characteristics of this environment require a unique approach to network management that supports asynchronous transport, autonomous local control, and a small footprint (in both resources and dependencies) so as to deploy on constrained devices. This document describes a DTN management architecture (DTNMA) suitable for managing devices in any challenged environment but, in particular, those communicating using the DTN Bundle Protocol (BP). Operating over BP requires an architecture that neither presumes synchronized transport behavior nor relies on query-response mechanisms. Implementations compliant with this DTNMA should expect to successfully operate in extremely challenging conditions, such as over uni-directional links and other places where BP is the preferred transport. | ||||||||||||||||
| draft-ietf-dtn-ipn-update-02.txt | |||||||||||||||||
| Update to the ipn URI scheme | |||||||||||||||||
|
This document updates both the specification of the ipn URI scheme previously defined in [RFC7116] and the rules for encoding of these URIs when used as an Endpoint Identifier (EID) in Bundle Protocol Version 7 (BPv7) as defined in [RFC9171]. These updates update and clarify the structure and behavior of the ipn URI scheme, define encodings of ipn scheme URIs, and establish the registries necessary to manage this scheme. | ||||||||||||||||
| draft-ietf-ecrit-lost-planned-changes-06.txt | |||||||||||||||||
| Validation of Locations Around a Planned Change | |||||||||||||||||
|
This document defines an extension to the Location to Service Translation (LoST) protocol (RFC5222) that allows a LoSR server ti notify a client of planned changes to the data. This extension is only useful with the validation function of LoST. It is beneficial for LoST validation clients to be aware of planned changes, as records that previously were valid may become invalid at a known future date, and new locations may become valid after the date. This extension adds an element to the | ||||||||||||||||
| draft-ietf-ecrit-similar-location-19.txt | |||||||||||||||||
| A LoST extension to return complete and similar location info | |||||||||||||||||
|
This document describes an extension to the LoST protocol of RFC 5222 that allows additional civic location information to be returned in a | ||||||||||||||||
| draft-ietf-elegy-rfc8989bis-05.txt | |||||||||||||||||
| Nominating Committee Eligibility | |||||||||||||||||
|
The IETF Nominating Committee (NomCom) appoints candidates to several IETF leadership committees. RFC8713 provides criteria for NomCom membership that attempt to ensure that NomCom volunteers are members of the loosely defined IETF community, by requiring in-person attendance in three of the past five in- person meetings. In 2020 and 2021, the IETF had six consecutive fully online plenary meetings that drove rapid advancement in remote meeting technologies and procedures, including an experiment that included remote attendance for NomCom eligibility. This document updates RFC8713 by defining a new set of eligibility criteria from first principles, with consideration to the increased salience of remote attendance. | ||||||||||||||||
| draft-ietf-emailcore-as-08.txt | |||||||||||||||||
| Applicability Statement for IETF Core Email Protocols | |||||||||||||||||
|
Electronic mail is one of the oldest Internet applications that is still in very active use. While the basic protocols and formats for mail transport and message formats have evolved slowly over the years, events and thinking in more recent years have supplemented those core protocols with additional features and suggestions for their use. This Applicability Statement describes the relationship among many of those protocols and provides guidance and makes recommendations for the use of features of the core protocols. | ||||||||||||||||
| draft-ietf-emailcore-rfc5321bis-18.txt | |||||||||||||||||
| Simple Mail Transfer Protocol | |||||||||||||||||
|
This document is a specification of the basic protocol for Internet electronic mail transport. It (including text carried forward from RFC 5321) consolidates, updates, and clarifies several previous documents, making all or parts of most of them obsolete. It covers the SMTP extension mechanisms and best practices for the contemporary Internet, but does not provide details about particular extensions. The document also provides information about use of SMTP for other than strict mail transport and delivery. This document replaces RFC 5321, the earlier version with the same title. | ||||||||||||||||
| draft-ietf-emailcore-rfc5322bis-05.txt | |||||||||||||||||
| Internet Message Format | |||||||||||||||||
|
This document specifies the Internet Message Format (IMF), a syntax for text messages that are sent between computer users, within the framework of "electronic mail" messages. This specification is a revision of Request For Comments (RFC) 5322, itself a revision of Request For Comments (RFC) 2822, all of which supersede Request For Comments (RFC) 822, "Standard for the Format of ARPA Internet Text Messages", updating it to reflect current practice and incorporating incremental changes that were specified in other RFCs. | ||||||||||||||||
| draft-ietf-emu-aka-pfs-10.txt | |||||||||||||||||
| Forward Secrecy for the Extensible Authentication Protocol Method for Authentication and Key Agreement (EAP-AKA' FS) | |||||||||||||||||
|
Many different attacks have been reported as part of revelations associated with pervasive surveillance. Some of the reported attacks involved compromising the smart card supply chain, such as attacking SIM card manufacturers and operators in an effort to compromise shared secrets stored on these cards. Since the publication of those reports, manufacturing and provisioning processes have gained much scrutiny and have improved. However, the danger of resourceful attackers for these systems is still a concern. Always assuming breach such as key compromise and minimizing the impact of breach are essential zero-trust principles. This specification updates RFC 9048, the improved Extensible Authentication Protocol Method for 3GPP Mobile Network Authentication and Key Agreement (EAP-AKA'), with an optional extension. Similarly, this specification also updates the earlier version of the EAP-AKA' specification in RFC 5448. The extension, when negotiated, provides Forward Secrecy for the session key generated as a part of the authentication run in EAP-AKA'. This prevents an attacker who has gained access to the long-term pre-shared secret in a Subscriber Identity Module (SIM) card from being able to decrypt any past communications. In addition, if the attacker stays merely a passive eavesdropper, the extension prevents attacks against future sessions. This forces attackers to use active attacks instead. | ||||||||||||||||
| draft-ietf-emu-bootstrapped-tls-02.txt | |||||||||||||||||
| Bootstrapped TLS Authentication with Proof of Knowledge (TLS-POK) | |||||||||||||||||
|
This document defines a mechanism that enables a bootstrapping device to establish trust and mutually authenticate against a network. Bootstrapping devices have a public private key pair, and this mechanism enables a network server to prove to the device that it knows the public key, and the device to prove to the server that it knows the private key. The mechanism leverages existing DPP and TLS standards and can be used in an EAP exchange. | ||||||||||||||||
| draft-ietf-emu-rfc7170bis-05.txt | |||||||||||||||||
| Tunnel Extensible Authentication Protocol (TEAP) Version 1 | |||||||||||||||||
|
This document defines the Tunnel Extensible Authentication Protocol (TEAP) version 1. TEAP is a tunnel-based EAP method that enables secure communication between a peer and a server by using the Transport Layer Security (TLS) protocol to establish a mutually authenticated tunnel. Within the tunnel, TLV objects are used to convey authentication-related data between the EAP peer and the EAP server. This document obsoletes RFC 7170. | ||||||||||||||||
| draft-ietf-emu-tls-eap-types-13.txt | |||||||||||||||||
| TLS-based EAP types and TLS 1.3 | |||||||||||||||||
|
EAP-TLS (RFC 5216) has been updated for TLS 1.3 in RFC 9190. Many other EAP types also depend on TLS, such as EAP-FAST (RFC 4851), EAP- TTLS (RFC 5281), TEAP (RFC 7170), and possibly many vendor specific EAP methods. This document updates those methods in order to use the new key derivation methods available in TLS 1.3. Additional changes necessitated by TLS 1.3 are also discussed. | ||||||||||||||||
| draft-ietf-extra-imap-messagelimit-02.txt | |||||||||||||||||
| IMAP MESSAGELIMIT Extension | |||||||||||||||||
|
The MESSAGELIMIT extension of the Internet Message Access Protocol (RFC 3501/RFC 9051) allows servers to announce a limit on the number of messages that can be processed in a single FETCH/SEARCH/STORE/COPY/MOVE command. This helps servers to control resource usage when performing various IMAP operations. | ||||||||||||||||
| draft-ietf-extra-imap-partial-04.txt | |||||||||||||||||
| IMAP Paged SEARCH & FETCH Extension | |||||||||||||||||
|
The PARTIAL extension of the Internet Message Access Protocol (RFC 3501/RFC 9051) allows clients to limit the number of search results returned, as well as to perform incremental (paged) searches. This also helps servers to optimize resource usage when performing searches. This document extends PARTIAL SEARCH return option originally specified in RFC 5267. It also clarifies some interactions between RFC 5267 and RFC 4731/RFC 9051. | ||||||||||||||||
| draft-ietf-extra-imap-uidonly-01.txt | |||||||||||||||||
| IMAP Extension for only using and returning UIDs | |||||||||||||||||
|
The UIDONLY extension to the Internet Message Access Protocol (RFC 3501/RFC 9051) allows clients to enable a mode in which information about mailbox changes is returned using only UIDs. Message numbers are not returned in responses, and can't be used in requests once this extension is enabled. This helps both clients and servers to reduce resource usage required for maintenance of message number to UID map. | ||||||||||||||||
| draft-ietf-extra-jmapaccess-03.txt | |||||||||||||||||
| The JMAPACCESS Extension for IMAP | |||||||||||||||||
|
This document defines an IMAP extension to let clients know that the messages in this IMAP server are also available via JMAP, and how. It is intended for clients that want to migrate gradually to JMAP. | ||||||||||||||||
| draft-ietf-extra-processimip-01.txt | |||||||||||||||||
| Sieve Email Filtering: Extension for Processing iMIP Messages | |||||||||||||||||
|
This document describes the "processimip" extension to the Sieve email filtering language. The "processimip" extension gives Sieve the ability to process messages using the iCalendar Message-Based Interoperability Protocol (iMIP). Open Issues | ||||||||||||||||
| draft-ietf-extra-sieve-action-registry-06.txt | |||||||||||||||||
| IANA registry for Sieve actions | |||||||||||||||||
|
Sieve Email Filtering Language (RFC 5228) is a popular email filtering language used upon final mail delivery. This document creates a registry of Sieve (RFC 5228) actions in order to help developers and Sieve extension writers track interactions between different extensions. | ||||||||||||||||
| draft-ietf-extra-sieve-snooze-07.txt | |||||||||||||||||
| Sieve Email Filtering: Snooze Extension | |||||||||||||||||
|
This document describes the "snooze" extension to the Sieve email filtering language. The "snooze" extension gives Sieve the ability to postpone the delivery of an incoming email message into a target mailbox until a later point in time. | ||||||||||||||||
| draft-ietf-gnap-core-protocol-13.txt | |||||||||||||||||
| Grant Negotiation and Authorization Protocol | |||||||||||||||||
|
GNAP defines a mechanism for delegating authorization to a piece of software, and conveying the results and artifacts of that delegation to the software. This delegation can include access to a set of APIs as well as subject information passed directly to the software. | ||||||||||||||||
| draft-ietf-gnap-resource-servers-03.txt | |||||||||||||||||
| Grant Negotiation and Authorization Protocol Resource Server Connections | |||||||||||||||||
|
GNAP defines a mechanism for delegating authorization to a piece of software, and conveying that delegation to the software. This extension defines methods for resource servers (RS) to communicate with authorization servers (AS) in an interoperable fashion. | ||||||||||||||||
| draft-ietf-grow-anycast-community-00.txt | |||||||||||||||||
| A well-known BGP community to denote prefixes used for Anycast | |||||||||||||||||
|
In theory routing decisions on the Internet and by extension within ISP networks should always use hot-potato routing to reach any given destination. In reality operators sometimes choose to not use the hot-potato paths to forward traffic due to a variety of reasons, mostly motivated by traffic engineering considerations. For prefixes carrying anycast traffic in virtually all situations it is advisable to stick to the hot-potato principle. As operators mostly don't know which prefixes are carrying unicast or anycast traffic, they can't differentiate between them in their routing policies. To allow operators to take well informed decisions on which prefixes are carrying anycast traffic this document proposes a well-known BGP community to denote this property. | ||||||||||||||||
| draft-ietf-grow-as-path-prepending-07.txt | |||||||||||||||||
| AS Path Prepending | |||||||||||||||||
|
AS Path Prepending provides a tool to manipulate the BGP AS_Path attribute through prepending multiple entries of an AS. AS Path Prepending is used to deprioritize a route or alternate path. By prepending the local ASN multiple times, ASs can make advertised AS paths appear artificially longer. Excessive AS Path Prepending has caused routing issues in the Internet. This document provides guidance with the use of AS Path Prepending, including alternative solutions, in order to avoid negatively affecting the Internet. | ||||||||||||||||
| draft-ietf-grow-bmp-tlv-12.txt | |||||||||||||||||
| TLV support for BMP Route Monitoring and Peer Down Messages | |||||||||||||||||
|
Most of the message types defined by the BGP Monitoring Protocol (BMP) make provision for data in TLV format. However, Route Monitoring messages (which provide a snapshot of the monitored Routing Information Base) and Peer Down messages (which indicate that a peering session was terminated) do not. Supporting (optional) data in TLV format across all BMP message types allows for a homogeneous and extensible surface that would be useful for the most different use-cases that need to convey additional data to a BMP station. While it is not intended for this document to cover any specific utilization scenario, it defines a simple way to support TLV data in all message types. | ||||||||||||||||
| draft-ietf-grow-bmp-tlv-ebit-02.txt | |||||||||||||||||
| Support for Enterprise-specific TLVs in the BGP Monitoring Protocol | |||||||||||||||||
|
Message types defined by the BGP Monitoring Protocol (BMP) do provision for data in TLV - Type, Length, Value - format, either in the shape of a TLV message body, ie. Route Mirroring and Stats Reports, or optional TLVs at the end of a BMP message, ie. Peer Up and Peer Down. However the space for Type value is unique and governed by IANA. To allow the usage of vendor-specific TLVs, a mechanism to define per-vendor Type values is required. In this document we introduce an Enterprise Bit, or E-bit, for such purpose. | ||||||||||||||||
| draft-ietf-grow-bmp-yang-01.txt | |||||||||||||||||
| BMP YANG Module | |||||||||||||||||
|
This document proposes a YANG module for BMP (BGP Monitoring Protocol) configuration and monitoring. A complementary RPC triggers a refresh of the session of a BMP monitoring station. | ||||||||||||||||
| draft-ietf-grow-nrtm-v4-01.txt | |||||||||||||||||
| Near Real Time Mirroring (NRTM) version 4 | |||||||||||||||||
|
This document specifies a one-way synchronization protocol for Internet Routing Registry (IRR) records. The protocol allows instances of IRR database servers to mirror IRR records, specified in the Routing Policy Specification Language (RPSL), between each other. | ||||||||||||||||
| draft-ietf-grow-route-leak-detection-mitigation-08.txt | |||||||||||||||||
| Methods for Detection and Mitigation of BGP Route Leaks | |||||||||||||||||
|
Problem definition for route leaks and enumeration of types of route leaks are provided in RFC 7908. This document describes a new well- known Large Community that provides a way for route-leak prevention, detection, and mitigation. The configuration process for this Community can be automated with the methodology for setting BGP roles that is described in RFC 9234. | ||||||||||||||||
| draft-ietf-homenet-front-end-naming-delegation-27.txt | |||||||||||||||||
| Simple Provisioning of Public Names for Residential Networks | |||||||||||||||||
|
Home network owners may have devices or services hosted on their home network that they wish to access from the Internet (i.e., from a network outside of the home network). Home networks are increasingly numbered using IPv6 addresses, which in principle makes this access simpler, but their access from the Internet requires the names and IP addresses of these devices and services to be made available in the public DNS. This document describes how an Home Naming Authority (NHA) instructs the outsourced infrastructure to publish these pieces of information in the public DNS. The names and IP addresses of the home network are set in the Public Homenet Zone by the Homenet Naming Authority (HNA), which in turn instructs an outsourced infrastructure to publish the zone on behalf of the home network owner. | ||||||||||||||||
| draft-ietf-homenet-naming-architecture-dhc-options-24.txt | |||||||||||||||||
| DHCPv6 Options for Home Network Naming Authority | |||||||||||||||||
|
This document defines DHCPv6 options so a Homenet Naming Authority (HNA) can automatically proceed to the appropriate configuration and outsource the authoritative naming service for the home network. In most cases, the outsourcing mechanism is transparent for the end user. | ||||||||||||||||
| draft-ietf-httpapi-idempotency-key-header-02.txt | |||||||||||||||||
| The Idempotency-Key HTTP Header Field | |||||||||||||||||
|
The HTTP Idempotency-Key request header field can be used to carry idempotency key in order to make non-idempotent HTTP methods such as "POST" or "PATCH" fault-tolerant. Discussion Venues This note is to be removed before publishing as an RFC. Discussion of this document takes place on the Building Blocks for HTTP APIs Working Group mailing list (httpapi@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/httpapi/. Source for this draft and an issue tracker can be found at https://github.com/mnot/idempotency. | ||||||||||||||||
| draft-ietf-httpapi-link-template-02.txt | |||||||||||||||||
| The Link-Template HTTP Header Field | |||||||||||||||||
|
This specification defines the Link-Template HTTP header field, providing a means for describing the structure of a link between two resources, so that new links can be generated. | ||||||||||||||||
| draft-ietf-httpapi-ratelimit-headers-06.txt | |||||||||||||||||
| RateLimit header fields for HTTP | |||||||||||||||||
|
This document defines the RateLimit-Limit, RateLimit-Remaining, RateLimit-Reset and RateLimit-Policy HTTP header fields for servers to advertise their current service rate limits, thereby allowing clients to avoid being throttled. | ||||||||||||||||
| draft-ietf-httpapi-rest-api-mediatypes-03.txt | |||||||||||||||||
| REST API Media Types | |||||||||||||||||
|
This document registers the following media types used in APIs on the IANA Media Types registry: application/schema+json, application/ schema-instance+json, application/openapi+json, and application/ openapi+yaml. | ||||||||||||||||
| draft-ietf-httpapi-rfc7807bis-06.txt | |||||||||||||||||
| Problem Details for HTTP APIs | |||||||||||||||||
|
This document defines a "problem detail" to carry machine-readable details of errors in HTTP response content to avoid the need to define new error response formats for HTTP APIs. This document obsoletes RFC 7807. Discussion Venues This note is to be removed before publishing as an RFC. Source for this draft and an issue tracker can be found at https://github.com/ietf-wg-httpapi/rfc7807bis. | ||||||||||||||||
| draft-ietf-httpapi-yaml-mediatypes-04.txt | |||||||||||||||||
| YAML Media Type | |||||||||||||||||
|
This document registers the application/yaml media type and the +yaml structured syntax suffix on the IANA Media Types registry. | ||||||||||||||||
| draft-ietf-httpbis-alias-proxy-status-01.txt | |||||||||||||||||
| HTTP Proxy-Status Parameter for Next-Hop Aliases | |||||||||||||||||
|
This document defines an HTTP Proxy-Status Parameter that contains a list of aliases and canonical names received over DNS when establishing a connection to the next hop. | ||||||||||||||||
| draft-ietf-httpbis-client-cert-field-06.txt | |||||||||||||||||
| Client-Cert HTTP Header Field | |||||||||||||||||
|
This document describes HTTP extension header fields that allow a TLS terminating reverse proxy to convey the client certificate information of a mutually authenticated TLS connection to the origin server in a common and predictable manner. | ||||||||||||||||
| draft-ietf-httpbis-digest-headers-12.txt | |||||||||||||||||
| Digest Fields | |||||||||||||||||
|
This document defines HTTP fields that support integrity digests. The Content-Digest field can be used for the integrity of HTTP message content. The Repr-Digest field can be used for the integrity of HTTP representations. Want-Content-Digest and Want-Repr-Digest can be used to indicate a sender's interest and preferences for receiving the respective Integrity fields. This document obsoletes RFC 3230 and the Digest and Want-Digest HTTP fields. | ||||||||||||||||
| draft-ietf-httpbis-message-signatures-16.txt | |||||||||||||||||
| HTTP Message Signatures | |||||||||||||||||
|
This document describes a mechanism for creating, encoding, and verifying digital signatures or message authentication codes over components of an HTTP message. This mechanism supports use cases where the full HTTP message may not be known to the signer, and where the message may be transformed (e.g., by intermediaries) before reaching the verifier. This document also describes a means for requesting that a signature be applied to a subsequent HTTP message in an ongoing HTTP exchange. | ||||||||||||||||
| draft-ietf-httpbis-origin-h3-03.txt | |||||||||||||||||
| The ORIGIN Extension in HTTP/3 | |||||||||||||||||
|
The ORIGIN frame for HTTP/2 is equally applicable to HTTP/3, but needs to be separately registered. This document describes the ORIGIN frame for HTTP/3. | ||||||||||||||||
| draft-ietf-httpbis-resumable-upload-01.txt | |||||||||||||||||
| Resumable Uploads for HTTP | |||||||||||||||||
|
HTTP clients often encounter interrupted data transfers as a result of canceled requests or dropped connections. Prior to interruption, part of a representation may have been exchanged. To complete the data transfer of the entire representation, it is often desirable to issue subsequent requests that transfer only the remainder of the representation. HTTP range requests support this concept of resumable downloads from server to client. This document describes a mechanism that supports resumable uploads from client to server using HTTP. | ||||||||||||||||
| draft-ietf-httpbis-retrofit-06.txt | |||||||||||||||||
| Retrofit Structured Fields for HTTP | |||||||||||||||||
|
This specification nominates a selection of existing HTTP fields as having syntax that is compatible with Structured Fields, so that they can be handled as such (subject to certain caveats). To accommodate some additional fields whose syntax is not compatible, it also defines mappings of their semantics into new Structured Fields. It does not specify how to negotiate their use. | ||||||||||||||||
| draft-ietf-httpbis-rfc6265bis-11.txt | |||||||||||||||||
| Cookies: HTTP State Management Mechanism | |||||||||||||||||
|
This document defines the HTTP Cookie and Set-Cookie header fields. These header fields can be used by HTTP servers to store state (called cookies) at HTTP user agents, letting the servers maintain a stateful session over the mostly stateless HTTP protocol. Although cookies have many historical infelicities that degrade their security and privacy, the Cookie and Set-Cookie header fields are widely used on the Internet. This document obsoletes RFC 6265. | ||||||||||||||||
| draft-ietf-httpbis-sfbis-02.txt | |||||||||||||||||
| Structured Field Values for HTTP | |||||||||||||||||
|
This document describes a set of data types and associated algorithms that are intended to make it easier and safer to define and handle HTTP header and trailer fields, known as "Structured Fields", "Structured Headers", or "Structured Trailers". It is intended for use by specifications of new HTTP fields that wish to use a common syntax that is more restrictive than traditional HTTP field values. This document obsoletes RFC 8941. | ||||||||||||||||
| draft-ietf-httpbis-unprompted-auth-02.txt | |||||||||||||||||
| HTTP Unprompted Authentication | |||||||||||||||||
|
Existing HTTP authentication mechanisms are probeable in the sense that it is possible for an unauthenticated client to probe whether an origin serves resources that require authentication. It is possible for an origin to hide the fact that it requires authentication by not generating Unauthorized status codes, however that only works with non-cryptographic authentication schemes: cryptographic schemes (such as signatures or message authentication codes) require a fresh nonce to be signed, and there is no existing way for the origin to share such a nonce without exposing the fact that it serves resources that require authentication. This document proposes a new non-probeable cryptographic authentication scheme. | ||||||||||||||||
| draft-ietf-i2nsf-applicability-18.txt | |||||||||||||||||
| Applicability of Interfaces to Network Security Functions to Network-Based Security Services | |||||||||||||||||
|
This document describes the applicability of Interface to Network Security Functions (I2NSF) to network-based security services in Network Functions Virtualization (NFV) environments, such as firewall, deep packet inspection, or attack mitigation engines. | ||||||||||||||||
| draft-ietf-i2nsf-capability-data-model-32.txt | |||||||||||||||||
| I2NSF Capability YANG Data Model | |||||||||||||||||
|
This document defines an information model and the corresponding YANG data model for the capabilities of various Network Security Functions (NSFs) in the Interface to Network Security Functions (I2NSF) framework to centrally manage the capabilities of the various NSFs. | ||||||||||||||||
| draft-ietf-i2nsf-consumer-facing-interface-dm-30.txt | |||||||||||||||||
| I2NSF Consumer-Facing Interface YANG Data Model | |||||||||||||||||
|
This document describes a YANG data model of the Consumer-Facing Interface of the Security Controller in an Interface to Network Security Functions (I2NSF) system in a Network Functions Virtualization (NFV) environment. This document defines various types of managed objects and the relationship among them needed to build the flow policies from users' perspective. The YANG data model is based on the "Event-Condition-Action" (ECA) policy defined by a capability YANG data model for I2NSF. The YANG data model enables different users of a given I2NSF system to define, manage, and monitor flow policies within an administrative domain (e.g., user group). | ||||||||||||||||
| draft-ietf-i2nsf-nsf-facing-interface-dm-29.txt | |||||||||||||||||
| I2NSF Network Security Function-Facing Interface YANG Data Model | |||||||||||||||||
|
This document defines a YANG data model for configuring security policy rules on Network Security Functions (NSF) in the Interface to Network Security Functions (I2NSF) framework. The YANG data model in this document is for the NSF-Facing Interface between a Security Controller and NSFs in the I2NSF framework. It is built on the basis of the YANG data model in the I2NSF Capability YANG Data Model document for the I2NSF framework. | ||||||||||||||||
| draft-ietf-i2nsf-nsf-monitoring-data-model-20.txt | |||||||||||||||||
| I2NSF NSF Monitoring Interface YANG Data Model | |||||||||||||||||
|
This document proposes an information model and the corresponding YANG data model of an interface for monitoring Network Security Functions (NSFs) in the Interface to Network Security Functions (I2NSF) framework. If the monitoring of NSFs is performed with the NSF monitoring interface in a standard way, it is possible to detect the indication of malicious activity, anomalous behavior, the potential sign of denial-of-service attacks, or system overload in a timely manner. This monitoring functionality is based on the monitoring information that is generated by NSFs. Thus, this document describes not only an information model for the NSF monitoring interface along with a YANG tree diagram, but also the corresponding YANG data model. | ||||||||||||||||
| draft-ietf-i2nsf-registration-interface-dm-25.txt | |||||||||||||||||
| I2NSF Registration Interface YANG Data Model for NSF Capability Registration | |||||||||||||||||
|
This document defines a YANG data model for the Registration Interface between Security Controller and Developer's Management System (DMS) in the Interface to Network Security Functions (I2NSF) framework to register Network Security Functions (NSF) of the DMS with the Security Controller. The objective of this data model is to support NSF capability registration and query via I2NSF Registration Interface. | ||||||||||||||||
| draft-ietf-idr-5g-edge-service-metadata-01.txt | |||||||||||||||||
| BGP Extension for 5G Edge Service Metadata | |||||||||||||||||
|
This draft describes three new sub-TLVs for egress routers to advertise the Edge Service Metadata of the directly attached edge services (ES). The Edge Service Metadata can be used by the ingress routers in the 5G Local Data Network to make path selections not only based on the routing cost but also the running environment of the edge services. The goal is to improve latency and performance for 5G edge services. The extension enables an edge service at one specific location to be more preferred than the others with the same IP address (ANYCAST) to receive data flow from a specific source, like specific User Equipment (UE). | ||||||||||||||||
| draft-ietf-idr-bgp-bfd-strict-mode-10.txt | |||||||||||||||||
| BGP BFD Strict-Mode | |||||||||||||||||
|
This document specifies extensions to RFC4271 BGP-4 that enable a BGP speaker to negotiate additional Bidirectional Forwarding Detection (BFD) extensions using a BGP capability. This BFD Strict-Mode Capability enables a BGP speaker to prevent a BGP session from being established until a BFD session is established. It is referred to as BGP BFD "strict-mode". BGP BFD strict-mode will be supported when both the local speaker and its remote peer are BFD strict-mode capable. | ||||||||||||||||
| draft-ietf-idr-bgp-car-01.txt | |||||||||||||||||
| BGP Color-Aware Routing (CAR) | |||||||||||||||||
|
This document describes a BGP based routing solution to establish end-to-end intent-aware paths across a multi-domain service provider transport network. This solution is called BGP Color-Aware Routing (BGP CAR). | ||||||||||||||||
| draft-ietf-idr-bgp-ct-03.txt | |||||||||||||||||
| BGP Classful Transport Planes | |||||||||||||||||
|
This document specifies a mechanism, referred to as "Intent Driven Service Mapping" to express association of overlay routes with underlay routes satisfying a certain SLA using BGP. The document describes a framework for classifying underlay routes into transport classes and mapping service routes to specific transport class. The "Transport class" construct maps to a desired SLA and can be used to realize the "Topology Slice" in 5G Network slicing architecture. This document specifies BGP protocol procedures that enable dissemination of such service mapping information that may span multiple cooperating administrative domains. These domains may be administetered by the same provider or by closely co-ordinating provider networks. A new BGP transport layer address family (SAFI 76) is defined for this purpose that uses RFC-4364 technology and follows RFC-8277 NLRI encoding. This new address family is called "BGP Classful Transport", aka BGP CT. BGP CT makes it possible to advertise multiple tunnels to the same destination address, thus avoiding need of multiple loopbacks on the egress node. It carries transport prefixes across tunnel domain boundaries (e.g. in Inter-AS Option-C networks), which is parallel to BGP LU (SAFI 4) . It disseminates "Transport class" information for the transport prefixes across the participating domains, which is not possible with BGP LU. This makes the end-to-end network a "Transport Class" aware tunneled network. Just like BGP LU (SAFI 4), BGP CT family (SAFI 76) is used in inter- AS option-C networks. The Service Mapping procedures described in this document apply in the same manner to Intra-AS service end points as well as Inter-AS option-A, option-B, option-C variations. Examples of these variations are given in Appendix A. | ||||||||||||||||
| draft-ietf-idr-bgp-flowspec-label-02.txt | |||||||||||||||||
| Carrying Label Information for BGP FlowSpec | |||||||||||||||||
|
This document specifies a method in which the label mapping information for a particular FlowSpec rule is piggybacked in the same Border Gateway Protocol (BGP) Update message that is used to distribute the FlowSpec rule. Based on the proposed method, the Label Switching Routers (LSRs) (except the ingress LSR) on the Label Switched Path (LSP) can use label to indentify the traffic matching a particular FlowSpec rule; this facilitates monitoring and traffic statistics for FlowSpec rules. | ||||||||||||||||
| draft-ietf-idr-bgp-ifit-capabilities-02.txt | |||||||||||||||||
| Advertising In-situ Flow Information Telemetry (IFIT) Capabilities in BGP | |||||||||||||||||
|
In-situ Flow Information Telemetry (IFIT) refers to network OAM data plane on-path telemetry techniques, in particular In-situ OAM (IOAM) and Alternate Marking. This document defines a new BGP Router Capability Code to advertise the In-situ Flow Information Telemetry (IFIT) capabilities. Within an IFIT domain, IFIT-capability advertisement from the tail node to the head node assists the head node to determine whether a particular IFIT Option type can be encapsulated in data packets. Such advertisement helps mitigating the leakage threat and facilitating the deployment of IFIT measurements on a per-service and on-demand basis. | ||||||||||||||||
| draft-ietf-idr-bgp-ls-isis-flood-reflection-02.txt | |||||||||||||||||
| BGP-LS Extensions for IS-IS Flood Reflection | |||||||||||||||||
|
IS-IS Flood Reflection is a mechanism that allows flat, single-area IS-IS topologies to scale beyond their traditional limitations. This document defines new BGP-LS (BGP Link-State) TLVs in order to carry IS-IS Flood Reflection information. | ||||||||||||||||
| draft-ietf-idr-bgp-ls-link-mtu-04.txt | |||||||||||||||||
| Signaling Maximum Transmission Unit (MTU) using BGP-LS | |||||||||||||||||
|
BGP Link State (BGP-LS) describes a mechanism by which link-state and TE information can be collected from networks and shared with external components using the BGP routing protocol. The centralized controller (PCE/SDN) completes the service path calculation based on the information transmitted by the BGP-LS and delivers the result to the Path Computation Client (PCC) through the PCEP or BGP protocol. Segment Routing (SR) leverages the source routing paradigm, which can be directly applied to the MPLS architecture with no change on the forwarding plane and applied to the IPv6 architecture, with a new type of routing header, called SRH. The SR uses the IGP protocol as the control protocol. Compared to the MPLS tunneling technology, the SR does not require additional signaling. Therefore, the SR does not support the negotiation of the Path MTU. Since multiple labels or SRv6 SIDs are pushed in the packets, it is more likely that the packet size exceeds the path mtu of SR tunnel. This document specifies the extensions to BGP Link State (BGP-LS) to carry maximum transmission unit (MTU) messages of link. The PCE/SDN calculates the Path MTU while completing the service path calculation based on the information transmitted by the BGP-LS. | ||||||||||||||||
| draft-ietf-idr-bgp-ls-sr-policy-00.txt | |||||||||||||||||
| Advertisement of Segment Routing Policies using BGP Link-State | |||||||||||||||||
|
This document describes a mechanism to collect the Segment Routing Policy information that is locally available in a node and advertise it into BGP Link-State (BGP-LS) updates. Such information can be used by external components for path computation, re-optimization, service placement, network visualization, etc. | ||||||||||||||||
| draft-ietf-idr-bgp-ls-sr-policy-path-segment-04.txt | |||||||||||||||||
| SR Policies Extensions for Path Segment and Bidirectional Path in BGP-LS | |||||||||||||||||
|
This document specifies the way of collecting configuration and states of SR policies carrying Path Segment and bidirectional path information by using BPG-LS. Such information can be used by external conponents for many use cases such as performance measurement, path re-optimization and end-to-end protection. | ||||||||||||||||
| draft-ietf-idr-bgp-ls-sr-service-segments-02.txt | |||||||||||||||||
| BGP-LS Advertisement of Segment Routing Service Segments | |||||||||||||||||
|
Service functions are deployed as, physical or virtualized elements along with network nodes or on servers in data centers. Segment Routing (SR) brings in the concept of segments which can be topological or service instructions. Service segments are SR segments that are associated with service functions. SR Policies are used for the setup of paths for steering of traffic through service functions using their service segments. BGP Link-State (BGP-LS) enables distribution of topology information from the network to a controller or an application in general so it can learn the network topology. This document specifies the extensions to BGP-LS for the advertisement of service functions along their associated service segments. The BGP-LS advertisement of service function information along with the network nodes that they are attached to, or associated with, enables controllers compute and setup service paths in the network. | ||||||||||||||||
| draft-ietf-idr-bgp-ls-te-path-00.txt | |||||||||||||||||
| Advertisement of Traffic Engineering Paths using BGP Link-State | |||||||||||||||||
|
This document describes a mechanism to collect the Traffic Engineering Path information that is locally available in a node and advertise it into BGP Link-State (BGP-LS) updates. Such information can be used by external components for path computation, re- optimization, service placement, network visualization, etc. | ||||||||||||||||
| draft-ietf-idr-bgp-model-16.txt | |||||||||||||||||
| YANG Model for Border Gateway Protocol (BGP-4) | |||||||||||||||||
|
This document defines a YANG data model for configuring and managing BGP, including protocol, policy, and operational aspects, such as RIB, based on data center, carrier, and content provider operational requirements. | ||||||||||||||||
| draft-ietf-idr-bgpls-inter-as-topology-ext-13.txt | |||||||||||||||||
| BGP-LS Extension for Inter-AS Topology Retrieval | |||||||||||||||||
|
This document describes the process to build Border Gateway Protocol- Link State (BGP-LS) key parameters in inter-domain scenario, defines one new BGP-LS Network Layer Reachability Information (NLRI) type (Stub Link NLRI) and some new Type-Length-Values (TLVs) for BGP-LS to let Software Definition Network (SDN) controller retrieve the network topology automatically under various inter-AS environments. Such extension and process can enable the network operator to collect the interconnect information between different domains and then calculate the overall network topology automatically based on the information provided by BGP-LS protocol. | ||||||||||||||||
| draft-ietf-idr-bgpls-sr-vtn-mt-02.txt | |||||||||||||||||
| BGP-LS with Multi-topology for Segment Routing based Virtual Transport Networks | |||||||||||||||||
|
Enhanced VPN (VPN+) aims to provide enhanced VPN service to support some applications' needs of enhanced isolation and stringent performance requirements. VPN+ requires integration between the overlay VPN and the underlay network. A Virtual Transport Network (VTN) is a virtual underlay network which consists of a subset of the network topology and network resources allocated from the physical network. A VTN could be used as the underlay for one or a group of VPN+ services. When Segment Routing is used as the data plane of VTNs, each VTN can be allocated with a group of Segment Identifiers (SIDs) to identify the topology and resource attributes of network segments in the VTN. The association between the network topology, the network resource attributes and the SR SIDs may need to be distributed to a centralized network controller. In network scenarios where each VTN can be associated with a unique logical network topology, this document describes a mechanism to distribute the information of SR based VTNs using BGP-LS with Multi-Topology. | ||||||||||||||||
| draft-ietf-idr-bgpls-srv6-ext-14.txt | |||||||||||||||||
| BGP Link State Extensions for SRv6 | |||||||||||||||||
|
Segment Routing over IPv6 (SRv6) allows for a flexible definition of end-to-end paths within various topologies by encoding paths as sequences of topological or functional sub-paths, called "segments". These segments are advertised by various protocols such as BGP, IS-IS and OSPFv3. This document defines extensions to BGP Link-state (BGP-LS) to advertise SRv6 segments along with their behaviors and other attributes via BGP. The BGP-LS address-family solution for SRv6 described in this document is similar to BGP-LS for SR for the MPLS data-plane defined in a separate document. | ||||||||||||||||
| draft-ietf-idr-bier-te-path-01.txt | |||||||||||||||||
| BGP for BIER-TE Path | |||||||||||||||||
|
This document describes extensions to Border Gateway Protocol (BGP) for distributing a Bit Index Explicit Replication Traffic/Tree Engineering (BIER-TE) path. A new Tunnel Type for BIER-TE path is defined to encode the information about a BIER-TE path. | ||||||||||||||||
| draft-ietf-idr-deprecate-as-set-confed-set-10.txt | |||||||||||||||||
| Deprecation of AS_SET and AS_CONFED_SET in BGP | |||||||||||||||||
|
BCP 172 (i.e., RFC 6472) recommends not using AS_SET and AS_CONFED_SET AS_PATH segment types in the Border Gateway Protocol (BGP). This document advances that recommendation to a standards requirement in BGP; it proscribes 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 and RFC 5065, and obsoletes RFC 6472. | ||||||||||||||||
| draft-ietf-idr-entropy-label-03.txt | |||||||||||||||||
| BGP Router Capabilities Attribute | |||||||||||||||||
|
RFC 5492 allows a BGP speaker to advertise its capabilities to its peer. When a route is propagated beyond the immediate peer, it is useful to allow certain capabilities to be conveyed further. In particular, it may be useful to advertise forwarding plane features. This specification defines a new BGP transitive attribute to carry such capability information, the "Router Capabilities Attribute," or RCA. This specification also defines an RCA capability that can be used to advertise the ability to process the MPLS Entropy Label as an egress LSR for all NLRI advertised in the BGP UPDATE. It updates RFC 6790 and RFC 7447 concerning this BGP signaling. | ||||||||||||||||
| draft-ietf-idr-flowspec-mpls-match-02.txt | |||||||||||||||||
| BGP Flow Specification Filter for MPLS Label | |||||||||||||||||
|
This draft proposes BGP flow specification rules that are used to filter MPLS labeled packets. | ||||||||||||||||
| draft-ietf-idr-flowspec-network-slice-ts-00.txt | |||||||||||||||||
| BGP Flowspec for IETF Network Slice Traffic Steering | |||||||||||||||||
|
BGP Flow Specification (Flowspec) provides a mechanism to distribute traffic flow specifications and the forwarding actions to be performed to the specific traffic flows. A set of Flowspec components are defined to specify the matching criteria that can be applied to the packet, and a set of BGP extended communities are defined to encode the actions a routing system can take on a packet which matches the flow specification. An IETF Network Slice enables connectivity between a set of Service Demarcation Points (SDPs) with specific Service Level Objectives (SLOs) and Service Level Expectations (SLEs) over a common underlay network. To meet the connectivity and performance requirements of network slice services, network slice service traffic needs to be mapped to a corresponding Network Resource Partition (NRP). The edge nodes of the NRP needs to identify the traffic flows which belong to a network slice and steer the matched traffic into the corresponding NRP, or a specific path within the corresponding NRP. BGP Flowspec can be used to distribute the matching criteria and the forwarding actions to be preformed on network slice service traffic. The existing Flowspec components can be reused for the matching of network slice services flows at the edge of an NRP. New components and traffic action may need to be defined for steering network slice service flows into the corresponding NRP. This document defines the extensions to BGP Flowspec for IETF network slice traffic steering (NS-TS). | ||||||||||||||||
| draft-ietf-idr-flowspec-nvo3-17.txt | |||||||||||||||||
| BGP Dissemination of Flow Specification Rules for Tunneled Traffic | |||||||||||||||||
|
This draft specifies a Border Gateway Protocol (BGP) Network Layer Reachability Information (NLRI) encoding format for flow specifications (RFC 8955) that can match on a variety of tunneled traffic. In addition, flow specification components are specified for certain tunneling header fields. | ||||||||||||||||
| draft-ietf-idr-flowspec-path-redirect-12.txt | |||||||||||||||||
| Flowspec Indirection-id Redirect | |||||||||||||||||
|
This document defines a new extended community known as "FlowSpec Redirect to indirection-id Extended Community". This extended community triggers advanced redirection capabilities to flowspec clients. When activated, this flowspec extended community is used by a flowspec client to retrieve the corresponding next-hop and encoding information within a localised indirection-id mapping table. The functionality detailed in this document allows a network controller to decouple the BGP flowspec redirection instruction from the operation of the available paths. | ||||||||||||||||
| draft-ietf-idr-flowspec-srv6-03.txt | |||||||||||||||||
| BGP Flow Specification for SRv6 | |||||||||||||||||
|
This document proposes extensions to BGP Flow Specification for SRv6 for filtering packets with a SRv6 SID that matches a sequence of conditions. | ||||||||||||||||
| draft-ietf-idr-flowspec-v2-01.txt | |||||||||||||||||
| BGP Flow Specification Version 2 | |||||||||||||||||
|
BGP flow specification version 1 (FSv1), defined in RFC 8955, RFC 8956, and RFC 9117 describes the distribution of traffic filter policy (traffic filters and actions) distributed via BGP. Multiple applications have used BGP FSv1 to distribute traffic filter policy. These applications include the following: mitigation of denial of service (DoS), enabling traffic filtering in BGP/MPLS VPNs, centralized traffic control of router firewall functions, and SFC traffic insertion. During the deployment of BGP FSv1 a number of issues were detected due to lack of consistent TLV encoding for rules for flow specifications, lack of user ordering of filter rules and/or actions, and lack of clear definition of interaction with BGP peers not supporting FSv1. Version 2 of the BGP flow specification (FSv2) protocol addresses these features. In order to provide a clear demarcation between FSv1 and FSv2, a different NLRI encapsulates FSv2. | ||||||||||||||||
| draft-ietf-idr-long-lived-gr-04.txt | |||||||||||||||||
| Support for Long-lived BGP Graceful Restart | |||||||||||||||||
|
In this document, we introduce a new BGP capability termed "Long- lived Graceful Restart Capability" so that stale routes can be retained for a longer time upon session failure than is provided for by BGP Graceful Restart (RFC 4724). A well-known BGP community "LLGR_STALE" is introduced for marking stale routes retained for a longer time. A second well-known BGP community, "NO_LLGR", is introduced to mark routes for which these procedures should not be applied. We also specify that such long-lived stale routes be treated as the least-preferred, and their advertisements be limited to BGP speakers that have advertised the new capability. Use of this extension is not advisable in all cases, and we provide guidelines to help determine if it is. We update RFC 6368 by specifying that the LLGR_STALE community must be propagated into, or out of, the path attributes exchanged between PE and CE. | ||||||||||||||||
| draft-ietf-idr-node-target-ext-comm-00.txt | |||||||||||||||||
| BGP Extended Community for Identifying the Target Nodes | |||||||||||||||||
|
BGP has been used to distribute different types of routing and policy information. In some cases, the information distributed may be only intended for one or a particular group of BGP nodes in the network. Currently BGP does not have a generic mechanism of designating the target nodes of the routing information. This document defines a new type of BGP Extended Community called "Node Target" for this purpose. | ||||||||||||||||
| draft-ietf-idr-rfc7752bis-16.txt | |||||||||||||||||
| Distribution of Link-State and Traffic Engineering Information Using BGP | |||||||||||||||||
|
In many environments, a component external to a network is called upon to perform computations based on the network topology and the current state of the connections within the network, including Traffic Engineering (TE) information. This is information typically distributed by IGP routing protocols within the network. This document describes a mechanism by which link-state and TE information can be collected from networks and shared with external components using the BGP routing protocol. This is achieved using a BGP Network Layer Reachability Information (NLRI) encoding format. The mechanism applies to physical and virtual (e.g., tunnel) IGP links. The mechanism described is subject to policy control. Applications of this technique include Application-Layer Traffic Optimization (ALTO) servers and Path Computation Elements (PCEs). This document obsoletes RFC7752 by completely replacing that document. It makes some small changes and clarifications to the previous specification. This document also obsoletes RFC9029 by incorporating the updates that it made to RFC7752. | ||||||||||||||||
| draft-ietf-idr-rpd-16.txt | |||||||||||||||||
| BGP Extensions for Routing Policy Distribution (RPD) | |||||||||||||||||
|
It is hard to adjust traffic in a traditional IP network from time to time through manual configurations. It is desirable to have a mechanism for setting up routing policies, which adjusts traffic automatically. This document describes BGP Extensions for Routing Policy Distribution (BGP RPD) to support this with a controller. | ||||||||||||||||
| draft-ietf-idr-rt-derived-community-00.txt | |||||||||||||||||
| Extended Communities Derived from Route Targets | |||||||||||||||||
|
This document specifies a way to derive an Extended Community from a Route Target and describes some example use cases. | ||||||||||||||||
| draft-ietf-idr-sdwan-edge-discovery-09.txt | |||||||||||||||||
| BGP UPDATE for SD-WAN Edge Discovery | |||||||||||||||||
|
The document describes the encoding of BGP UPDATE messages for the SD-WAN edge node property discovery. In the context of this document, BGP Route Reflector (RR) is the component of the SD-WAN Controller that receives the BGP UPDATE from SD-WAN edges and in turns propagates the information to the intended peers that are authorized to communicate via the SD-WAN overlay network. | ||||||||||||||||
| draft-ietf-idr-segment-routing-te-policy-20.txt | |||||||||||||||||
| Advertising Segment Routing Policies in BGP | |||||||||||||||||
|
This document introduces a BGP SAFI with two NLRIs to advertise a candidate path of a Segment Routing (SR) Policy. An SR Policy is an ordered list of segments (i.e., instructions) that represent a source-routed policy. An SR Policy consists of one or more candidate paths, each consisting of one or more segment lists. A headend may be provisioned with candidate paths for an SR Policy via several different mechanisms, e.g., CLI, NETCONF, PCEP, or BGP. This document specifies how BGP may be used to distribute SR Policy candidate paths. It defines sub-TLVs for the Tunnel Encapsulation Attribute for signaling information about these candidate paths. This documents updates RFC9012 with extensions to the Color Extended Community to support additional steering modes over SR Policy. | ||||||||||||||||
| draft-ietf-idr-sr-policy-ifit-05.txt | |||||||||||||||||
| BGP SR Policy Extensions to Enable IFIT | |||||||||||||||||
|
Segment Routing (SR) policy is a set of candidate SR paths consisting of one or more segment lists and necessary path attributes. It enables instantiation of an ordered list of segments with a specific intent for traffic steering. In-situ Flow Information Telemetry (IFIT) refers to network OAM data plane on-path telemetry techniques, in particular the most popular are In-situ OAM (IOAM) and Alternate Marking. This document defines extensions to BGP to distribute SR policies carrying IFIT information. So that IFIT methods can be enabled automatically when the SR policy is applied. | ||||||||||||||||
| draft-ietf-idr-sr-policy-path-mtu-06.txt | |||||||||||||||||
| Segment Routing Path MTU in BGP | |||||||||||||||||
|
Segment Routing is a source routing paradigm that explicitly indicates the forwarding path for packets at the ingress node. An SR policy is a set of candidate SR paths consisting of one or more segment lists with necessary path attributes. However, the path maximum transmission unit (MTU) information for SR path is not available in the SR policy since the SR does not require signaling. This document defines extensions to BGP to distribute path MTU information within SR policies. | ||||||||||||||||
| draft-ietf-idr-sr-policy-path-segment-07.txt | |||||||||||||||||
| SR Policy Extensions for Path Segment and Bidirectional Path | |||||||||||||||||
|
A Segment Routing (SR) policy is a set of candidate SR paths consisting of one or more segment lists with necessary path attributes. For each SR path, it may also have its own path attributes, and Path Segment is one of them. A Path Segment is defined to identify an SR path, which can be used for performance measurement, path correlation, and end-2-end path protection. Path Segment can be also used to correlate two unidirectional SR paths into a bidirectional SR path which is required in some scenarios, for example, mobile backhaul transport network. This document defines extensions to BGP to distribute SR policies carrying Path Segment and bidirectional path information. | ||||||||||||||||
| draft-ietf-idr-ts-flowspec-srv6-policy-02.txt | |||||||||||||||||
| Traffic Steering using BGP FlowSpec with SR Policy | |||||||||||||||||
|
BGP Flow Specification (FlowSpec) [RFC8955] [RFC8956] has been proposed to distribute BGP FlowSpec NLRI to FlowSpec clients to mitigate (distributed) denial-of-service attacks, and to provide traffic filtering in the context of a BGP/MPLS VPN service. Recently, traffic steering applications in the context of SR-MPLS and SRv6 using FlowSpec also attract attention. This document introduces the usage of BGP FlowSpec to steer packets into an SR Policy. | ||||||||||||||||
| draft-ietf-idr-vpn-prefix-orf-00.txt | |||||||||||||||||
| VPN Prefix Outbound Route Filter (VPN Prefix ORF) for BGP-4 | |||||||||||||||||
|
This draft defines a new Outbound Route Filter (ORF) type, called the VPN Prefix ORF. The described VPN Prefix ORF mechanism is applicable when the VPN routes from different VRFs are exchanged via one shared BGP session (e.g., routers in a single-domain connect via Route Reflector). | ||||||||||||||||
| draft-ietf-idr-wide-bgp-communities-11.txt | |||||||||||||||||
| BGP Community Container Attribute | |||||||||||||||||
|
Route tagging plays an important role in external BGP [RFC4271] relations, in communicating various routing policies between peers. It is also a common best practice among operators to propagate various additional information about routes intra-domain. The most common tool used today to attach various information about routes is through the use of BGP communities [RFC1997]. This document defines a new encoding that enhances and simplifies what can be accomplished with BGP communities. This specification's most important addition is the ability to specify and advertise an operator's parameters for execution. It also provides an extensible platform for any future community encoding requirements. | ||||||||||||||||
| draft-ietf-intarea-rfc7042bis-03.txt | |||||||||||||||||
| IANA Considerations and IETF Protocol and Documentation Usage for IEEE 802 Parameters | |||||||||||||||||
|
Some IETF protocols make use of Ethernet frame formats and IEEE 802 parameters. This document discusses several aspects of such parameters and their use in IETF protocols, specifies IANA considerations for assignment of points under the IANA OUI (Organizationally Unique Identifier), and provides some values for use in documentation. This document obsoletes RFC 7042. | ||||||||||||||||
| draft-ietf-intarea-schc-protocol-numbers-00.txt | |||||||||||||||||
| Protocol Numbers for SCHC | |||||||||||||||||
|
This document requests an Internet Protocol Number, an Ethertype, and UDP port assignment for SCHC. The Internet Protocol Number request is so that SCHC can be used for IP independent SCHC of other transports such as UDP and ESP. The Ethertype is to support generic use of native SCHC over any IEEE 802 technology for IP and non-IP protocols. The UDP port request is to support End-to-End SCHC through potentially blocking firewalls. | ||||||||||||||||
| draft-ietf-intarea-tunnels-13.txt | |||||||||||||||||
| IP Tunnels in the Internet Architecture | |||||||||||||||||
|
This document discusses the role of IP tunnels in the Internet architecture. An IP tunnel transits IP datagrams as payloads in non- link layer protocols. This document explains the relationship of IP tunnels to existing protocol layers and the challenges in supporting IP tunneling, based on the equivalence of tunnels to links. The implications of this document updates RFC 4459 and its MTU and fragmentation recommendations for IP tunnels. | ||||||||||||||||
| draft-ietf-iotops-security-protocol-comparison-02.txt | |||||||||||||||||
| Comparison of CoAP Security Protocols | |||||||||||||||||
|
This document analyzes and compares the sizes of key exchange flights and the per-packet message size overheads when using different security protocols to secure CoAP. The described overheads are independent of the underlying transport. Small message sizes are very important for reducing energy consumption, latency, and time to completion in constrained radio network such as Low-Power Wide Area Networks (LPWANs). The analyzed security protocols are DTLS 1.2, DTLS 1.3, TLS 1.2, TLS 1.3, cTLS, EDHOC, OSCORE, and Group OSCORE. The DTLS and TLS record layers are analyzed with and without 6LoWPAN- GHC compression. DTLS is analyzed with and without Connection ID. | ||||||||||||||||
| draft-ietf-ippm-capacity-protocol-04.txt | |||||||||||||||||
| Test Protocol for One-way IP Capacity Measurement | |||||||||||||||||
|
This memo addresses the problem of protocol support for measuring Network Capacity metrics in RFC 9097, where the method deploys a feedback channel from the receiver to control the sender's transmission rate in near-real-time. This memo defines a simple protocol to perform the RFC 9097 (and other) measurements. | ||||||||||||||||
| draft-ietf-ippm-connectivity-monitoring-05.txt | |||||||||||||||||
| A Connectivity Monitoring Metric for IPPM | |||||||||||||||||
|
Within a Segment Routing domain, segment routed measurement packets can be sent along pre-determined paths. This enables new kinds of measurements. Connectivity monitoring allows to supervise the state and performance of a connection or a (sub)path from one or a few central monitoring systems. This document specifies a suitable type-P connectivity monitoring metric. | ||||||||||||||||
| draft-ietf-ippm-encrypted-pdmv2-03.txt | |||||||||||||||||
| IPv6 Performance and Diagnostic Metrics Version 2 (PDMv2) Destination Option | |||||||||||||||||
|
RFC8250 describes an optional Destination Option (DO) header embedded in each packet to provide sequence numbers and timing information as a basis for measurements. As this data is sent in clear-text, this may create an opportunity for malicious actors to get information for subsequent attacks. This document defines PDMv2 which has a lightweight handshake (registration procedure) and encryption to secure this data. Additional performance metrics which may be of use are also defined. | ||||||||||||||||
| draft-ietf-ippm-explicit-flow-measurements-03.txt | |||||||||||||||||
| Explicit Host-to-Network Flow Measurements Techniques | |||||||||||||||||
|
This document describes protocol independent methods called Explicit Host-to-Network Flow Measurement Techniques that can be applicable to transport-layer protocols between client and server. These methods employ just a few marking bits inside the header of each packet for performance measurements and require collaborative client and server. Both endpoints cooperate by marking and, possibly, mirroring information back and forward on the round-trip connection. The techniques are especially valuable when applied to protocols that encrypt transport headers, since they enable loss and delay measurements by passive on-path network devices. Different techniques are considered within this document. | ||||||||||||||||
| draft-ietf-ippm-ioam-data-integrity-03.txt | |||||||||||||||||
| Integrity of In-situ OAM 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 to ensure their security. This document describes the integrity protection of IOAM-Data-Fields. | ||||||||||||||||
| draft-ietf-ippm-ioam-deployment-05.txt | |||||||||||||||||
| In-situ OAM Deployment | |||||||||||||||||
|
In-situ Operations, Administration, and Maintenance (IOAM) collects operational and telemetry information in the packet while the packet traverses a path between two points in the network. This document provides a framework for IOAM deployment and provides IOAM deployment considerations and guidance. | ||||||||||||||||
| draft-ietf-ippm-ioam-ipv6-options-10.txt | |||||||||||||||||
| In-situ OAM IPv6 Options | |||||||||||||||||
|
In-situ Operations, Administration, and Maintenance (IOAM) records operational and telemetry information in the packet while the packet traverses a path between two points in the network. This document outlines how IOAM data fields are encapsulated in IPv6. | ||||||||||||||||
| draft-ietf-ippm-ioam-yang-06.txt | |||||||||||||||||
| A YANG Data Model for In-Situ OAM | |||||||||||||||||
|
In situ Operations, Administration, and Maintenance (IOAM) collects operational and telemetry information in the packet while the packet traverses a path between two points in the network. RFC9197 discusses the data fields and associated data types for IOAM. This document defines a YANG module for the IOAM function. | ||||||||||||||||
| draft-ietf-ippm-otwamp-on-lag-01.txt | |||||||||||||||||
| One-way/Two-way Active Measurement Protocol Extensions for Performance Measurement on LAG | |||||||||||||||||
|
This document defines extensions to One-way Active Measurement Protocol (OWAMP), and Two-way Active Measurement Protocol (TWAMP) to implement performance measurement on every member link of a Link Aggregation Group (LAG). Knowing the measured metrics of each member link of a LAG enables operators to enforce the performance based traffic steering policy across the member links. | ||||||||||||||||
| draft-ietf-ippm-pam-01.txt | |||||||||||||||||
| Precision Availability Metrics for SLO-Governed End-to-End Services | |||||||||||||||||
|
This document defines a set of metrics for networking services with performance requirements expressed as Service Level Objectives (SLO). These metrics, referred to as Precision Availability Metrics (PAM), are useful for defining and monitoring of SLOs. For example, PAM can be used by providers and/or users of the Network Slice service to assess whether the service is provided in compliance with its specified quality, i.e., in accordance with its defined SLOs. | ||||||||||||||||
| draft-ietf-ippm-responsiveness-02.txt | |||||||||||||||||
| Responsiveness under Working Conditions | |||||||||||||||||
|
For many years, a lack of responsiveness, variously called lag, latency, or bufferbloat, has been recognized as an unfortunate, but common, symptom in today's networks. Even after a decade of work on standardizing technical solutions, it remains a common problem for the end users. Everyone "knows" that it is "normal" for a video conference to have problems when somebody else at home is watching a 4K movie or uploading photos from their phone. However, there is no technical reason for this to be the case. In fact, various queue management solutions have solved the problem. Our networks remain unresponsive, not from a lack of technical solutions, but rather a lack of awareness of the problem and deployment of its solutions. We believe that creating a tool that measures the problem and matches people's everyday experience will create the necessary awareness, and result in a demand for solutions. This document specifies the "Responsiveness Test" for measuring responsiveness. It uses common protocols and mechanisms to measure user experience specifically when the network is under working conditions. The measurement is expressed as "Round-trips Per Minute" (RPM) and should be included with throughput (up and down) and idle latency as critical indicators of network quality. | ||||||||||||||||
| draft-ietf-ippm-stamp-on-lag-01.txt | |||||||||||||||||
| Simple Two-Way Active Measurement Protocol Extensions for Performance Measurement on LAG | |||||||||||||||||
|
This document extends Simple Two-Way Active Measurement Protocol (STAMP) to implement performance measurement on every member link of a Link Aggregation Group (LAG). Knowing the measured metrics of each member link of a LAG enables operators to enforce a performance based traffic steering policy across the member links. | ||||||||||||||||
| draft-ietf-ippm-stamp-srpm-09.txt | |||||||||||||||||
| Simple TWAMP (STAMP) Extensions for Segment Routing Networks | |||||||||||||||||
|
Segment Routing (SR) leverages the source routing paradigm. SR is applicable to both Multiprotocol Label Switching (SR-MPLS) and IPv6 (SRv6) forwarding planes. This document specifies RFC 8762 (Simple Two-Way Active Measurement Protocol (STAMP)) extensions for SR networks, for both SR-MPLS and SRv6 forwarding planes by augmenting the optional extensions defined in RFC 8972. | ||||||||||||||||
| draft-ietf-ippm-stamp-yang-11.txt | |||||||||||||||||
| Simple Two-way Active Measurement Protocol (STAMP) Data Model | |||||||||||||||||
|
This document specifies the data model for implementations of Session-Sender and Session-Reflector for Simple Two-way Active Measurement Protocol (STAMP) mode using YANG. | ||||||||||||||||
| draft-ietf-ipsecme-add-ike-11.txt | |||||||||||||||||
| Internet Key Exchange Protocol Version 2 (IKEv2) Configuration for Encrypted DNS | |||||||||||||||||
|
This document specifies new Internet Key Exchange Protocol Version 2 (IKEv2) Configuration Payload Attribute Types to assign DNS resolvers that support encrypted DNS protocols, such as DNS-over-HTTPS (DoH), DNS-over-TLS (DoT), and DNS-over-QUIC (DoQ). | ||||||||||||||||
| draft-ietf-ipsecme-g-ikev2-09.txt | |||||||||||||||||
| Group Key Management using IKEv2 | |||||||||||||||||
|
This document presents an extension to the Internet Key Exchange version 2 (IKEv2) protocol for the purpose of a group key management. The protocol is in conformance with the Multicast Security (MSEC) key management architecture, which contains two components: member registration and group rekeying. Both components require a Group Controller/Key Server to download IPsec group security associations to authorized members of a group. The group members then exchange IP multicast or other group traffic as IPsec packets. This document obsoletes RFC 6407. This documents also updates RFC 7296 by renaming a transform type 5 from "Extended Sequence Numbers (ESN)" to the "Replay Protection (RP)" and by renaming IKEv2 authentication method 0 from "Reserved" to "NONE". | ||||||||||||||||
| draft-ietf-ipsecme-ikev1-algo-to-historic-09.txt | |||||||||||||||||
| Deprecation of IKEv1 and obsoleted algorithms | |||||||||||||||||
|
Internet Key Exchange version 1 (IKEv1) has been deprecated and its specification in RFC2407, RFC2408 and RFC2409 have been moved to Historic status. This document updates RFC 8221 and RFC 8247 to reflect the usage guidelines of old algorithms that are associated with IKEv1, and are not specified or commonly implemented for IKEv2. This document further updates the IANA IKEv2 Transform Type registries to add a Status column where deprecation status can be listed. | ||||||||||||||||
| draft-ietf-ipsecme-ikev2-auth-announce-03.txt | |||||||||||||||||
| Announcing Supported Authentication Methods in IKEv2 | |||||||||||||||||
|
This specification defines a mechanism that allows the Internet Key Exchange version 2 (IKEv2) implementations to indicate the list of supported authentication methods to their peers while establishing IKEv2 Security Association (SA). This mechanism improves interoperability when IKEv2 partners are configured with multiple different credentials to authenticate each other. | ||||||||||||||||
| draft-ietf-ipsecme-ikev2-multiple-ke-12.txt | |||||||||||||||||
| Multiple Key Exchanges in IKEv2 | |||||||||||||||||
|
This document describes how to extend the Internet Key Exchange Protocol Version 2 (IKEv2) to allow multiple key exchanges to take place while computing a shared secret during a Security Association (SA) setup. The primary application of this feature in IKEv2 is the ability to perform one or more post-quantum key exchanges in conjunction with the classical (Elliptic Curve) Diffie-Hellman (EC)DH key exchange, so that the resulting shared key is resistant against quantum computer attacks. Since there is currently no post-quantum key exchange that is as well-studied as (EC)DH, performing multiple key exchanges with different post-quantum algorithms along with the well-established classical key exchange algorithms addresses this concern, since the overall security is at least as strong as each individual primitive. Another possible application for this extension is the ability to combine several key exchanges in situations when no single key exchange algorithm is trusted by both initiator and responder. This document utilizes the IKE_INTERMEDIATE exchange, by means of which multiple key exchanges are performed when an IKE SA is being established. It also introduces a new IKEv2 exchange IKE_FOLLOWUP_KE, which is used for the same purpose when the IKE SA is up (during rekeys or creating additional Child SAs). This document updates RFC7296 by renaming a transform type 4 from "Diffie-Hellman Group (D-H)" to "Key Exchange Method (KE)" and renaming a field in the Key Exchange Payload from "Diffie-Hellman Group Num" to "Key Exchange Method". It also renames an IANA registry for this transform type from "Transform Type 4 - Diffie- Hellman Group Transform IDs" to "Transform Type 4 - Key Exchange Method Transform IDs". These changes generalize key exchange algorithms that can be used in IKEv2. | ||||||||||||||||
| draft-ietf-ipsecme-ikev2-sa-ts-payloads-opt-00.txt | |||||||||||||||||
| IKEv2 Optional SA&TS Payloads in Child Exchange | |||||||||||||||||
|
This document describes a method for reducing the size of the Internet Key Exchange version 2 (IKEv2) CREATE_CHILD_SA exchanges used for rekeying of the IKE or Child SA by replacing the SA and TS payloads with a Notify Message payload. Reducing size and complexity of IKEv2 exchanges is especially useful for low power consumption battery powered devices. | ||||||||||||||||
| draft-ietf-ipsecme-labeled-ipsec-11.txt | |||||||||||||||||
| Labeled IPsec Traffic Selector support for IKEv2 | |||||||||||||||||
|
This document defines a new Traffic Selector (TS) Type for Internet Key Exchange version 2 to add support for negotiating Mandatory Access Control (MAC) security labels as a traffic selector of the Security Policy Database (SPD). Security Labels for IPsec are also known as "Labeled IPsec". The new TS type is TS_SECLABEL, which consists of a variable length opaque field specifying the security label. | ||||||||||||||||
| draft-ietf-ipsecme-multi-sa-performance-00.txt | |||||||||||||||||
| IKEv2 support for per-queue Child SAs | |||||||||||||||||
|
This document defines three Notify Message Type Payloads for the Internet Key Exchange Protocol Version 2 (IKEv2) indicating support for the negotiation of multiple identical Child SAs to optimize performance. The CPU_QUEUES notification indicates support for multiple queues or CPUs. The CPU_QUEUE_INFO notification is used to confirm and optionally convey information about the specific queue. The TS_MAX_QUEUE notify conveys that the peer is unwilling to create more additional Child SAs for this particular Traffic Selector set. Using multiple identical Child SAs has the benefit that each stream has its own Sequence Number Counter, ensuring that CPUs don't have to synchronize their crypto state or disable their packet replay protection. | ||||||||||||||||
| draft-ietf-isis-sr-yang-15.txt | |||||||||||||||||
| YANG Data Model for IS-IS Segment Routing | |||||||||||||||||
|
This document defines a YANG data module that can be used to configure and manage IS-IS Segment Routing for MPLS data plane. | ||||||||||||||||
| draft-ietf-jmap-blob-18.txt | |||||||||||||||||
| JMAP Blob management extension | |||||||||||||||||
|
The JMAP base protocol (RFC8620) provides the ability to upload and download arbitrary binary data via HTTP POST and GET on defined endpoint. This binary data is called a "blob". This extension adds additional ways to create and access blobs, by making inline method calls within a standard JMAP request. This extension also adds a reverse lookup mechanism to discover where blobs are referenced within other data types. | ||||||||||||||||
| draft-ietf-jmap-calendars-11.txt | |||||||||||||||||
| JMAP for Calendars | |||||||||||||||||
|
This document specifies a data model for synchronizing calendar data with a server using JMAP. | ||||||||||||||||
| draft-ietf-jmap-contacts-00.txt | |||||||||||||||||
| JMAP for Contacts | |||||||||||||||||
|
This document specifies a data model for synchronising contacts data with a server using JMAP. | ||||||||||||||||
| draft-ietf-jmap-quotas-12.txt | |||||||||||||||||
| JMAP for Quotas | |||||||||||||||||
|
This document specifies a data model for handling quotas on accounts with a server using the JSON Meta Application Protocol (JMAP). | ||||||||||||||||
| draft-ietf-jmap-sharing-03.txt | |||||||||||||||||
| JMAP Sharing | |||||||||||||||||
|
This document specifies a data model for sharing data between users using JMAP. Specifications for other data types can reference this document to support a consistent model of sharing. | ||||||||||||||||
| draft-ietf-jmap-sieve-14.txt | |||||||||||||||||
| JMAP for Sieve Scripts | |||||||||||||||||
|
This document specifies a data model for managing Sieve scripts on a server using the JSON Meta Application Protocol (JMAP). Open Issues * Should ALL Sieve capabilites be in the JMAP Session capabilities property rather than in the accountCapabilities property? Would the capabilities actually differ between users? | ||||||||||||||||
| draft-ietf-jmap-smime-sender-extensions-03.txt | |||||||||||||||||
| JMAP extension for S/MIME signing and encryption | |||||||||||||||||
|
This document specifies an extension to JMAP for sending S/MIME signed and S/MIME encrypted messages. | ||||||||||||||||
| draft-ietf-jmap-tasks-06.txt | |||||||||||||||||
| JMAP for Tasks | |||||||||||||||||
|
This document specifies a data model for synchronizing task data with a server using JMAP. | ||||||||||||||||
| draft-ietf-jsonpath-base-13.txt | |||||||||||||||||
| JSONPath: Query expressions for JSON | |||||||||||||||||
|
JSONPath defines a string syntax for selecting and extracting JSON (RFC 8259) values from a JSON value. | ||||||||||||||||
| draft-ietf-jsonpath-iregexp-04.txt | |||||||||||||||||
| I-Regexp: An Interoperable Regexp Format | |||||||||||||||||
|
This document specifies I-Regexp, a flavor of regular expressions that is limited in scope with the goal of interoperation across many different regular-expression libraries. | ||||||||||||||||
| draft-ietf-kitten-krb-spake-preauth-10.txt | |||||||||||||||||
| SPAKE Pre-Authentication | |||||||||||||||||
|
This document defines a new pre-authentication mechanism for the Kerberos protocol. The mechanism uses a password-authenticated key exchange to prevent brute-force password attacks, and may optionally incorporate a second factor. | ||||||||||||||||
| draft-ietf-kitten-sasl-saml-ec-20.txt | |||||||||||||||||
| SAML Enhanced Client SASL and GSS-API Mechanisms | |||||||||||||||||
|
Security Assertion Markup Language (SAML) 2.0 is a generalized framework for the exchange of security-related information between asserting and relying parties. Simple Authentication and Security Layer (SASL) and the Generic Security Service Application Program Interface (GSS-API) are application frameworks that facilitate an extensible authentication model, among other things. This document specifies a SASL and GSS-API mechanism for SAML 2.0 that leverages the capabilities of a SAML-aware "enhanced client" to address significant barriers to federated authentication in a manner that encourages reuse of existing SAML bindings and profiles designed for non-browser scenarios. | ||||||||||||||||
| draft-ietf-kitten-scram-2fa-02.txt | |||||||||||||||||
| Extensions to Salted Challenge Response (SCRAM) for 2 factor authentication | |||||||||||||||||
|
This specification describes an extension to family of Simple Authentication and Security Layer (SASL; RFC 4422) authentication mechanisms called the Salted Challenge Response Authentication Mechanism (SCRAM), which provides support for 2 factor authentication. It also includes a separate extension for quick reauthentication. This specification also gives an example of how TOTP (RFC 6238) can be used as the second factor. | ||||||||||||||||
| draft-ietf-lake-edhoc-19.txt | |||||||||||||||||
| Ephemeral Diffie-Hellman Over COSE (EDHOC) | |||||||||||||||||
|
This document specifies Ephemeral Diffie-Hellman Over COSE (EDHOC), a very compact and lightweight authenticated Diffie-Hellman key exchange with ephemeral keys. EDHOC provides mutual authentication, forward secrecy, and identity protection. EDHOC is intended for usage in constrained scenarios and a main use case is to establish an OSCORE security context. By reusing COSE for cryptography, CBOR for encoding, and CoAP for transport, the additional code size can be kept very low. | ||||||||||||||||
| draft-ietf-lake-traces-04.txt | |||||||||||||||||
| Traces of EDHOC | |||||||||||||||||
|
This document contains some example traces of Ephemeral Diffie- Hellman Over COSE (EDHOC). | ||||||||||||||||
| draft-ietf-lamps-caa-issuemail-01.txt | |||||||||||||||||
| Certification Authority Authorization (CAA) Processing for Email Addresses | |||||||||||||||||
|
The Certification Authority Authorization (CAA) DNS resource record (RR) provides a mechanism for domains to express the allowed set of Certification Authorities (CAs) that are authorized issue certificates for the domain. RFC 8659 contains the core CAA specification, where Property Tags that restrict the issuance of certificates which certify domain names are defined. This specification defines a Property Tag that grants authorization to CAs to issue certificates which certify email addresses that include the domain name. | ||||||||||||||||
| draft-ietf-lamps-cert-binding-for-multi-auth-00.txt | |||||||||||||||||
| Related Certificates for Use in Multiple Authentications within a Protocol | |||||||||||||||||
|
This document defines a new CSR attribute, relatedCertRequest, and a new X.509 certificate extension, RelatedCertificate. The use of the relatedCertRequest attribute in a CSR and the inclusion of the RelatedCertificate extension in the resulting certificate together provide additional assurance that two certificates each belong to the same end entity. This mechanism is particularly useful in the context of non-composite hybrid authentication, which enables users to employ the same certificates in hybrid authentication as in authentication done with only traditional or post-quantum algorithms. | ||||||||||||||||
| draft-ietf-lamps-cmp-algorithms-15.txt | |||||||||||||||||
| Certificate Management Protocol (CMP) Algorithms | |||||||||||||||||
|
This document describes the conventions for using several cryptographic algorithms with the Certificate Management Protocol (CMP). CMP is used to enroll and further manage the lifecycle of X.509 certificates. This document also updates the algorithm use profile from RFC 4210 Appendix D.2. | ||||||||||||||||
| draft-ietf-lamps-cmp-updates-23.txt | |||||||||||||||||
| Certificate Management Protocol (CMP) Updates | |||||||||||||||||
|
This document contains a set of updates to the syntax and transfer of Certificate Management Protocol (CMP) version 2. This document updates RFC 4210, RFC 5912, and RFC 6712. The aspects of CMP updated in this document are using EnvelopedData instead of EncryptedValue, clarifying the handling of p10cr messages, improving the crypto agility, as well as adding new general message types, extended key usages to identify certificates for use with CMP, and well-known URI path segments. CMP version 3 is introduced to enable signaling support of EnvelopedData instead of EncryptedValue and signaling the use of an explicit hash AlgorithmIdentifier in certConf messages, as far as needed. | ||||||||||||||||
| draft-ietf-lamps-cms-kemri-00.txt | |||||||||||||||||
| Using Key Encapsulation Mechanism (KEM) Algorithms in the Cryptographic Message Syntax (CMS) | |||||||||||||||||
|
The Cryptographic Message Syntax (CMS) supports key transport and key agreement algorithms. In recent years, cryptographers have been specifying Key Encapsulation Mechanism (KEM) algorithms, including quantum-secure KEM algorithms. This document defines conventions for the use of KEM algorithms by the originator and recipients to encrypt CMS content. | ||||||||||||||||
| draft-ietf-lamps-cms-kyber-00.txt | |||||||||||||||||
| Use of KYBER in the Cryptographic Message Syntax (CMS) | |||||||||||||||||
|
This document describes the conventions for using a Key Encapsulation Mechanism algorithm (KEM) within the Cryptographic Message Syntax (CMS). The CMS specifies the envelopped-data content type, which consists of an encrypted content and encrypted content-encryption keys for one or more recipients. The mechanism proposed here can rely on either post-quantum KEMs, hybrid KEMs or classical KEMs. | ||||||||||||||||
| draft-ietf-lamps-cms-sphincs-plus-01.txt | |||||||||||||||||
| Use of the SPHINCS+ Signature Algorithm in the Cryptographic Message Syntax (CMS) | |||||||||||||||||
|
SPHINCS+ is a stateless hash-based signature scheme. This document specifies the conventions for using the SPHINCS+ stateless hash-based signature algorithm with the Cryptographic Message Syntax (CMS). In addition, the algorithm identifier and public key syntax are provided. | ||||||||||||||||
| draft-ietf-lamps-dilithium-certificates-01.txt | |||||||||||||||||
| Internet X.509 Public Key Infrastructure: Algorithm Identifiers for Dilithium | |||||||||||||||||
|
Digital signatures are used within X.509 certificates, Certificate Revocation Lists (CRLs), and to sign messages. This document describes the conventions for using Dilithium quantum-resistant signatures in Internet X.509 certificates and certificate revocation lists. The conventions for the associated post-quantum signatures, subject public keys, and private key are also described. | ||||||||||||||||
| draft-ietf-lamps-e2e-mail-guidance-06.txt | |||||||||||||||||
| Guidance on End-to-End E-mail Security | |||||||||||||||||
|
End-to-end cryptographic protections for e-mail messages can provide useful security. However, the standards for providing cryptographic protection are extremely flexible. That flexibility can trap users and cause surprising failures. This document offers guidance for mail user agent implementers that need to compose or interpret e-mail messages with end-to-end cryptographic protection. It provides a useful set of vocabulary as well as suggestions to avoid common failures. | ||||||||||||||||
| draft-ietf-lamps-header-protection-14.txt | |||||||||||||||||
| Header Protection for Cryptographically Protected E-mail | |||||||||||||||||
|
S/MIME version 3.1 introduced a mechanism to provide end-to-end cryptographic protection of e-mail message headers. However, few implementations generate messages using this mechanism, and several legacy implementations have revealed rendering or security issues when handling such a message. This document updates the S/MIME specification to offer a different mechanism that provides the same cryptographic protections but with fewer downsides when handled by legacy clients. The header protection schemes described here are also applicable to messages with PGP/MIME cryptographic protections. Furthermore, this document offers more explicit guidance for clients when generating or handling e-mail messages with cryptographic protection of message headers. | ||||||||||||||||
| draft-ietf-lamps-key-attestation-ext-00.txt | |||||||||||||||||
| Key Attestation Extension for Certificate Management Protocols | |||||||||||||||||
|
Certification Authorities (CAs) issue certificates for public keys conveyed to the CA via a certificate management message or protocol. In some cases, a CA may wish to tailor certificate contents based on whether the corresponding private key is secured by hardware in non- exportable form. This document describes extensions that may be included in any of several widely used certificate management protocols to convey attestations about the private key to the CA to support this determination. | ||||||||||||||||
| draft-ietf-lamps-kyber-00.txt | |||||||||||||||||
| Use of KYBER in the Cryptographic Message Syntax (CMS) | |||||||||||||||||
|
This document describes the conventions for using a Key Encapsulation Mechanism algorithm (KEM) within the Cryptographic Message Syntax (CMS). The CMS specifies the envelopped-data content type, which consists of an encrypted content and encrypted content-encryption keys for one or more recipients. The mechanism proposed here can rely on either post-quantum KEMs, hybrid KEMs or classical KEMs but this document specifies the use of Kyber. | ||||||||||||||||
| draft-ietf-lamps-kyber-certificates-01.txt | |||||||||||||||||
| Internet X.509 Public Key Infrastructure - Algorithm Identifiers for Kyber | |||||||||||||||||
|
Kyber is a key-encapsulation mechanism (KEM). This document specifies algorithm identifiers and ASN.1 encoding format for Kyber in public key certificates. The encoding for public and private keys are also provided. [EDNOTE: This document is not expected to be finalized before the NIST PQC Project has standardized PQ algorithms. This specification will use object identifiers for the new algorithms that are assigned by NIST, and will use placeholders until these are released.] | ||||||||||||||||
| draft-ietf-lamps-lightweight-cmp-profile-21.txt | |||||||||||||||||
| Lightweight Certificate Management Protocol (CMP) Profile | |||||||||||||||||
|
This document aims at simple, interoperable, and automated PKI management operations covering typical use cases of industrial and IoT scenarios. This is achieved by profiling the Certificate Management Protocol (CMP), the related Certificate Request Message Format (CRMF), and HTTP-based or CoAP-based transfer in a succinct but sufficiently detailed and self-contained way. To make secure certificate management for simple scenarios and constrained devices as lightweight as possible, only the most crucial types of operations and options are specified as mandatory. More specialized or complex use cases are supported with optional features. | ||||||||||||||||
| draft-ietf-lamps-pkcs12-pbmac1-01.txt | |||||||||||||||||
| Use of Password Based Message Authentication Code 1 (PBMAC1) in PKCS #12 Syntax | |||||||||||||||||
|
This document specifies additions and amendments to RFC 7292. It defines a way to use the Password Based Message Authentication Code 1, defined in RFC 8018, inside the PKCS #12 syntax. The purpose of this specification is to permit use of more modern PBKDFs and allow for regulatory compliance. | ||||||||||||||||
| draft-ietf-lamps-rfc3709bis-10.txt | |||||||||||||||||
| Internet X.509 Public Key Infrastructure: Logotypes in X.509 Certificates | |||||||||||||||||
|
This document specifies a certificate extension for including logotypes in public key certificates and attribute certificates. This document obsoletes RFC 3709 and RFC 6170. | ||||||||||||||||
| draft-ietf-lamps-rfc4210bis-06.txt | |||||||||||||||||
| Internet X.509 Public Key Infrastructure -- Certificate Management Protocol (CMP) | |||||||||||||||||
|
This document describes the Internet X.509 Public Key Infrastructure (PKI) Certificate Management Protocol (CMP). Protocol messages are defined for X.509v3 certificate creation and management. CMP provides interactions between client systems and PKI components such as a Registration Authority (RA) and a Certification Authority (CA). This document obsoletes RFC 4210 by including the updates specified by CMP Updates [RFCAAAA] Section 2 and Appendix A.2 maintaining backward compatibility with CMP version 2 wherever possible and obsoletes both documents. Updates to CMP version 2 are: improving crypto agility, extending the polling mechanism, adding new general message types, and adding extended key usages to identify special CMP server authorizations. Introducing version 3 to be used only for changes to the ASN.1 syntax, which are: support of EnvelopedData instead of EncryptedValue and hashAlg for indicating a hash AlgorithmIdentifier in certConf messages. In addition to the changes specified in CMP Updates [RFCAAAA] this document adds support for management of KEM certificates. | ||||||||||||||||
| draft-ietf-lamps-rfc5990bis-00.txt | |||||||||||||||||
| Use of the RSA-KEM Algorithm in the Cryptographic Message Syntax (CMS) | |||||||||||||||||
|
The RSA Key Encapsulation Mechanism (RSA-KEM) Algorithm is a one-pass (store-and-forward) cryptographic mechanism for an originator to securely send keying material to a recipient using the recipient's RSA public key. The RSA-KEM Algorithm is specified in Clause 11.5 of ISO/IEC: 18033-2:2006. This document specifies the conventions for using the RSA-KEM Algorithm with the Cryptographic Message Syntax (CMS) using KEMRecipientInfo as specified in draft-ietf-lamps-cms- kemri. | ||||||||||||||||
| draft-ietf-lamps-rfc6712bis-03.txt | |||||||||||||||||
| Internet X.509 Public Key Infrastructure -- HTTP Transfer for the Certificate Management Protocol (CMP) | |||||||||||||||||
|
This document describes how to layer the Certificate Management Protocol (CMP) over HTTP. It includes the updates on RFC 6712 specified in CMP Updates [RFCAAAA] Section 3 and obsoleted both documents. These updates introduce CMP URIs using a Well-known prefix. | ||||||||||||||||
| draft-ietf-lamps-rfc7030-csrattrs-02.txt | |||||||||||||||||
| Clarification of RFC7030 CSR Attributes definition | |||||||||||||||||
|
The Enrollment over Secure Transport (EST, RFC7030) is ambiguous in its specification of the CSR Attributes Response. This has resulted in implementation challenges and implementor confusion. This document updates RFC7030 (EST) and clarifies how the CSR Attributes Response can be used by an EST server to specify both CSR attribute OIDs and also CSR attribute values, in particular X.509 extension values, that the server expects the client to include in subsequent CSR request. | ||||||||||||||||
| draft-ietf-lisp-ecdsa-auth-10.txt | |||||||||||||||||
| LISP Control-Plane ECDSA Authentication and Authorization | |||||||||||||||||
|
This draft describes how LISP control-plane messages can be individually authenticated and authorized without a a priori shared- key configuration. Public-key cryptography is used with no new PKI infrastructure required. | ||||||||||||||||
| draft-ietf-lisp-eid-anonymity-14.txt | |||||||||||||||||
| LISP EID Anonymity | |||||||||||||||||
|
This specification will describe how ephemeral LISP EIDs can be used to create source anonymity. The idea makes use of frequently changing EIDs much like how a credit-card system uses a different credit-card numbers for each transaction. | ||||||||||||||||
| draft-ietf-lisp-eid-mobility-11.txt | |||||||||||||||||
| LISP L2/L3 EID Mobility Using a Unified Control Plane | |||||||||||||||||
|
The LISP control plane offers the flexibility to support multiple overlay flavors simultaneously. This document specifies how LISP can be used to provide control-plane support to deploy a unified L2 and L3 overlay solution for End-point Identifier (EID) mobility, as well as analyzing possible deployment options and models. | ||||||||||||||||
| draft-ietf-lisp-geo-01.txt | |||||||||||||||||
| LISP Geo-Coordinate Use-Cases | |||||||||||||||||
|
This draft describes how Geo-Coordinates can be used in the LISP Architecture and Protocols. Some use-cases can be geo-fencing and physically locating objects. | ||||||||||||||||
| draft-ietf-lisp-map-server-reliable-transport-01.txt | |||||||||||||||||
| LISP Map Server Reliable Transport | |||||||||||||||||
|
The communication between LISP ETRs and Map-Servers is based on unreliable UDP message exchange coupled with periodic message transmission in order to maintain soft state. The drawback of periodic messaging is the constant load imposed on both the ETR and the Map-Server. New use cases for LISP have increased the amount of state that needs to be communicated with requirements that are not satisfied by the current mechanism. This document introduces the use of a reliable transport for ETR to Map-Server communication in order to eliminate the periodic messaging overhead, while providing reliability, flow-control and endpoint liveness detection. | ||||||||||||||||
| draft-ietf-lisp-mn-13.txt | |||||||||||||||||
| LISP Mobile Node | |||||||||||||||||
|
This document describes how a lightweight version of LISP's ITR/ETR functionality can be used to provide seamless mobility to a mobile node. The LISP Mobile Node design described in this document uses standard LISP functionality to provide scalable mobility for LISP mobile nodes. | ||||||||||||||||
| draft-ietf-lisp-name-encoding-01.txt | |||||||||||||||||
| LISP Distinguished Name Encoding | |||||||||||||||||
|
This draft defines how to use the AFI=17 Distinguished Names in LISP. | ||||||||||||||||
| draft-ietf-lisp-nexagon-50.txt | |||||||||||||||||
| Network-Hexagons:Geolocation Mobility Network Based On H3 and LISP | |||||||||||||||||
|
This specification describes the use of the Locator/ID Separation Protocol (LISP) for network virtualization overlays (NVO) that support mobility geolocation network functions. Distributed network functions are anchored by logically addressable geolocation agents, which are distributed between the automotive-edge and vehicular far-edge agents. Geolocation agents' endpoint identifiers (EID) are determined by the H3 hexagonal grid jurisdiction and the functions they anchor. Geolocation agents consolidate, delegate, federate, and propagate information and logic to and from in-vehicle agents. In-vehicle agents' EIDs are ephemeral to protect the vehicle owner's geo-privacy while interacting with geolocation agents. In-vehicle agents' EIDs are obtained and renewed through an authorization, authentication, and accounting procedure (AAA). Geolocation functions include mapping, training, and notification prompts using an H3-based key-value language and messages. Primary functions are invoked while vehicles are driving, and secondary distributed functions while vehicles are parked use the same LISP network overlay and EID addressing scheme. | ||||||||||||||||
| draft-ietf-lisp-predictive-rlocs-12.txt | |||||||||||||||||
| LISP Predictive RLOCs | |||||||||||||||||
|
This specification describes a method to achieve near-zero packet loss when an EID is roaming quickly across RLOCs. | ||||||||||||||||
| draft-ietf-lisp-pubsub-15.txt | |||||||||||||||||
| Publish/Subscribe Functionality for the Locator/ID Separation Protocol (LISP) | |||||||||||||||||
|
This document specifies an extension to the request/reply based Locator/ID Separation Protocol (LISP) control plane to enable Publish/Subscribe (PubSub) operation. | ||||||||||||||||
| draft-ietf-lisp-te-12.txt | |||||||||||||||||
| LISP Traffic Engineering Use-Cases | |||||||||||||||||
|
This document describes how LISP reencapsulating tunnels can be used for Traffic Engineering purposes. The mechanisms described in this document require no LISP protocol changes but do introduce a new locator (RLOC) encoding. The Traffic Engineering features provided by these LISP mechanisms can span intra-domain, inter-domain, or combination of both. | ||||||||||||||||
| draft-ietf-lisp-vpn-11.txt | |||||||||||||||||
| LISP Virtual Private Networks (VPNs) | |||||||||||||||||
|
This document describes the use of the Locator/ID Separation Protocol (LISP) to create Virtual Private Networks (VPNs). LISP is used to provide segmentation in both the LISP data plane and control plane. These VPNs can be created over the top of the Internet or over private transport networks, and can be implemented by Enterprises or Service Providers. The goal of these VPNs is to leverage the characteristics of LISP - routing scalability, simply expressed Ingress site TE Policy, IP Address Family traversal, and mobility, in ways that provide value to network operators. | ||||||||||||||||
| draft-ietf-lisp-yang-19.txt | |||||||||||||||||
| LISP YANG Model | |||||||||||||||||
|
This document describes a YANG data model to use with the Locator/ID Separation Protocol (LISP). The YANG modules in this document conform to the Network Management Datastore Architecture (NMDA). | ||||||||||||||||
| draft-ietf-lpwan-schc-compound-ack-17.txt | |||||||||||||||||
| SCHC Compound ACK | |||||||||||||||||
|
The present document updates the SCHC (Static Context Header Compression and fragmentation) protocol RFC8724 and the corresponding Yang Module RFC9363. It defines a SCHC Compound ACK message format and procedure, which are intended to reduce the number of response transmissions (i.e., SCHC ACKs) in the ACK-on-Error mode, by accumulating bitmaps of several windows in a single SCHC message (i.e., the SCHC Compound ACK). Both message format and procedure are generic, so they can be used, for instance, by any of the four Low Power Wide Area Networks (LPWANs) technologies defined in RFC8376, being Sigfox, LoRaWAN, NB- IoT and IEEE 802.15.4w. | ||||||||||||||||
| draft-ietf-lpwan-schc-over-sigfox-23.txt | |||||||||||||||||
| SCHC over Sigfox LPWAN | |||||||||||||||||
|
The Static Context Header Compression and fragmentation (SCHC) specification (RFC8724) describes a generic framework for application header compression and fragmentation modes designed for Low Power Wide Area Network (LPWAN) technologies. The present document defines a profile of SCHC over Sigfox LPWAN, and provides optimal parameter values and modes of operation. | ||||||||||||||||
| draft-ietf-lsr-algorithm-related-adjacency-sid-04.txt | |||||||||||||||||
| Algorithm Related IGP-Adjacency SID Advertisement | |||||||||||||||||
|
Segment Routing architecture supports the use of multiple routing algorithms, i.e., different constraint-based shortest-path calculations can be supported. There are two standard algorithms: SPF and Strict-SPF, defined in Segment Routing architecture. There are also other user defined algorithms according to Flex-algo applicaiton. However, an algorithm identifier is often included as part of a Prefix-SID advertisement, that maybe not satisfy some scenarios where multiple algorithm share the same link resource. This document complement that the algorithm identifier can be also included as part of a Adjacency-SID advertisement. | ||||||||||||||||
| draft-ietf-lsr-distoptflood-01.txt | |||||||||||||||||
| IS-IS Optimal Distributed Flooding for Dense Topologies | |||||||||||||||||
|
In dense topologies (such as data center fabrics based on the Clos and butterfly topologies, though not limited to those exclusively), IGP flooding mechanisms designed originally for sparse topologies can "overflood," or in other words generate too many identical copies of topology and reachability information arriving at a given node from other devices. This normally results in slower convergence times and higher resource utilization to process and discard the superfluous copies. The modifications to the flooding mechanism in the Intermediate System to Intermediate System (IS-IS) link state protocol described in this document reduce resource utilization significantly, while increaseing convergence performance in dense topologies. Beside reducing the extraneous copies it uses the dense topologies to "load-balance" flooding across different possible paths in the network to prevent build up of flooding hot-spots. Note that a Clos fabric is used as the primary example of a dense flooding topology throughout this document. However, the flooding optimizations described in this document apply to any arbitrary topology. | ||||||||||||||||
| draft-ietf-lsr-dynamic-flooding-12.txt | |||||||||||||||||
| Dynamic Flooding on Dense Graphs | |||||||||||||||||
|
Routing with link state protocols in dense network topologies can result in sub-optimal convergence times due to the overhead associated with flooding. This can be addressed by decreasing the flooding topology so that it is less dense. This document discusses the problem in some depth and an architectural solution. Specific protocol changes for IS-IS, OSPFv2, and OSPFv3 are described in this document. | ||||||||||||||||
| draft-ietf-lsr-flex-algo-bw-con-06.txt | |||||||||||||||||
| Flexible Algorithms: Bandwidth,Delay,Metrics and Constraints | |||||||||||||||||
|
Many networks configure the link metric relative to the link capacity. High bandwidth traffic gets routed as per the link capacity. Flexible algorithms provides mechanisms to create constraint based paths in IGP. This draft documents a generic metric type and set of bandwidth related constraints to be used in Flexible Algorithms. | ||||||||||||||||
| draft-ietf-lsr-flooding-topo-min-degree-06.txt | |||||||||||||||||
| Flooding Topology Minimum Degree Algorithm | |||||||||||||||||
|
This document proposes an algorithm for a node to compute a flooding topology, which is a subgraph of the complete topology per underline physical network. When every node in an area automatically calculates a flooding topology by using a same algorithm and floods the link states using the flooding topology, the amount of flooding traffic in the network is greatly reduced. This would reduce convergence time with a more stable and optimized routing environment. | ||||||||||||||||
| draft-ietf-lsr-igp-flex-algo-reverse-affinity-00.txt | |||||||||||||||||
| IGP Flexible Algorithms Reverse Affinity Constraint | |||||||||||||||||
|
An IGP Flexible Algorithm (Flex-Algorithm) allows IGPs to compute constraint-based paths. This document extends IGP Flex-Algorithm with additional constraints. | ||||||||||||||||
| draft-ietf-lsr-ip-flexalgo-08.txt | |||||||||||||||||
| IGP Flexible Algorithms (Flex-Algorithm) In IP Networks | |||||||||||||||||
|
An IGP Flexible Algorithm (Flex-Algorithm) allows IGPs to compute constraint-based paths. The base IGP Flex-Algorithm specification describes how it is used with Segment Routing (SR) data planes - SR MPLS and SRv6. This document extends IGP Flex-Algorithm, so that it can be used with regular IPv4 and IPv6 forwarding. | ||||||||||||||||
| draft-ietf-lsr-isis-area-proxy-09.txt | |||||||||||||||||
| Area Proxy for IS-IS | |||||||||||||||||
|
Link state routing protocols have hierarchical abstraction already built into them. However, when lower levels are used for transit, they must expose their internal topologies to each other, leading to scale issues. To avoid this, this document discusses extensions to the IS-IS routing protocol that would allow level 1 areas to provide transit, yet only inject an abstraction of the level 1 topology into level 2. Each level 1 area is represented as a single level 2 node, thereby enabling greater scale. | ||||||||||||||||
| draft-ietf-lsr-isis-fast-flooding-03.txt | |||||||||||||||||
| IS-IS Fast Flooding | |||||||||||||||||
|
Current Link State Protocol Data Unit (PDU) flooding rates are much slower than what modern networks can support. The use of IS-IS at larger scale requires faster flooding rates to achieve desired convergence goals. This document discusses the need for faster flooding, the issues around faster flooding, and some example approaches to achieve faster flooding. It also defines protocol extensions relevant to faster flooding. | ||||||||||||||||
| draft-ietf-lsr-isis-sr-vtn-mt-04.txt | |||||||||||||||||
| Using IS-IS Multi-Topology (MT) for Segment Routing based Virtual Transport Network | |||||||||||||||||
|
Enhanced VPN (VPN+) aims to provide enhanced VPN service to support some application's needs of enhanced isolation and stringent performance requirements. VPN+ requires integration between the overlay VPN connectivity and the characteristics provided by the underlay network. A Virtual Transport Network (VTN) is a virtual underlay network which consists of a subset of network resources allocated on network nodes and links in a customized topology of the physical network. A VTN could be used as the underlay to support one or a group of VPN+ services. In some network scenarios, each VTN can be associated with a unique logical network topology. This document describes a mechanism to build the SR based VTNs using IS-IS Multi-Topology together with other well-defined IS-IS extensions. | ||||||||||||||||
| draft-ietf-lsr-isis-srv6-yang-03.txt | |||||||||||||||||
| YANG Data Model for IS-IS SRv6 | |||||||||||||||||
|
This document defines a YANG data model that can be used to configure and manage IS-IS Segment Routing over the IPv6 Data Plane. | ||||||||||||||||
| draft-ietf-lsr-isis-ttz-07.txt | |||||||||||||||||
| IS-IS Topology-Transparent Zone | |||||||||||||||||
|
This document specifies a topology-transparent zone in an IS-IS area. A zone is a subset (block/piece) of an area, which comprises a group of routers and a number of circuits connecting them. It is abstracted as a virtual entity such as a single virtual node or zone edges mesh. Any router outside of the zone is not aware of the zone. The information about the circuits and routers inside the zone is not distributed to any router outside of the zone. | ||||||||||||||||
| draft-ietf-lsr-isis-yang-augmentation-v1-05.txt | |||||||||||||||||
| IS-IS YANG Model Augmentations for Additional Features - Version 1 | |||||||||||||||||
|
This document defines YANG data modules augmenting the IETF IS-IS YANG model to provide support for IS-IS Minimum Remaining Lifetime as defined in RFC 7987, IS-IS Application-Specific Link Attributes as defined in RFC 8919, and IS-IS Flexible Algorithm. | ||||||||||||||||
| draft-ietf-lsr-ospf-admin-tags-07.txt | |||||||||||||||||
| Extensions to OSPF for Advertising Prefix Administrative Tags | |||||||||||||||||
|
It is useful for routers in OSPFv2 and OSPFv3 routing domains to be able to associate tags with prefixes. Previously, OSPFv2 and OSPFv3 were relegated to a single tag and only for AS External and Not-So- Stubby-Area (NSSA) prefixes. With the flexible encodings provided by OSPFv2 Prefix/Link Attribute Advertisement and OSPFv3 Extended LSAs, multiple administrative tags may be advertised for all types of prefixes. These administrative tags can be used for many applications including route redistribution policy, selective prefix prioritization, selective IP Fast-ReRoute (IPFRR) prefix protection, and many others. The ISIS protocol supports a similar mechanism that is described in RFC 5130. | ||||||||||||||||
| draft-ietf-lsr-ospf-srv6-yang-03.txt | |||||||||||||||||
| YANG Data Model for OSPF SRv6 | |||||||||||||||||
|
This document defines a YANG data model that can be used to configure and manage OSPFv3 Segment Routing over the IPv6 Data Plane. | ||||||||||||||||
| draft-ietf-lsr-ospf-terminology-03.txt | |||||||||||||||||
| Update to OSPF Terminology | |||||||||||||||||
|
This document updates some OSPF terminology to be in line with inclusive language used in the industry. The IETF has designated National Institute of Standards and Technology (NIST) "Guidance for NIST Staff on Using Inclusive Language in Documentary Standards" for its inclusive language guidelines. This document updates RFC2328, RFC5340, RFC4222, RFC4811, RFC5243, RFC5614, and RFC5838. | ||||||||||||||||
| draft-ietf-lsr-ospf-transport-instance-04.txt | |||||||||||||||||
| OSPF-GT (Generalized Transport) | |||||||||||||||||
|
OSPFv2 and OSPFv3 include a reliable flooding mechanism to disseminate routing topology and Traffic Engineering (TE) information within a routing domain. Given the effectiveness of these mechanisms, it is advantageous to use the same mechanism for dissemination of other types of information within the domain. However, burdening OSPF with this additional information will impact intra-domain routing convergence and possibly jeopardize the stability of the OSPF routing domain. This document presents mechanisms to advertise this non-routing information in separate OSPF Generalized Transport (OSPF-GT) instances. OSPF-GT is not constrained to the semantics as traditional OSPF. OSPF-GT neighbors are not required to be directly attached since they are never used to compute hop-by-hop routing. Consequently, independent sparse topologies can be defined to dissemenate non- routing information only to those OSPF-GT routers requiring it. | ||||||||||||||||
| draft-ietf-lsr-ospf-yang-augmentation-v1-09.txt | |||||||||||||||||
| OSPF YANG Model Augmentations for Additional Features - Version 1 | |||||||||||||||||
|
This document defines YANG data modules augmenting the IETF OSPF YANG model to provide support for Traffic Engineering Extensions to OSPF Version 3 as defined in RF 5329, OSPF Two-Part Metric as defined in RFC 8042, OSPF Graceful Link Shutdown as defined in RFC 8379, OSPF Link-Local Signaling (LLS) Extensions for Local Interface ID Advertisement as defined in RFC 8510, OSPF MSD as defined in RFC 8476, OSPF Application-Specific Link Attributes as defined in RFC 8920, and OSPF Flexible Algorithm. | ||||||||||||||||
| draft-ietf-lsr-ospfv3-extended-lsa-yang-13.txt | |||||||||||||||||
| YANG Model for OSPFv3 Extended LSAs | |||||||||||||||||
|
This document defines a YANG data model augmenting the IETF OSPF YANG model to provide support for OSPFv3 Link State Advertisement (LSA) Extensibility as defined in RFC 8362. OSPFv3 Extended LSAs provide extensible TLV-based LSAs for the base LSA types defined in RFC 5340. | ||||||||||||||||
| draft-ietf-lsr-ospfv3-srv6-extensions-09.txt | |||||||||||||||||
| OSPFv3 Extensions for SRv6 | |||||||||||||||||
|
The Segment Routing (SR) architecture allows a flexible definition of the end-to-end path by encoding it as a sequence of topological elements called segments. It can be implemented over an MPLS or IPv6 data plane. This document describes the OSPFv3 extensions required to support Segment Routing over the IPv6 data plane (SRv6). | ||||||||||||||||
| draft-ietf-lsr-rfc8919bis-00.txt | |||||||||||||||||
| IS-IS Application-Specific Link Attributes | |||||||||||||||||
|
Existing traffic-engineering-related link attribute advertisements have been defined and are used in RSVP-TE deployments. Since the original RSVP-TE use case was defined, additional applications (e.g., Segment Routing Policy and Loop-Free Alternates) that also make use of the link attribute advertisements have been defined. In cases where multiple applications wish to make use of these link attributes, the current advertisements do not support application- specific values for a given attribute, nor do they support indication of which applications are using the advertised value for a given link. This document introduces new link attribute advertisements that address both of these shortcomings. This document obsoletes RFC 8919. | ||||||||||||||||
| draft-ietf-lsr-rfc8920bis-01.txt | |||||||||||||||||
| OSPF Application-Specific Link Attributes | |||||||||||||||||
|
Existing traffic-engineering-related link attribute advertisements have been defined and are used in RSVP-TE deployments. Since the original RSVP-TE use case was defined, additional applications (e.g., Segment Routing Policy and Loop-Free Alternates) that also make use of the link attribute advertisements have been defined. In cases where multiple applications wish to make use of these link attributes, the current advertisements do not support application- specific values for a given attribute, nor do they support indication of which applications are using the advertised value for a given link. This document introduces new link attribute advertisements in OSPFv2 and OSPFv3 that address both of these shortcomings. This document obsoletes RFC 8920. | ||||||||||||||||
| draft-ietf-lsvr-applicability-09.txt | |||||||||||||||||
| Usage and Applicability of Link State Vector Routing in Data Centers | |||||||||||||||||
|
This document discusses the usage and applicability of Link State Vector Routing (LSVR) extensions in data center networks utilizing CLOS or Fat-Tree topologies. The document is intended to provide a simplified guide for the deployment of LSVR extensions. | ||||||||||||||||
| draft-ietf-lsvr-bgp-ls-yang-01.txt | |||||||||||||||||
| A YANG Model for BGP-LS,BGP-LS-VPN,and BGP-LS-SPF | |||||||||||||||||
|
This document defines a YANG data model for configuration and management of BGP-LS, BGP-LS-VPN, and BGP-LS-SPF. | ||||||||||||||||
| draft-ietf-lsvr-bgp-spf-22.txt | |||||||||||||||||
| BGP Link-State Shortest Path First (SPF) Routing | |||||||||||||||||
|
Many Massively Scaled Data Centers (MSDCs) have converged on simplified layer 3 routing. Furthermore, requirements for operational simplicity have led many of these MSDCs to converge on BGP as their single routing protocol for both their fabric routing and their Data Center Interconnect (DCI) routing. This document describes extensions to BGP to use BGP Link-State distribution and the Shortest Path First (SPF) algorithm. In doing this, it allows BGP to be efficiently used as both the underlay protocol and the overlay protocol in MSDCs. | ||||||||||||||||
| draft-ietf-lwig-curve-representations-23.txt | |||||||||||||||||
| Alternative Elliptic Curve Representations | |||||||||||||||||
|
This document specifies how to represent Montgomery curves and (twisted) Edwards curves as curves in short-Weierstrass form and illustrates how this can be used to carry out elliptic curve computations leveraging existing implementations and specifications of, e.g., ECDSA and ECDH using NIST prime curves. We also provide extensive background material that may be useful for implementers of elliptic curve cryptography. | ||||||||||||||||
| draft-ietf-madinas-mac-address-randomization-06.txt | |||||||||||||||||
| Randomized and Changing MAC Address | |||||||||||||||||
|
Internet privacy has become a major concern over the past few years. Users are becoming more aware that their online activity leaves a vast digital footprint, that communications are not always properly secured, and that their location and actions can be easily tracked. One of the main factors for the location tracking issue is the wide use of long-lasting identifiers, such as MAC addresses. There have been several initiatives at the IETF and the IEEE 802 standards committees to overcome some of these privacy issues. This document provides an overview of these activities, with the intention to inform the technical community about them, and help coordinate between present and future standardization activities. | ||||||||||||||||
| draft-ietf-madinas-use-cases-05.txt | |||||||||||||||||
| Randomized and Changing MAC Address Use Cases and Requirements | |||||||||||||||||
|
To limit the privacy and security issues created by the association between a device, its traffic, its location and its user, client vendors have started implementing MAC address rotation. When such rotation happens, some in-network states may break, which may affect network efficiency and the user experience. At the same time, devices may continue sending other stable identifiers, defeating the MAC rotation purposes. This document lists various network environments and a set of functional network services that may be affected by such rotation. This document then examines settings where the user experience may be affected by in-network state disruption, and settings where other machine identifiers may help re- identify the user or recover the identity of the user, and locate the device and its associated user. Last, this document examines solutions to maintain user privacy while preserving user quality of experience and network operation efficiency. | ||||||||||||||||
| draft-ietf-masque-connect-ip-11.txt | |||||||||||||||||
| Proxying IP in HTTP | |||||||||||||||||
|
This document describes how to proxy IP packets in HTTP. This protocol is similar to UDP proxying in HTTP, but allows transmitting arbitrary IP packets. More specifically, this document defines a protocol that allows an HTTP client to create an IP tunnel through an HTTP server that acts as an IP proxy. This document updates RFC 9298. | ||||||||||||||||
| draft-ietf-mboned-multicast-telemetry-06.txt | |||||||||||||||||
| Multicast On-path Telemetry using IOAM | |||||||||||||||||
|
This document specifies the requirements of on-path telemetry for multicast traffic using In-situ OAM. While In-situ OAM is advantageous for multicast traffic telemetry, applying it presents some unique challenges. This document provides the solutions based on the In-situ OAM trace option and direct export option to support the telemetry data correlation and the multicast tree reconstruction without incurring data redundancy. | ||||||||||||||||
| draft-ietf-mboned-multicast-yang-model-08.txt | |||||||||||||||||
| Multicast YANG Data Model | |||||||||||||||||
|
This document provides a general multicast YANG data model, which takes full advantages of existed multicast protocol models to control the multicast network, and guides the deployment of multicast service. | ||||||||||||||||
| draft-ietf-mboned-redundant-ingress-failover-02.txt | |||||||||||||||||
| Multicast Redundant Ingress Router Failover | |||||||||||||||||
|
This document discusses multicast redundant ingress router failover issues, include global multicast and Service Provider Network MVPN use case. This document analyzes specification of global multicast and Multicast VPN Fast Upstream Failover and the Ingress PE Standby Modes and the benefits of each mode. | ||||||||||||||||
| draft-ietf-mediaman-haptics-03.txt | |||||||||||||||||
| The 'haptics' Top-level Media Type | |||||||||||||||||
|
This memo serves to register and document the 'haptics' top-level media type, under which subtypes for representation formats for haptics may be registered. This document also serves as a registration application for a set of intended subtypes, which are representative of some existing subtypes already in use. | ||||||||||||||||
| draft-ietf-mediaman-suffixes-03.txt | |||||||||||||||||
| Media Types with Multiple Suffixes | |||||||||||||||||
|
This document updates RFC 6838 "Media Type Specifications and Registration Procedures" to describe how to interpret subtypes with multiple suffixes. | ||||||||||||||||
| draft-ietf-mediaman-toplevel-03.txt | |||||||||||||||||
| Guidelines for the Definition of New Top-Level Media Types | |||||||||||||||||
|
This document defines best practices for defining new top-level media types. It also introduces a registry for top-level media types, and contains a short history of top-level media types. It updates RFC 6838. [RFC Editor, please remove this paragraph.] Comments and discussion about this document should be directed to media-types@ietf.org, the mailing list of the Media Type Maintenance (mediaman) WG. Alternatively, issues can be raised on github at https://github.com/ ietf-wg-mediaman/toplevel. | ||||||||||||||||
| draft-ietf-mls-architecture-10.txt | |||||||||||||||||
| The Messaging Layer Security (MLS) Architecture | |||||||||||||||||
|
The Messaging Layer Security (MLS) protocol (I-D.ietf-mls-protocol) specification has the role of defining a Group Key Agreement protocol, including all the cryptographic operations and serialization/deserialization functions necessary for scalable and secure group messaging. The MLS protocol is meant to protect against eavesdropping, tampering, message forgery, and provide further properties such as Forward Secrecy (FS) and Post-Compromise Security (PCS) in the case of past or future device compromises. This document describes a general secure group messaging infrastructure and its security goals. It provides guidance on building a group messaging system and discusses security and privacy tradeoffs offered by multiple security mechanisms that are part of the MLS protocol (e.g., frequency of public encryption key rotation). The document also provides guidance for parts of the infrastructure that are not standardized by the MLS Protocol document and left to the application or the infrastructure architects to design. While the recommendations of this document are not mandatory to follow in order to interoperate at the protocol level, they affect the overall security guarantees that are achieved by a messaging application. This is especially true in case of active adversaries that are able to compromise clients, the delivery service, or the authentication service. | ||||||||||||||||
| draft-ietf-mls-extensions-01.txt | |||||||||||||||||
| The Messaging Layer Security (MLS) Extensions | |||||||||||||||||
|
This document describes extensions to the Messaging Layer Security (MLS) protocol. Discussion Venues This note is to be removed before publishing as an RFC. Source for this draft and an issue tracker can be found at https://github.com/mlswg/mls-extensions. | ||||||||||||||||
| draft-ietf-mls-federation-02.txt | |||||||||||||||||
| The Messaging Layer Security (MLS) Federation | |||||||||||||||||
|
This document describes how the Messaging Layer Security (MLS) protocol can be used in a federated environment. Discussion Venues This note is to be removed before publishing as an RFC. Source for this draft and an issue tracker can be found at https://github.com/mlswg/mls-federation. | ||||||||||||||||
| draft-ietf-mls-protocol-20.txt | |||||||||||||||||
| The Messaging Layer Security (MLS) Protocol | |||||||||||||||||
|
Messaging applications are increasingly making use of end-to-end security mechanisms to ensure that messages are only accessible to the communicating endpoints, and not to any servers involved in delivering messages. Establishing keys to provide such protections is challenging for group chat settings, in which more than two clients need to agree on a key but may not be online at the same time. In this document, we specify a key establishment protocol that provides efficient asynchronous group key establishment with forward secrecy and post-compromise security for groups in size ranging from two to thousands. | ||||||||||||||||
| draft-ietf-mops-ar-use-case-10.txt | |||||||||||||||||
| Media Operations Use Case for an Extended Reality Application on Edge Computing Infrastructure | |||||||||||||||||
|
This document explores the issues involved in the use of Edge Computing resources to operationalize media use cases that involve Extended Reality (XR) applications. In particular, we discuss those applications that run on devices having different form factors and need Edge computing resources to mitigate the effect of problems such as a need to support interactive communication requiring low latency, limited battery power, and heat dissipation from those devices. The intended audience for this document are network operators who are interested in providing edge computing resources to operationalize the requirements of such applications. We discuss the expected behavior of XR applications which can be used to manage the traffic. In addition, we discuss the service requirements of XR applications to be able to run on the network. | ||||||||||||||||
| draft-ietf-mops-treedn-00.txt | |||||||||||||||||
| TreeDN- Tree-based CDNs for Live Streaming to Mass Audiences | |||||||||||||||||
|
As Internet audience sizes for high-interest live events reach unprecedented levels and bitrates climb to support 4K/8K/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 weren't possible or economically viable using traditional CDN approaches. Finally, TreeDN is a decentralized architecture and a democratizing technology for content distribution. | ||||||||||||||||
| draft-ietf-mpls-1stnibble-00.txt | |||||||||||||||||
| IANA Registry for the First Nibble Following a Label Stack | |||||||||||||||||
|
The goal of this memo is to create a new IANA registry (called the MPLS First Nibble registry) for the first nibble (4-bit field) immediately following an MPLS label stack. The memo offers a rationale for such a registry, describes how the registry should be managed, and provides some initial entries. Furthermore, this memo sets out some documentation requirements for registering new values. Finally, it provides some recommendations that makes processing MPLS packets easier and more robust. There is an important caveat on the use of this registry versus the IP version number registry. This memo, if published, would update [RFC4928] and [RFC8469]. | ||||||||||||||||
| draft-ietf-mpls-bfd-directed-22.txt | |||||||||||||||||
| Bidirectional Forwarding Detection (BFD) Directed Return Path for MPLS Label Switched Paths (LSPs) | |||||||||||||||||
|
Bidirectional Forwarding Detection (BFD) is expected to be able to monitor a wide variety of encapsulations of paths between systems. When a BFD session monitors an explicitly routed unidirectional path there may be a need to direct egress BFD peer to use a specific path for the reverse direction of the BFD session. This document describes an extension to MPLS LSP echo request that allows a BFD system request that the remote BFD peer transmits BFD control packets over the specified LSP. | ||||||||||||||||
| draft-ietf-mpls-egress-tlv-for-nil-fec-06.txt | |||||||||||||||||
| Egress TLV for Nil FEC in Label Switched Path Ping and Traceroute Mechanisms | |||||||||||||||||
|
MPLS ping and traceroute mechanism as described in RFC 8029 and related extensions for SR as defined in RFC 8287 is very useful to precisely validate the control plane and data plane synchronization. There is a possibility that all intermediate or transit nodes may not have been upgraded to support these validation procedures. A simple mpls ping and traceroute mechanism comprises of ability to traverse any path without having to validate the control plane state. RFC 8029 supports this mechanism with Nil FEC. The procedures described in RFC 8029 are mostly applicable when the Nil FEC is used as intermediate FEC in the label stack. When all labels in label stack are represented using single Nil FEC, it poses some challenges. This document introduces new TLV as additional extension to exisiting Nil FEC and describes mpls ping and traceroute procedures using Nil FEC with this additional extensions to overcome these challenges. | ||||||||||||||||
| draft-ietf-mpls-inband-pm-encapsulation-05.txt | |||||||||||||||||
| Encapsulation For MPLS Performance Measurement with Alternate Marking Method | |||||||||||||||||
|
This document defines the encapsulation for MPLS performance measurement with alternate marking method, which performs flow-based packet loss, delay, and jitter measurements on MPLS live traffic. | ||||||||||||||||
| draft-ietf-mpls-lspping-norao-01.txt | |||||||||||||||||
| Deprecating the Use of Router Alert in LSP Ping | |||||||||||||||||
|
LSP ping messages (RFC 8029) are encapsulated in IP headers that include a Router Alert Option (RAO). The rationale for including an RAO is questionable. Furthermore, RFC6398 identifies security vulnerabilities associated with the RAO. Therefore, this document removes the RAO from LSP ping message encapsulations. It updates RFCs 7506 and 8029. This document also recommends the use of an IPv6 loopback address (:::1/128) and discourages the use of an IPv4 loopback address mapped to IPv6. | ||||||||||||||||
| draft-ietf-mpls-mldp-multi-topology-02.txt | |||||||||||||||||
| mLDP Extensions for Multi-Topology Routing | |||||||||||||||||
|
Multi-Topology Routing (MTR) is a technology to enable service differentiation within an IP network. Flexible Algorithm (FA) is another mechanism of creating a sub-topology within a topology using defined topology constraints and computation algorithm. In order to deploy mLDP in a network that supports MTR and/or FA, mLDP is required to become topology and FA aware. This document specifies extensions to mLDP to support MTR with FA such that when building a Multi-Point LSPs it can follow a particular topology and algorithm. | ||||||||||||||||
| draft-ietf-mpls-mna-fwk-03.txt | |||||||||||||||||
| MPLS Network Actions Framework | |||||||||||||||||
|
This document specifies an architectural framework for the MPLS Network Actions (MNA) technologies. MNA technologies are used to indicate actions for Label Switched Paths (LSPs) and/or MPLS packets and to transfer data needed for these actions. The document describes a common set of network actions and information elements supporting additional operational models and capabilities of MPLS networks. Some of these actions are defined in existing MPLS specifications, while others require extensions to existing specifications to meet the requirements found in "Requirements for MPLS Network Action Indicators and Ancillary Data". | ||||||||||||||||
| draft-ietf-mpls-mna-hdr-02.txt | |||||||||||||||||
| MPLS Network Action (MNA) Sub-Stack Solution | |||||||||||||||||
|
This document defines the MPLS Network Action (MNA) sub-stack solution for carrying Network Actions and Ancillary Data in the label stack. MPLS Network Actions can be used to influence packet forwarding decisions, carry additional OAM information in the MPLS packet, or perform user-defined operations. This document addresses the MNA requirements specified in draft-ietf-mpls-mna-requirements. This document follows the MNA framework specified in draft-ietf-mpls- mna-fwk. | ||||||||||||||||
| draft-ietf-mpls-mna-requirements-05.txt | |||||||||||||||||
| Requirements for MPLS Network Actions | |||||||||||||||||
|
This document specifies requirements for MPLS network actions which affect the forwarding or other processing of MPLS packets. These requirements are derived from a number of proposals for additions to the MPLS label stack to allow forwarding or other processing decisions to be made, either by a transit or terminating LSR (i.e. the LER). | ||||||||||||||||
| draft-ietf-mpls-mna-usecases-02.txt | |||||||||||||||||
| Use Cases for MPLS Network Action Indicators and MPLS Ancillary Data | |||||||||||||||||
|
This document presents a number of use cases that have a common need for encoding network action indicators and associated ancillary data inside MPLS packets. There has been significant recent interest in extending the MPLS data plane to carry such indicators and ancillary data to address a number of use cases that are described in this document. The use cases described in this document are not an exhaustive set, but rather the ones that are actively discussed by members of the IETF MPLS, PALS and DETNET working groups participating in the MPLS Open Design Team. | ||||||||||||||||
| draft-ietf-mpls-msd-yang-00.txt | |||||||||||||||||
| A YANG Model for MPLS MSD | |||||||||||||||||
|
This document defines a YANG data module augmenting the IETF MPLS YANG model to provide support for MPLS Maximum SID Depths (MSDs) as defined in RFC 8476 and RFC 8491. | ||||||||||||||||
| draft-ietf-mpls-p2mp-bfd-04.txt | |||||||||||||||||
| BFD for Multipoint Networks over Point-to-Multi-Point MPLS LSP | |||||||||||||||||
|
This document describes procedures for using Bidirectional Forwarding Detection (BFD) for multipoint networks to detect data plane failures in Multiprotocol Label Switching (MPLS) point-to-multipoint (p2mp) Label Switched Paths (LSPs) and Segment Routing (SR) point-to- multipoint policies with SR-MPLS data plane. Furthermore, this document also proposes an update to RFC 8562 and recommends the use of an IPv6 loopback address (:::1/128) and discourages the use of an IPv4 loopback address mapped to IPv6. It also describes the applicability of LSP Ping, as in-band, and the control plane, as out-band, solutions to bootstrap a BFD session. It also describes the behavior of the active tail for head notification. | ||||||||||||||||
| draft-ietf-mpls-rfc6374-sfl-10.txt | |||||||||||||||||
| RFC6374 Synonymous Flow Labels | |||||||||||||||||
|
RFC 6374 describes methods of making loss and delay measurements on Label Switched Paths (LSPs) primarily as used in MPLS Transport Profile (MPLS-TP) networks. This document describes a method of extending RFC 6374 performance measurements from flows carried over MPLS-TP to flows carried over generic MPLS LSPs. In particular, it extends the technique to allow loss and delay measurements to be made on multi-point to point LSPs and introduces some additional techniques to allow more sophisticated measurements to be made in both MPLS-TP and generic MPLS networks. | ||||||||||||||||
| draft-ietf-mpls-rfc6374-sr-07.txt | |||||||||||||||||
| Performance Measurement Using RFC 6374 for Segment Routing Networks with MPLS Data Plane | |||||||||||||||||
|
Segment Routing (SR) leverages the source routing paradigm. RFC 6374 specifies protocol mechanisms to enable the efficient and accurate measurement of packet loss, one-way and two-way delay, as well as related metrics such as delay variation in MPLS networks. This document utilizes these mechanisms for Performance Delay and Loss Measurements in SR networks with MPLS data plane (SR-MPLS), for both SR-MPLS links and end-to-end SR-MPLS paths including Policies. In addition, this document defines Return Path TLV and Block Number TLV extensions for RFC 6374. | ||||||||||||||||
| draft-ietf-mpls-ri-rsvp-frr-14.txt | |||||||||||||||||
| Refresh-interval Independent FRR Facility Protection | |||||||||||||||||
|
RSVP-TE Fast ReRoute extensions specified in RFC 4090 defines two local repair techniques to reroute Label Switched Path (LSP) traffic over pre-established backup tunnel. Facility backup method allows one or more LSPs traversing a connected link or node to be protected using a bypass tunnel. The many-to-one nature of local repair technique is attractive from scalability point of view. This document enumerates facility backup procedures in RFC 4090 that rely on refresh timeout and hence make facility backup method refresh- interval dependent. The RSVP-TE extensions defined in this document will enhance the facility backup protection mechanism by making the corresponding procedures refresh-interval independent and hence compatible with Refresh-interval Independent RSVP (RI-RSVP) specified in RFC 8370. Hence, this document updates RFC 4090 in order to support RI-RSVP capability specified in RFC 8370. | ||||||||||||||||
| draft-ietf-mpls-sfl-control-03.txt | |||||||||||||||||
| A Simple Control Protocol for MPLS SFLs | |||||||||||||||||
|
In RFC 8957 the concept of MPLS synonymos flow labels (SFL) was introduced. This document describes a simple control protocol that runs over an associated control header to request, withdraw, and extend the lifetime of such labels. It is not the only control protocol that might be used to support SFL, but it has the benefit of being able to be used without modifying of the existing MPLS control protocols. The existence of this design is not intended to restrict the ability to enhance an existing MPLS control protocol to add a similar capability. A Querier MUST wait a configured time (suggested wait of 60 seconds) before re-attempting a Withdraw request. No more than three Withdraw requests SHOULD be made. These restrictions are to prevent overloading the control plane of the actioning router. | ||||||||||||||||
| draft-ietf-mpls-spring-inter-domain-oam-04.txt | |||||||||||||||||
| PMS/Head-end based MPLS Ping and Traceroute in Inter-domain SR Networks | |||||||||||||||||
|
Segment Routing (SR) architecture leverages source routing and tunneling paradigms and can be directly applied to the use of a Multiprotocol Label Switching (MPLS) data plane. A network may consist of multiple IGP domains or multiple ASes under the control of same organization. It is useful to have the Label switched Path (LSP) Ping and traceroute procedures when an SR end-to-end path spans across multiple ASes or domains. This document describes mechanisms to facilitae LSP ping and traceroute in inter-AS/inter-domain SR-MPLS networks in an efficient manner with simple Operations, Administration, and Maintenance (OAM) protocol extension which uses dataplane forwarding alone for sending echo reply. | ||||||||||||||||
| draft-ietf-mpls-sr-epe-oam-08.txt | |||||||||||||||||
| Label Switched Path (LSP) Ping/Traceroute for Segment Routing (SR) Egress Peer Engineering Segment Identifiers (SIDs) with MPLS Data Planes | |||||||||||||||||
|
Egress Peer Engineering (EPE) is an application of Segment Routing to solve the problem of egress peer selection. The Segment Routing based BGP-EPE solution allows a centralized controller, e.g. a Software Defined Network (SDN) controller to program any egress peer. The EPE solution requires a node to program the PeerNode Segment Identifier(SID) describing a session between two nodes, the PeerAdj SID describing the link (one or more) that is used by sessions between peer nodes, and the PeerSet SID describing an arbitrary set of sessions or links between a local node and its peers. This document provides new sub-TLVs for EPE Segment Identifiers (SID) that would be used in the MPLS Target stack TLV (Type 1), in MPLS Ping and Traceroute procedures. | ||||||||||||||||
| draft-ietf-netconf-adaptive-subscription-02.txt | |||||||||||||||||
| Adaptive Subscription to YANG Notification | |||||||||||||||||
|
This document defines a YANG data model and associated mechanism that enable adaptive subscription to a publisher's event streams. The periodic update interval for the event streams can be set. Applying these elements allows servers to automatically adjust the rate and volume of telemetry traffic sent from a publisher to receivers. | ||||||||||||||||
| draft-ietf-netconf-crypto-types-27.txt | |||||||||||||||||
| YANG Data Types and Groupings for Cryptography | |||||||||||||||||
|
This document presents a YANG 1.1 (RFC 7950) module defining identities, typedefs, and groupings useful to cryptographic applications. | ||||||||||||||||
| draft-ietf-netconf-distributed-notif-06.txt | |||||||||||||||||
| Subscription to Distributed Notifications | |||||||||||||||||
|
This document describes extensions to the YANG notifications subscription to allow metrics being published directly from processors on line cards to target receivers, while subscription is still maintained at the route processor in a distributed forwarding system. | ||||||||||||||||
| draft-ietf-netconf-http-client-server-13.txt | |||||||||||||||||
| YANG Groupings for HTTP 1.1/2.0 Clients and HTTP Servers | |||||||||||||||||
|
This document defines 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). 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 * DDDD --> the assigned RFC value for draft-ietf-netconf-tcp-client- server * FFFF --> the assigned RFC value for draft-ietf-netconf-tls-client- server * GGGG --> 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: * 2023-04-17 --> 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 Informative Reference in the Appendix. The following Appendix section is to be removed prior to publication: * Appendix A. Change Log | ||||||||||||||||
| draft-ietf-netconf-https-notif-13.txt | |||||||||||||||||
| An HTTPS-based Transport for YANG Notifications | |||||||||||||||||
|
This document defines a protocol for sending notifications over HTTPS. YANG modules for configuring publishers are also defined. Examples are provided illustrating how to configure various publishers. This document requires that the publisher is a "server" (e.g., a NETCONF or RESTCONF server), but does not assume that the receiver is a server. | ||||||||||||||||
| draft-ietf-netconf-keystore-28.txt | |||||||||||||||||
| A YANG Data Model for a Keystore | |||||||||||||||||
|
This document defines a YANG module called "ietf-keystore" that enables centralized configuration of both symmetric and asymmetric keys. The secret value for both key types may be encrypted or hidden. Asymmetric keys may be associated with certificates. Notifications are sent when certificates are about to expire. | ||||||||||||||||
| draft-ietf-netconf-list-pagination-01.txt | |||||||||||||||||
| List Pagination for YANG-driven Protocols | |||||||||||||||||
|
In some circumstances, instances of YANG modeled "list" and "leaf- list" nodes may contain numerous entries. Retrieval of all the entries can lead to inefficiencies in the server, the client, and the network in between. This document defines a model for list pagination that can be implemented by YANG-driven management protocols such as NETCONF and RESTCONF. The model supports paging over optionally filtered and/or sorted entries. The solution additionally enables servers to constrain query expressions on some "config false" lists or leaf- lists. | ||||||||||||||||
| draft-ietf-netconf-list-pagination-nc-01.txt | |||||||||||||||||
| NETCONF Extensions to Support List Pagination | |||||||||||||||||
|
This document defines a mapping of the list pagination mechanism defined in [I-D.ietf-netconf-list-pagination] to NETCONF [RFC6241]. This document updates [RFC6241], to augment the | ||||||||||||||||
| draft-ietf-netconf-list-pagination-rc-01.txt | |||||||||||||||||
| RESTCONF Extensions to Support List Pagination | |||||||||||||||||
|
This document defines a mapping of the list pagination mechanism defined in [I-D.ietf-netconf-list-pagination] to RESTCONF [RFC8040]. This document updates RFC 8040, to declare "list" and "leaf-list" as valid resource targets for the RESTCONF GET and DELETE operations, to define GET query parameters necessary for list pagination, and to define a media-type for XML-based lists. | ||||||||||||||||
| draft-ietf-netconf-netconf-client-server-29.txt | |||||||||||||||||
| NETCONF Client and Server Models | |||||||||||||||||
|
This document defines 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: * 2023-04-17 --> 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 Informative Reference in the Appendix. The following Appendix section is to be removed prior to publication: * Appendix A. Change Log | ||||||||||||||||
| draft-ietf-netconf-over-tls13-02.txt | |||||||||||||||||
| Updates to Using the NETCONF Protocol over Transport Layer Security (TLS) with Mutual X.509 Authentication | |||||||||||||||||
|
RFC 7589 defines how to protect NETCONF messages with TLS 1.2. This document updates RFC 7589 to address support requirements for TLS 1.2 and TLS 1.3 and the use of TLS 1.3's early data. | ||||||||||||||||
| draft-ietf-netconf-restconf-client-server-29.txt | |||||||||||||||||
| RESTCONF Client and Server Models | |||||||||||||||||
|
This document defines 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: * 2023-04-17 --> 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 Informative Reference in the Appendix. The following Appendix section is to be removed prior to publication: * Appendix A. Change Log | ||||||||||||||||
| draft-ietf-netconf-ssh-client-server-33.txt | |||||||||||||||||
| YANG Groupings for SSH Clients and SSH Servers | |||||||||||||||||
|
This document defines three YANG 1.1 modules: the first defines features and groupings common to both SSH clients and SSH servers, the second defines a grouping for a generic SSH client, and the third defines a grouping for a generic SSH server. 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: * 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 this draft Artwork in this document contains placeholder values for the date of publication of this draft. Please apply the following replacement: * 2023-04-17 --> 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 Informative Reference in the Appendix. The following Appendix section is to be removed prior to publication: * Appendix B. Change Log | ||||||||||||||||
| draft-ietf-netconf-sztp-csr-14.txt | |||||||||||||||||
| Conveying a Certificate Signing Request (CSR) in a Secure Zero Touch Provisioning (SZTP) Bootstrapping Request | |||||||||||||||||
|
This draft extends the input to the "get-bootstrapping-data" RPC defined in RFC 8572 to include an optional certificate signing request (CSR), enabling a bootstrapping device to additionally obtain an identity certificate (e.g., an LDevID from IEEE 802.1AR) as part of the "onboarding information" response provided in the RPC-reply. | ||||||||||||||||
| draft-ietf-netconf-tcp-client-server-16.txt | |||||||||||||||||
| YANG Groupings for TCP Clients and TCP Servers | |||||||||||||||||
|
This document defines three YANG 1.1 modules to support the configuration of TCP clients and TCP servers. The modules include basic parameters of a TCP connection relevant for client or server applications, as well as client configuration required for traversing proxies. The modules can be used either standalone or in conjunction with configuration of other stack protocol layers. | ||||||||||||||||
| draft-ietf-netconf-tls-client-server-33.txt | |||||||||||||||||
| YANG Groupings for TLS Clients and TLS Servers | |||||||||||||||||
|
This document defines three YANG 1.1 modules: the first defines features and groupings common to both TLS clients and TLS servers, the second defines a grouping for a generic TLS client, and the third defines a grouping for a generic TLS server. 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: * 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 * FFFF --> 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: * 2023-04-17 --> 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 Informative Reference in the Appendix. The following Appendix section is to be removed prior to publication: * Appendix B. Change Log | ||||||||||||||||
| draft-ietf-netconf-transaction-id-00.txt | |||||||||||||||||
| Transaction ID Mechanism for NETCONF | |||||||||||||||||
|
NETCONF clients and servers often need to have a synchronized view of the server's configuration data stores. The volume of configuration data in a server may be very large, while data store changes typically are small when observed at typical client resynchronization intervals. Rereading the entire data store and analyzing the response for changes is an inefficient mechanism for synchronization. This document specifies an extension to NETCONF that allows clients and servers to keep synchronized with a much smaller data exchange and without any need for servers to store information about the clients. | ||||||||||||||||
| draft-ietf-netconf-trust-anchors-21.txt | |||||||||||||||||
| A YANG Data Model for a Truststore | |||||||||||||||||
|
This document defines a YANG module for configuring bags of certificates and bags of public keys that can be referenced by other data models for trust. Notifications are sent when certificates are about to expire. | ||||||||||||||||
| draft-ietf-netconf-udp-notif-09.txt | |||||||||||||||||
| UDP-based Transport for Configured Subscriptions | |||||||||||||||||
|
This document describes an UDP-based notification mechanism to collect data from networking devices. A shim header is proposed to facilitate the data streaming directly from the publishing process on network processor of line cards to receivers. The objective is to provide a lightweight approach to enable higher frequency and less performance impact on publisher and receiver processes compared to already established notification mechanisms. | ||||||||||||||||
| draft-ietf-netmod-acl-extensions-01.txt | |||||||||||||||||
| Extensions to the Access Control Lists (ACLs) YANG Model | |||||||||||||||||
|
RFC 8519 defines a YANG data model for Access Control Lists (ACLs). This document discusses a set of extensions that fix many of the limitations of the ACL model as initially defined in RFC 8519. The document also defines an IANA-maintained module for ICMP types. | ||||||||||||||||
| draft-ietf-netmod-intf-ext-yang-11.txt | |||||||||||||||||
| Common Interface Extension YANG Data Models | |||||||||||||||||
|
This document defines two YANG modules that augment the Interfaces data model defined in the "YANG Data Model for Interface Management" with additional configuration and operational data nodes to support common lower layer interface properties, such as interface MTU. The YANG modules in this document conform to the Network Management Datastore Architecture (NMDA) defined in RFC 8342. | ||||||||||||||||
| draft-ietf-netmod-rfc6991-bis-15.txt | |||||||||||||||||
| Common YANG Data Types | |||||||||||||||||
|
This document defines a collection of common data types to be used with the YANG data modeling language. This version of the document adds several new type definitions and obsoletes RFC 6991. | ||||||||||||||||
| draft-ietf-netmod-sub-intf-vlan-model-08.txt | |||||||||||||||||
| Sub-interface VLAN YANG Data Models | |||||||||||||||||
|
This document defines YANG modules to add support for classifying traffic received on interfaces as Ethernet/VLAN framed packets to sub-interfaces based on the fields available in the Ethernet/VLAN frame headers. These modules allow configuration of Layer 3 and Layer 2 sub-interfaces (e.g. L2VPN attachment circuits) that can interoperate with IETF based forwarding protocols; such as IP and L3VPN services; or L2VPN services like VPWS, VPLS, and EVPN. The sub-interfaces also interoperate with VLAN tagged traffic orignating from an IEEE 802.1Q compliant bridge. The model differs from an IEEE 802.1Q bridge model in that the configuration is interface/sub-interface based as opposed to being based on membership of an 802.1Q VLAN bridge. The YANG data models in this document conforms to the Network Management Datastore Architecture (NMDA) defined in RFC 8342. | ||||||||||||||||
| draft-ietf-netmod-syslog-model-30.txt | |||||||||||||||||
| A YANG Data Model for Syslog Configuration | |||||||||||||||||
|
This document defines a YANG data model for the configuration of a syslog process. It is intended this model be used by vendors who implement syslog in their systems. | ||||||||||||||||
| draft-ietf-netmod-system-config-01.txt | |||||||||||||||||
| System-defined Configuration | |||||||||||||||||
|
This document updates Network Management Datastore Architecture (NMDA) to define a read-only conventional configuration datastore called "system" to hold system-defined configurations. To avoid clients' explicit copy/paste of referenced system-defined configuration into the target configuration datastore (e.g., | ||||||||||||||||
| draft-ietf-netmod-yang-module-versioning-09.txt | |||||||||||||||||
| Updated YANG Module Revision Handling | |||||||||||||||||
|
This document specifies a new YANG module update procedure that can document when non-backwards-compatible changes have occurred during the evolution of a YANG module. It extends the YANG import statement with a minimum revision suggestion to help document inter-module dependencies. It provides guidelines for managing the lifecycle of YANG modules and individual schema nodes. It provides a mechanism, via the revision label YANG extension, to specify a revision identifier for YANG modules and submodules. This document updates RFC 7950, RFC 6020, RFC 8407 and RFC 8525. | ||||||||||||||||
| draft-ietf-netmod-yang-schema-comparison-02.txt | |||||||||||||||||
| YANG Schema Comparison | |||||||||||||||||
|
This document specifies an algorithm for comparing two revisions of a YANG schema to determine the scope of changes, and a list of changes, between the revisions. The output of the algorithm can be used to help select an appropriate revision-label or YANG semantic version number for a new revision. This document defines a YANG extension that provides YANG annotations to help the tool accurately determine the scope of changes between two revisions. | ||||||||||||||||
| draft-ietf-netmod-yang-semver-11.txt | |||||||||||||||||
| YANG Semantic Versioning | |||||||||||||||||
|
This document specifies a scheme and guidelines for applying an extended set of semantic versioning rules to revisions of YANG artifacts (e.g., modules and packages). Additionally, this document defines an RFCAAAA-compliant revision-label-scheme for this YANG semantic versioning scheme. | ||||||||||||||||
| draft-ietf-nfsv4-delstid-02.txt | |||||||||||||||||
| Extending the Opening of Files in NFSv4.2 | |||||||||||||||||
|
The Network File System v4 (NFSv4) allows a client to both open a file and be granted a delegation of that file. This provides the client the right to cache metadata on the file locally. This document presents several refinements to RFC8881 for both the opening and delegating of the file to the client. | ||||||||||||||||
| draft-ietf-nfsv4-internationalization-04.txt | |||||||||||||||||
| Internationalization for the NFSv4 Protocols | |||||||||||||||||
|
This document describes the handling of internationalization for all NFSv4 protocols, including NFSv4.0, NFSv4.1, NFSv4.2 and extensions thereof, and future minor versions. It updates RFC7530 and RFC8881. | ||||||||||||||||
| draft-ietf-nfsv4-layoutwcc-01.txt | |||||||||||||||||
| Add LAYOUT_WCC to NFSv4.2's Flex File Layout Type | |||||||||||||||||
|
The Parallel Network File System (pNFS) Flexible File Layout allows for a file's metadata (MDS) and data (DS) to be on different servers. It does not provide a mechanism for the data server to update the metadata server of changes to the data part of the file. The client has knowledge of such updates, but lacks the ability to update the metadata server. This document presents a refinement to RFC8435 to allow the client to update the metadata server to changes on the data server. | ||||||||||||||||
| draft-ietf-nfsv4-rfc5661bis-00.txt | |||||||||||||||||
| Network File System (NFS) Version 4 Minor Version 1 Protocol | |||||||||||||||||
|
This document describes the Network File System (NFS) version 4 minor version 1, including features retained from the base protocol (NFS version 4 minor version 0, which is specified in RFC 7530) and protocol extensions made subsequently. The later minor version has no dependencies on NFS version 4 minor version 0, and was, until recently, documented as a completely separate protocol. This document is part of a set of documents which collectively obsolete RFC 8881. In addition to many corrections and clarifications, it will rely on NFSv4-wide documents to substantially revise the treatment of protocol extension, internationalization, and security, superseding the descriptions of those aspects of the protocol appearing in RFCs 5661 and 8881. | ||||||||||||||||
| draft-ietf-nfsv4-scsi-layout-nvme-02.txt | |||||||||||||||||
| Using the Parallel NFS (pNFS) SCSI Layout with NVMe | |||||||||||||||||
|
This document specifies how to use the Parallel Network File System (pNFS) SCSI Layout Type to access storage devices using the NVMe protocol family. | ||||||||||||||||
| draft-ietf-ntp-chronos-13.txt | |||||||||||||||||
| A Secure Selection and Filtering Mechanism for the Network Time Protocol with Khronos | |||||||||||||||||
|
The Network Time Protocol version 4 (NTPv4), as defined in RFC 5905, is the mechanism used by NTP clients to synchronize with NTP servers across the Internet. This document specifies an extension to the NTPv4 client, named Khronos, which is used as a "watchdog" alongside NTPv4, and provides improved security against time shifting attacks. Khronos involves changes to the NTP client's system process only. Since it does not affect the wire protocol, the Khronos mechanism is applicable to any current or future time protocol. | ||||||||||||||||
| draft-ietf-ntp-interleaved-modes-07.txt | |||||||||||||||||
| NTP Interleaved Modes | |||||||||||||||||
|
This document extends the specification of Network Time Protocol (NTP) version 4 in RFC 5905 with special modes called the NTP interleaved modes, that enable NTP servers to provide their clients and peers with more accurate transmit timestamps that are available only after transmitting NTP packets. More specifically, this document describes three modes: interleaved client/server, interleaved symmetric, and interleaved broadcast. | ||||||||||||||||
| draft-ietf-ntp-ntpv5-requirements-01.txt | |||||||||||||||||
| NTPv5 use cases and requirements | |||||||||||||||||
|
This document describes the use cases, requirements, and considerations that should be factored in the design of a successor protocol to supersede version 4 of the NTP protocol [RFC5905] presently referred to as NTP version 5 ("NTPv5"). Note to Readers _RFC Editor: please remove this section before publication_ Source code and issues for this draft can be found at https://github.com/fiestajetsam/draft-gruessing-ntp- ntpv5-requirements (https://github.com/fiestajetsam/draft-gruessing- ntp-ntpv5-requirements). | ||||||||||||||||
| draft-ietf-ntp-update-registries-06.txt | |||||||||||||||||
| Updating the NTP Registries | |||||||||||||||||
|
The Network Time Protocol (NTP) and Network Time Security (NTS) documents define a number of assigned number registries, collectively called the NTP registries. Some registries have wrong values, some registries do not follow current common practice, and some are just right. For the sake of completeness, this document reviews all NTP and NTS registries. This document updates RFC 5905, RFC 5906, RFC 8573, RFC 7822, and RFC 7821. | ||||||||||||||||
| draft-ietf-nvo3-bfd-geneve-09.txt | |||||||||||||||||
| BFD for Geneve | |||||||||||||||||
|
This document describes the use of the Bidirectional Forwarding Detection (BFD) protocol in point-to-point Generic Network Virtualization Encapsulation (Geneve) unicast tunnels used to make up an overlay network. | ||||||||||||||||
| draft-ietf-nvo3-encap-09.txt | |||||||||||||||||
| Network Virtualization Overlays (NVO3) Encapsulation Considerations | |||||||||||||||||
|
The IETF Network Virtualization Overlays (NVO3) Working Group Chairs and Routing Area Director chartered a design team to take forward the encapsulation discussion and see if there was potential to design a common encapsulation that addresses the various technical concerns. This document provides a record, for the benefit of the IETF community, of the considerations arrived at by the NVO3 encapsulation design team, which may be helpful with future deliberations by working groups over the choice of encapsulation formats. There are implications of having different encapsulations in real environments consisting of both software and hardware implementations and within and spanning multiple data centers. For example, OAM functions such as path MTU discovery become challenging with multiple encapsulations along the data path. The design team recommended Geneve with a few modifications as the common encapsulation. This document provides more details, particularly in Section 7. | ||||||||||||||||
| draft-ietf-nvo3-evpn-applicability-05.txt | |||||||||||||||||
| Applicability of EVPN to NVO3 Networks | |||||||||||||||||
|
In Network Virtualization Over Layer-3 (NVO3) networks, Network Virtualization Edge devices (NVEs) sit at the edge of the underlay network and provide Layer-2 and Layer-3 connectivity among Tenant Systems (TSes) of the same tenant. The NVEs need to build and maintain mapping tables so that they can deliver encapsulated packets to their intended destination NVE(s). While there are different options to create and disseminate the mapping table entries, NVEs may exchange that information directly among themselves via a control- plane protocol, such as Ethernet Virtual Private Network (EVPN). EVPN provides an efficient, flexible and unified control-plane option that can be used for Layer-2 and Layer-3 Virtual Network (VN) service connectivity. This document describes the applicability of EVPN to NVO3 networks and how EVPN solves the challenges in those networks. This document does not introduce any new procedures in EVPN. | ||||||||||||||||
| draft-ietf-nvo3-geneve-oam-06.txt | |||||||||||||||||
| OAM for use in GENEVE | |||||||||||||||||
|
This document lists a set of general requirements for active OAM protocols in the Geneve overlay network. Based on the requirements, IP encapsulation for active Operations, Administration, and Maintenance protocols in Geneve protocol is defined. Considerations for using ICMP and UDP-based protocols are discussed. | ||||||||||||||||
| draft-ietf-oauth-browser-based-apps-13.txt | |||||||||||||||||
| OAuth 2.0 for Browser-Based Apps | |||||||||||||||||
|
This specification details the security considerations and best practices that must be taken into account when developing browser- based applications that use OAuth 2.0. Discussion Venues This note is to be removed before publishing as an RFC. Discussion of this document takes place on the Web Authorization Protocol Working Group mailing list (oauth@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/oauth/. Source for this draft and an issue tracker can be found at https://github.com/oauth-wg/oauth-browser-based-apps. | ||||||||||||||||
| draft-ietf-oauth-cross-device-security-01.txt | |||||||||||||||||
| Cross-Device Flows: Security Best Current Practice | |||||||||||||||||
|
This document describes threats against cross-device flows along with near term mitigations, protocol selection guidance and the analytical tools needed to evaluate the effectiveness of these mitigations. It serves as a security guide to system designers, architects, product managers, security specialists, fraud analysts and engineers implementing cross-device flows. | ||||||||||||||||
| draft-ietf-oauth-dpop-16.txt | |||||||||||||||||
| OAuth 2.0 Demonstrating Proof-of-Possession at the Application Layer (DPoP) | |||||||||||||||||
|
This document describes a mechanism for sender-constraining OAuth 2.0 tokens via a proof-of-possession mechanism on the application level. This mechanism allows for the detection of replay attacks with access and refresh tokens. | ||||||||||||||||
| draft-ietf-oauth-jwt-introspection-response-12.txt | |||||||||||||||||
| JWT Response for OAuth Token Introspection | |||||||||||||||||
|
This specification proposes an additional JSON Web Token (JWT) secured response for OAuth 2.0 Token Introspection. | ||||||||||||||||
| draft-ietf-oauth-rar-23.txt | |||||||||||||||||
| OAuth 2.0 Rich Authorization Requests | |||||||||||||||||
|
This document specifies a new parameter authorization_details that is used to carry fine-grained authorization data in OAuth messages. | ||||||||||||||||
| draft-ietf-oauth-security-topics-22.txt | |||||||||||||||||
| OAuth 2.0 Security Best Current Practice | |||||||||||||||||
|
This document describes best current security practice for OAuth 2.0. It updates and extends the OAuth 2.0 Security Threat Model to incorporate practical experiences gathered since OAuth 2.0 was published and covers new threats relevant due to the broader application of OAuth 2.0. | ||||||||||||||||
| draft-ietf-oauth-selective-disclosure-jwt-04.txt | |||||||||||||||||
| Selective Disclosure for JWTs (SD-JWT) | |||||||||||||||||
|
This document specifies conventions for creating JSON Web Token (JWT) documents that support selective disclosure of JWT claims. Discussion Venues This note is to be removed before publishing as an RFC. Discussion of this document takes place on the Web Authorization Protocol Working Group mailing list (oauth@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/oauth/. Source for this draft and an issue tracker can be found at https://github.com/oauth-wg/oauth-selective-disclosure-jwt. | ||||||||||||||||
| draft-ietf-oauth-step-up-authn-challenge-15.txt | |||||||||||||||||
| OAuth 2.0 Step-up Authentication Challenge Protocol | |||||||||||||||||
|
It is not uncommon for resource servers to require different authentication strengths or recentness according to the characteristics of a request. This document introduces a mechanism for a resource server to signal to a client that the authentication event associated with the access token of the current request does not meet its authentication requirements and specify how to meet them. This document also codifies a mechanism for a client to request that an authorization server achieve a specific authentication strength or recentness when processing an authorization request. | ||||||||||||||||
| draft-ietf-oauth-v2-1-08.txt | |||||||||||||||||
| The OAuth 2.1 Authorization Framework | |||||||||||||||||
|
The OAuth 2.1 authorization framework enables an application to obtain limited access to a protected resource, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and an authorization service, or by allowing the application to obtain access on its own behalf. This specification replaces and obsoletes the OAuth 2.0 Authorization Framework described in RFC 6749 and the Bearer Token Usage in RFC 6750. | ||||||||||||||||
| draft-ietf-ohai-ohttp-08.txt | |||||||||||||||||
| Oblivious HTTP | |||||||||||||||||
|
This document describes a system for forwarding encrypted HTTP messages. This allows a client to make multiple requests to an origin server without that server being able to link those requests to the client or to identify the requests as having come from the same client, while placing only limited trust in the nodes used to forward the messages. | ||||||||||||||||
| draft-ietf-ohai-svcb-config-01.txt | |||||||||||||||||
| Discovery of Oblivious Services via Service Binding Records | |||||||||||||||||
|
This document defines a parameter that can be included in SVCB and HTTPS DNS resource records to denote that a service is accessible using Oblivious HTTP, by offering an Oblivious Gateway Resource through which to access the target. This document also defines a mechanism to learn the key configuration of the discovered Oblivious Gateway Resource. | ||||||||||||||||
| draft-ietf-openpgp-crypto-refresh-08.txt | |||||||||||||||||
| OpenPGP | |||||||||||||||||
|
This document specifies the message formats used in OpenPGP. OpenPGP provides encryption with public-key or symmetric cryptographic algorithms, digital signatures, compression and key management. This document is maintained in order to publish all necessary information needed to develop interoperable applications based on the OpenPGP format. It is not a step-by-step cookbook for writing an application. It describes only the format and methods needed to read, check, generate, and write conforming packets crossing any network. It does not deal with storage and implementation questions. It does, however, discuss implementation issues necessary to avoid security flaws. This document obsoletes: RFC 4880 (OpenPGP), RFC 5581 (Camellia in OpenPGP) and RFC 6637 (Elliptic Curves in OpenPGP). | ||||||||||||||||
| draft-ietf-opsawg-add-encrypted-dns-12.txt | |||||||||||||||||
| RADIUS Extensions for DHCP Configured Services | |||||||||||||||||
|
This document specifies two new Remote Authentication Dial-In User Service (RADIUS) attributes that carry DHCP options. The specification is generic and can be applicable to any service that relies upon DHCP. Both DHCPv4 and DHCPv6 configured services are covered. Also, this document updates RFC 4014 by relaxing a constraint on permitted RADIUS Attributes in the RADIUS Attributes DHCP suboption. | ||||||||||||||||
| draft-ietf-opsawg-ipfix-on-path-telemetry-02.txt | |||||||||||||||||
| Export of On-Path Delay in IPFIX | |||||||||||||||||
|
This document introduces new IP Flow Information Export (IPFIX) information elements to expose the On-Path Telemetry measured delay on the IOAM transit and decapsulation nodes. | ||||||||||||||||
| draft-ietf-opsawg-ipfix-srv6-srh-08.txt | |||||||||||||||||
| Export of Segment Routing over IPv6 Information in IP Flow Information Export (IPFIX) | |||||||||||||||||
|
This document introduces new IP Flow Information Export (IPFIX) Information Elements to identify a set of Segment Routing over IPv6 (SRv6) related information such as data contained in a Segment Routing Header (SRH), the SRv6 control plane, and the SRv6 endpoint behavior that traffic is being forwarded with. | ||||||||||||||||
| draft-ietf-opsawg-mud-acceptable-urls-06.txt | |||||||||||||||||
| Authorized update to MUD URLs | |||||||||||||||||
|
This document provides a way for an RFC8520 Manufacturer Usage Description (MUD) definitions to declare what are acceptable replacement MUD URLs for a device. RFCEDITOR-please-remove: this document is being worked on at: https://github.com/mcr/iot-mud-acceptable-urls | ||||||||||||||||
| draft-ietf-opsawg-mud-iot-dns-considerations-08.txt | |||||||||||||||||
| Operational Considerations for use of DNS in IoT devices | |||||||||||||||||
|
This document details concerns about how Internet of Things devices use IP addresses and DNS names. The issue becomes acute as network operators begin deploying RFC8520 Manufacturer Usage Description (MUD) definitions to control device access. This document makes recommendations on when and how to use DNS names in MUD files. | ||||||||||||||||
| draft-ietf-opsawg-mud-tls-12.txt | |||||||||||||||||
| Manufacturer Usage Description (MUD) (D)TLS Profiles for IoT Devices | |||||||||||||||||
|
This memo extends the Manufacturer Usage Description (MUD) specification to incorporate (D)TLS profile parameters. This allows a network security service to identify unexpected (D)TLS usage, which can indicate the presence of unauthorized software or malware on an endpoint. | ||||||||||||||||
| draft-ietf-opsawg-ol-02.txt | |||||||||||||||||
| Ownership and licensing statements in YANG | |||||||||||||||||
|
This memo provides for an extension to RFC 8520 that allows MUD file authors to specify ownership and licensing of MUD files themselves. This memo updates RFC 8520. However, it can also be used for purposes outside of MUD, and the grouping is structured as such. | ||||||||||||||||
| draft-ietf-opsawg-pcap-02.txt | |||||||||||||||||
| PCAP Capture File Format | |||||||||||||||||
|
This document describes the format used by the libpcap library to record captured packets to a file. Programs using the libpcap library to read and write those files, and thus reading and writing files in that format, include tcpdump. | ||||||||||||||||
| draft-ietf-opsawg-pcaplinktype-00.txt | |||||||||||||||||
| Link-Layer Types for PCAP and PCAPNG Capture File Formats | |||||||||||||||||
|
This document creates a registry for the PCAP and PCAPNG LINKTYPE values. The PCAP and PCAPNG formats are used to save network captures from programs such as tcpdump and wireshark, when using libraries such as libpcap. | ||||||||||||||||
| draft-ietf-opsawg-pcapng-00.txt | |||||||||||||||||
| PCAP Next Generation (pcapng) Capture File Format | |||||||||||||||||
|
This document describes a format to record captured packets to a file. This format is extensible; Wireshark can currently read and write it, and libpcap can currently read some pcapng files. Discussion Venues This note is to be removed before publishing as an RFC. Discussion of this document takes place on the OPSAWG Working Group mailing list (opsawg@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/opsawg/. Source for this draft and an issue tracker can be found at https://github.com/pcapng/pcapng. | ||||||||||||||||
| draft-ietf-opsawg-rfc7125-update-02.txt | |||||||||||||||||
| An Update to the tcpControlBits IP Flow Information Export (IPFIX) Information Element | |||||||||||||||||
|
RFC 7125 revised the tcpControlBits IP Flow Information Export (IPFIX) Information Element that was originally defined in RFC 5102 to reflect changes to the TCP Flags header field since RFC 793. However, that update is still problematic for interoperability because some flag values were deprecated since then. This document removes stale information from the IPFIX registry and avoiding future conflicts with the authoritative TCP Header Flags registry. This document obsoletes RFC 7125. | ||||||||||||||||
| draft-ietf-opsawg-sap-15.txt | |||||||||||||||||
| A YANG Network Model for Service Attachment Points (SAPs) | |||||||||||||||||
|
This document defines a YANG data model for representing an abstract view of the provider network topology that contains the points from which its services can be attached (e.g., basic connectivity, VPN, network slices). Also, the model can be used to retrieve the points where the services are actually being delivered to customers (including peer networks). This document augments the 'ietf-network' data model by adding the concept of Service Attachment Points (SAPs). The SAPs are the network reference points to which network services, such as Layer 3 Virtual Private Network (L3VPN) or Layer 2 Virtual Private Network (L2VPN), can be attached. One or multiple services can be bound to the same SAP. Both User-Network Interface (UNI) and Network-to- Network Interface (NNI) are supported in the SAP data model. | ||||||||||||||||
| draft-ietf-opsawg-sbom-access-15.txt | |||||||||||||||||
| Discovering and Retrieving Software Transparency and Vulnerability Information | |||||||||||||||||
|
To improve cybersecurity posture, automation is necessary to locate what software is running on a device, whether that software has known vulnerabilities, and what, if any recommendations suppliers may have. This memo extends the MUD YANG model to provide the locations of software bills of materials (SBOMS) and to vulnerability information. | ||||||||||||||||
| draft-ietf-opsawg-service-assurance-architecture-13.txt | |||||||||||||||||
| Service Assurance for Intent-based Networking Architecture | |||||||||||||||||
|
This document describes an architecture that aims at assuring that service instances are running as expected. As services rely upon multiple sub-services provided by a variety of elements including the underlying network devices and functions, getting the assurance of a healthy service is only possible with a holistic view of all involved elements. This architecture not only helps to correlate the service degradation with symptoms of a specific network component but also to list the services impacted by the failure or degradation of a specific network component. | ||||||||||||||||
| draft-ietf-opsawg-service-assurance-yang-11.txt | |||||||||||||||||
| YANG Modules for Service Assurance | |||||||||||||||||
|
This document specifies YANG modules for representing assurance graphs. These graphs represent the assurance of a given service by decomposing it into atomic assurance elements called subservices. A companion document, Service Assurance for Intent-based Networking Architecture, presents an architecture for implementing the assurance of such services. The YANG data models in this document conforms to the Network Management Datastore Architecture (NMDA) defined in RFC 8342. | ||||||||||||||||
| draft-ietf-opsawg-tacacs-tls13-02.txt | |||||||||||||||||
| TACACS+ TLS 1.3 | |||||||||||||||||
|
The TACACS+ Protocol [RFC8907] provides device administration for routers, network access servers and other networked computing devices via one or more centralized servers. This document, a companion to the TACACS+ protocol [RFC8907], adds Transport Layer Security (currently defined by TLS 1.3 [RFC8446]) support and obsoletes former inferior security mechanisms. | ||||||||||||||||
| draft-ietf-opsawg-tlstm-update-14.txt | |||||||||||||||||
| Updates to the TLS Transport Model for SNMP | |||||||||||||||||
|
This document updates RFC 6353 "Transport Layer Security (TLS) Transport Model for the Simple Network Management Protocol (SNMP)", to reflect changes necessary to support Transport Layer Security Version 1.3 (TLS 1.3) and Datagram Transport Layer Security Version 1.3 (DTLS 1.3), which are jointly known as "(D)TLS 1.3". This document is compatible with (D)TLS 1.2 and is intended to be compatible with future versions of SNMP and (D)TLS. This document updates the SNMP-TLS-TM-MIB as defined in RFC 6353. | ||||||||||||||||
| draft-ietf-opsawg-yang-vpn-service-pm-15.txt | |||||||||||||||||
| A YANG Model for Network and VPN Service Performance Monitoring | |||||||||||||||||
|
The data model for network topologies defined in RFC 8345 introduces vertical layering relationships between networks that can be augmented to cover network and service topologies. This document defines a YANG module for performance monitoring (PM) of both underlay networks and overlay VPN services that can be used to monitor and manage network performance on the topology of both layers. | ||||||||||||||||
| draft-ietf-opsec-indicators-of-compromise-04.txt | |||||||||||||||||
| Indicators of Compromise (IoCs) and Their Role in Attack Defence | |||||||||||||||||
|
Cyber defenders frequently rely on Indicators of Compromise (IoCs) to identify, trace, and block malicious activity in networks or on endpoints. This draft reviews the fundamentals, opportunities, operational limitations, and recommendations for IoC use. It highlights the need for IoCs to be detectable in implementations of Internet protocols, tools, and technologies - both for the IoCs' initial discovery and their use in detection - and provides a foundation for approaches to operational challenges in network security. | ||||||||||||||||
| draft-ietf-opsec-probe-attribution-03.txt | |||||||||||||||||
| Attribution of Internet Probes | |||||||||||||||||
|
Active measurements at Internet-scale can target either collaborating parties or non-collaborating ones. Sometimes these measurements are viewed as unwelcome or aggressive. This document proposes some simple techniques allowing any party or organization to understand what this unsolicited packet is, what is its purpose, and more importantly who to contact. | ||||||||||||||||
| draft-ietf-ospf-sr-yang-20.txt | |||||||||||||||||
| "OSPF SR (Segment Routing) YANG Data Model">YANG Data Model for OSPF Segment Routing | |||||||||||||||||
|
This document defines a YANG data module that can be used to configure and manage OSPF Extensions for Segment Routing. | ||||||||||||||||
| draft-ietf-payload-vp9-16.txt | |||||||||||||||||
| RTP Payload Format for VP9 Video | |||||||||||||||||
|
This specification describes an RTP payload format for the VP9 video codec. The payload format has wide applicability, as it supports applications from low bit-rate peer-to-peer usage, to high bit-rate video conferences. It includes provisions for temporal and spatial scalability. | ||||||||||||||||
| draft-ietf-pce-binding-label-sid-16.txt | |||||||||||||||||
| Carrying Binding Label/Segment Identifier (SID) in PCE-based Networks. | |||||||||||||||||
|
In order to provide greater scalability, network confidentiality, and service independence, Segment Routing (SR) utilizes a Binding Segment Identifier (SID) (called BSID) as described in RFC 8402. It is possible to associate a BSID to an RSVP-TE-signaled Traffic Engineering Label Switched Path or an SR Traffic Engineering path. The BSID can be used by an upstream node for steering traffic into the appropriate TE path to enforce SR policies. This document specifies the concept of binding value, which can be either an MPLS label or Segment Identifier. It further specifies an extension to Path Computation Element (PCE) communication Protocol(PCEP) for reporting the binding value by a Path Computation Client (PCC) to the PCE to support PCE-based Traffic Engineering policies. | ||||||||||||||||
| draft-ietf-pce-enhanced-errors-13.txt | |||||||||||||||||
| Extensions to the Path Computation Element Communication Protocol for Enhanced Errors and Notifications | |||||||||||||||||
|
This document defines new error and notification TLVs for the PCE Communication Protocol (PCEP) specified in RFC5440, and will update it. It identifies the possible PCEP behaviors in case of error or notification. Thus, this draft defines types of errors and how they are disclosed to other PCEs in order to support predefined PCEP behaviors. | ||||||||||||||||
| draft-ietf-pce-flexible-grid-09.txt | |||||||||||||||||
| PCEP Extension for Flexible Grid Networks | |||||||||||||||||
|
This document provides the Path Computation Element Communication Protocol (PCEP) extensions for the support of Routing and Spectrum Assignment (RSA) in Flexible Grid networks. | ||||||||||||||||
| draft-ietf-pce-local-protection-enforcement-08.txt | |||||||||||||||||
| Local Protection Enforcement in PCEP | |||||||||||||||||
|
This document extends the base specification to clarify usage of the local protection desired bit signalled in the Path Computation Element Protocol (PCEP). This document also introduces a new flag for signalling protection strictness in PCEP. | ||||||||||||||||
| draft-ietf-pce-multipath-07.txt | |||||||||||||||||
| PCEP Extensions for Signaling Multipath Information | |||||||||||||||||
|
Path computation algorithms are not limited to return a single optimal path. Multiple paths may exist that satisfy the given objectives and constraints. This document defines a mechanism to encode multiple paths for a single set of objectives and constraints. This is a generic PCEP mechanism, not specific to any path setup type or dataplane. The mechanism is applicable to both stateless and stateful PCEP. | ||||||||||||||||
| draft-ietf-pce-pcep-color-00.txt | |||||||||||||||||
| Path Computation Element Protocol(PCEP) Extension for Color | |||||||||||||||||
|
Color is a 32-bit numerical attribute that is used to associate a Traffic Engineering (TE) tunnel or policy with an intent or objective (e.g. low latency). This document specifies an extension to Path Computation Element Protocol (PCEP) to carry the color attribute. | ||||||||||||||||
| draft-ietf-pce-pcep-extension-native-ip-20.txt | |||||||||||||||||
| PCEP Extension for Native IP Network | |||||||||||||||||
|
This document defines the Path Computation Element Communication Protocol (PCEP) extension for Central Control Dynamic Routing (CCDR) based application in Native IP network. The scenario and framework of CCDR in native IP is described in [RFC8735] and [RFC8821]. This draft describes the key information that is transferred between Path Computation Element (PCE) and Path Computation Clients (PCC) to accomplish the End to End (E2E) traffic assurance in Native IP network under central control mode. | ||||||||||||||||
| draft-ietf-pce-pcep-extension-pce-controller-sr-06.txt | |||||||||||||||||
| PCE Communication Protocol (PCEP) Extensions for Using PCE as a Central Controller (PCECC) for Segment Routing (SR) MPLS Segment Identifier (SID) Allocation and Distribution. | |||||||||||||||||
|
The PCE is a core component of Software-Defined Networking (SDN) systems. A PCE-based Central Controller (PCECC) can simplify the processing of a distributed control plane by blending it with elements of SDN and without necessarily completely replacing it. Thus, the Label Switched Path (LSP) can be calculated/set up/initiated and the label forwarding entries can also be downloaded through a centralized PCE server to each network device along the path while leveraging the existing PCE technologies as much as possible. This document specifies the procedures and PCE Communication Protocol (PCEP) extensions when a PCE-based controller is also responsible for configuring the forwarding actions on the routers, in addition to computing the paths for packet flows in a segment routing (SR) network and telling the edge routers what instructions to attach to packets as they enter the network. PCECC as defined in RFC 9050 is further enhanced for SR-MPLS SID (Segment Identifier) allocation and distribution. | ||||||||||||||||
| draft-ietf-pce-pcep-extension-pce-controller-srv6-00.txt | |||||||||||||||||
| PCE Communication Protocol (PCEP) Extensions for Using the PCE as a Central Controller (PCECC) for Segment Routing over IPv6 (SRv6) Segment Identifier (SID) Allocation and Distribution. | |||||||||||||||||
|
The PCE is a core component of Software-Defined Networking (SDN) systems. A PCE-based Central Controller (PCECC) can simplify the processing of a distributed control plane by blending it with elements of SDN and without necessarily completely replacing it. 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 for Segment Routing (SR) in IPv6 (SRv6) network and telling the edge routers what instructions to attach to packets as they enter the network. PCECC is further enhanced for SRv6 SID (Segment Identifier) allocation and distribution. | ||||||||||||||||
| draft-ietf-pce-pcep-ifit-02.txt | |||||||||||||||||
| Path Computation Element Communication Protocol (PCEP) Extensions to Enable IFIT | |||||||||||||||||
|
In-situ Flow Information Telemetry (IFIT) refers to network OAM data plane on-path telemetry techniques, in particular In-situ OAM (IOAM) and Alternate Marking. This document defines PCEP extensions to allow a Path Computation Client (PCC) to indicate which IFIT features it supports, and a Path Computation Element (PCE) to configure IFIT behavior at a PCC for a specific path in the stateful PCE model. The application to Segment Routing (SR) is reported. However, the PCEP extensions described in this document can be generalized for all path types, but that is out of scope of this document. | ||||||||||||||||
| draft-ietf-pce-pcep-l2-flowspec-03.txt | |||||||||||||||||
| PCEP Extension for 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. 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 L3 flowspecs. | ||||||||||||||||
| draft-ietf-pce-pcep-pmtu-03.txt | |||||||||||||||||
| Support for Path MTU (PMTU) in the Path Computation Element (PCE) Communication Protocol (PCEP) | |||||||||||||||||
|
The Path Computation Element (PCE) provides path computation functions in support of traffic engineering in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. The Source Packet Routing in Networking (SPRING) architecture describes how Segment Routing (SR) can be used to steer packets through an IPv6 or MPLS network using the source routing paradigm. A Segment Routed Path can be derived from a variety of mechanisms, including an IGP Shortest Path Tree (SPT), explicit configuration, or a Path Computation Element (PCE). Since the SR does not require signaling, the path maximum transmission unit (MTU) information for SR path is not available at the headend. This document specify the extension to PCE Communication Protocol (PCEP) to carry path MTU as a new metric type in the PCEP messages for SR and other scenarios. This document also updates RFC 5440 to allow metric bounds to be minimum as needed in the case of path MTU. | ||||||||||||||||
| draft-ietf-pce-pcep-srv6-yang-02.txt | |||||||||||||||||
| A YANG Data Model for Segment Routing (SR) Policy and SR in IPv6 (SRv6) support in Path Computation Element Communications Protocol (PCEP) | |||||||||||||||||
|
This document augments a YANG data model for the management of Path Computation Element Communications Protocol (PCEP) for communications between a Path Computation Client (PCC) and a Path Computation Element (PCE), or between two PCEs in support for Segment Routing in IPv6 (SRv6) and SR Policy. The data model includes configuration data and state data (status information and counters for the collection of statistics). | ||||||||||||||||
| draft-ietf-pce-pcep-stateful-pce-gmpls-20.txt | |||||||||||||||||
| Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE Usage in GMPLS-controlled Networks | |||||||||||||||||
|
The PCE communication Protocol (PCEP) has been extended to support stateful PCE functions where the Stateful PCE maintains information about paths and resource usage within a network, but these extensions do not cover all requirements for GMPLS networks. This document provides the extensions required for PCEP so as to enable the usage of a stateful PCE capability in GMPLS-controlled networks. | ||||||||||||||||
| draft-ietf-pce-pcep-yang-21.txt | |||||||||||||||||
| A YANG Data Model for Path Computation Element Communications Protocol (PCEP) | |||||||||||||||||
|
This document defines a YANG data model for the management of Path Computation Element communications Protocol (PCEP) for communications between a Path Computation Client (PCC) and a Path Computation Element (PCE), or between two PCEs. The data model includes configuration and state data. | ||||||||||||||||
| draft-ietf-pce-segment-routing-ipv6-16.txt | |||||||||||||||||
| Path Computation Element Communication Protocol (PCEP) Extensions for Segment Routing leveraging the IPv6 dataplane | |||||||||||||||||
|
Segment Routing (SR) can be used to steer packets through an IPv6 or MPLS network using the source routing paradigm. SR enables any head- end node to select any path without relying on a hop-by-hop signaling technique (e.g., LDP or RSVP-TE). A Segment Routed Path can be derived from a variety of mechanisms, including an IGP Shortest Path Tree (SPT), explicit configuration, or a PCE. Since SR can be applied to both MPLS and IPv6 forwarding planes, a PCE should be able to compute SR-Path for both MPLS and IPv6 forwarding planes. The PCEP extension and mechanisms to support SR- MPLS are described in [RFC8664]. This document describes the extensions required for SR support for IPv6 data plane in the Path Computation Element communication Protocol(PCEP). | ||||||||||||||||
| draft-ietf-pce-segment-routing-policy-cp-09.txt | |||||||||||||||||
| PCEP extension to support Segment Routing Policy Candidate Paths | |||||||||||||||||
|
A Segment Routing (SR) Policy ([RFC9256]) is a non-empty set of SR Candidate Paths, that all share the same | ||||||||||||||||
| draft-ietf-pce-sr-bidir-path-11.txt | |||||||||||||||||
| Path Computation Element Communication Protocol (PCEP) Extensions for Associated Bidirectional Segment Routing (SR) Paths | |||||||||||||||||
|
The Path Computation Element Communication Protocol (PCEP) provides mechanisms for Path Computation Elements (PCEs) to perform path computations in response to Path Computation Clients (PCCs) requests. Segment routing (SR) leverages the source routing and tunneling paradigms. The Stateful PCEP extensions allow stateful control of Segment Routing Traffic Engineering (TE) Paths. Furthermore, PCEP can be used for computing SR TE paths in the network. This document defines PCEP extensions for grouping two unidirectional SR Paths (one in each direction in the network) into a single associated bidirectional SR Path. The mechanisms defined in this document can also be applied using a stateful PCE for both PCE- initiated and PCC-initiated LSPs or when using a stateless PCE. | ||||||||||||||||
| draft-ietf-pce-sr-p2mp-policy-03.txt | |||||||||||||||||
| PCEP extensions for p2mp sr policy | |||||||||||||||||
|
SR P2MP policies are set of policies that enable architecture for P2MP service delivery. This document specifies extensions to the Path Computation Element Communication Protocol (PCEP) that allow a stateful PCE to compute and initiate P2MP paths from a Root to a set of Leaves. | ||||||||||||||||
| draft-ietf-pce-sr-path-segment-07.txt | |||||||||||||||||
| Path Computation Element Communication Protocol (PCEP) Extension for Path Segment in Segment Routing (SR) | |||||||||||||||||
|
The Path Computation Element (PCE) provides path computation functions in support of traffic engineering in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. The Source Packet Routing in Networking (SPRING) architecture describes how Segment Routing (SR) can be used to steer packets through an IPv6 or MPLS network using the source routing paradigm. A Segment Routed Path can be derived from a variety of mechanisms, including an IGP Shortest Path Tree (SPT), explicit configuration, or a Path Computation Element (PCE). Path identification is needed for several use cases such as performance measurement in Segment Routing (SR) network. This document specifies extensions to the Path Computation Element Communication Protocol (PCEP) to support requesting, replying, reporting and updating the Path Segment ID (Path SID) between PCEP speakers. | ||||||||||||||||
| draft-ietf-pce-state-sync-04.txt | |||||||||||||||||
| Inter Stateful Path Computation Element (PCE) Communication Procedures. | |||||||||||||||||
|
The Path Computation Element (PCE) Communication Protocol (PCEP) provides mechanisms for PCEs to perform path computation in response to a Path Computation Client (PCC) request. The Stateful PCE extensions allow stateful control of Multi-Protocol Label Switching (MPLS) Traffic Engineering (TE) Label Switched Paths (LSPs) using PCEP. A Path Computation Client (PCC) can synchronize an LSP state information to a Stateful Path Computation Element (PCE). A PCC can have multiple PCEP sessions towards multiple PCEs. There are some use cases, where an inter-PCE stateful communication can bring additional resiliency in the design, for instance when some PCC-PCE session fails. This document describes the procedures to allow a stateful communication between PCEs for various use-cases and also the procedures to prevent computations loops. | ||||||||||||||||
| draft-ietf-pce-stateful-pce-optional-05.txt | |||||||||||||||||
| Extension for Stateful PCE to allow Optional Processing of PCE Communication Protocol (PCEP) Objects | |||||||||||||||||
|
This document introduces a mechanism to mark some of the Path Computation Element (PCE) Communication Protocol (PCEP) objects as optional during PCEP messages exchange for the Stateful PCE model to allow relaxing some constraints during path computation and setup. This document introduces this relaxation to stateful PCE and updates RFC 8231. | ||||||||||||||||
| draft-ietf-pim-3228bis-00.txt | |||||||||||||||||
| IANA Considerations for Internet Group Management Protocols | |||||||||||||||||
|
This document specifies revised IANA Considerations for the Internet Group Management Protocol and the Multicast Listener Discovery protocol. This document specifies the guidance provided to IANA to manage values associated with various fields within the protocol headers of the group management protocols. This document obsoletes RFC 3228 and updates RFC 4443. | ||||||||||||||||
| draft-ietf-pim-3376bis-05.txt | |||||||||||||||||
| Internet Group Management Protocol,Version 3 | |||||||||||||||||
|
This document specifies a revised Version 3 of the Internet Group Management Protocol, IGMPv3. 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 obsoletes RFC 3376. | ||||||||||||||||
| draft-ietf-pim-3810bis-05.txt | |||||||||||||||||
| Multicast Listener Discovery Version 2 (MLDv2) for IPv6 | |||||||||||||||||
|
This document updates RFC 2710, and it specifies Version 2 of the Multicast Listener Discovery Protocol (MLDv2). MLD is used by an IPv6 router to discover the presence of multicast listeners on directly attached links, and to discover which multicast addresses are of interest to those neighboring nodes. MLDv2 is designed to be interoperable with MLDv1. MLDv2 adds the ability for a node to report interest in listening to packets with a particular multicast address only from specific source addresses or from all sources except for specific source addresses. This document obsoletes RFC 3810. | ||||||||||||||||
| draft-ietf-pim-assert-packing-12.txt | |||||||||||||||||
| PIM Assert Message Packing | |||||||||||||||||
|
In PIM-SM shared LAN networks, there is often more than one upstream router. When PIM Sparse Mode (PIM-SM), including PIM Source Specific-Specific Multicast (PIM-SSM), is used, this can lead to duplicate IP multicast packets being forwarded by these PIM routers. PIM Assert messages are used to elect a single forwarder for each IP multicast traffic flow between these routers. This document defines a mechanism to send and receive information for multiple IP multicast flows in a single PackedAssert message. This optimization reduces the total number of PIM packets on the LAN and can therefore speed up the election of the single forwarder, reducing the number of duplicate IP multicast packets incurred. | ||||||||||||||||
| draft-ietf-pim-dr-improvement-14.txt | |||||||||||||||||
| Protocol Independent Multicast - Sparse Mode (PIM-SM) Designated Router (DR) Improvement | |||||||||||||||||
|
Protocol Independent Multicast - Sparse Mode (PIM-SM) is a widely deployed multicast protocol. As deployment for the PIM protocol is growing day by day, a user expects lower packet loss and faster convergence regardless of the cause of the network failure. This document defines an extension to the existing protocol, which improves the PIM's stability with respect to packet loss and convergence time when the PIM Designated Router (DR) role changes. | ||||||||||||||||
| draft-ietf-pim-igmp-mld-proxy-yang-10.txt | |||||||||||||||||
| A YANG Data Model for IGMP/MLD Proxy | |||||||||||||||||
|
This document defines a YANG data model that can be used to configure and manage Internet Group Management Protocol (IGMP) or Multicast Listener Discovery (MLD) proxy devices. The YANG module in this document conforms to Network Management Datastore Architecture (NMDA). | ||||||||||||||||
| draft-ietf-pim-igmp-mld-snooping-yang-l2vpn-ext-02.txt | |||||||||||||||||
| IGMP and MLD Snooping Yang Module Extension for L2VPN | |||||||||||||||||
|
Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Snooping could be used in both bridge service and L2VPN service. The old ietf-igmp-mld-snooping yang module just describes the bridge service. In this document we extend the existing ietf-igmp-mld- snooping yang module and make it could be used in L2VPN service. | ||||||||||||||||
| draft-ietf-pim-jp-extensions-lisp-03.txt | |||||||||||||||||
| PIM Join/ Prune Attributes for LISP Environments using Underlay Multicast | |||||||||||||||||
|
This document specifies an extension to PIM Receiver RLOC Join/ Prune attribute that supports the construction of multicast distribution trees where the root and receivers are located in different Locator/ ID Separation Protocol (LISP) sites and are connected using underlay IP Multicast. This attribute allows the receiver site to signal the underlay multicast group to the control plane of the root ITR (Ingress Tunnel Router). | ||||||||||||||||
| draft-ietf-pim-mofrr-tilfa-01.txt | |||||||||||||||||
| Multicast-only Fast Reroute Based on Topology Independent Loop-free Alternate Fast Reroute | |||||||||||||||||
|
Multicast-only Fast Reroute (MoFRR) has been defined in [RFC7431], but the selection of the secondary multicast next hop only according to the loop-free alternate fast reroute, which has restrictions in multicast deployments. This document describes a mechanism for Multicast-only Fast Reroute by using Topology Independent Loop-free Alternate fast reroute, which is independent of network topology and can achieve covering more network environments. | ||||||||||||||||
| draft-ietf-pim-null-register-packing-16.txt | |||||||||||||||||
| PIM Null-Register packing | |||||||||||||||||
|
In PIM-SM networks, PIM Null-Register messages are sent by the Designated Router (DR) to the Rendezvous Point (RP) to signal the presence of Multicast sources in the network. There are periodic PIM Null-Registers sent from the DR to the RP to keep the state alive at the RP as long as the source is active. The PIM Null-Register message carries information about a single Multicast source and group. This document defines a standard to send multiple Multicast source and group information in a single PIM message. This document refers to the new messages as the PIM Packed Null-Register message and PIM Packed Register-Stop message. | ||||||||||||||||
| draft-ietf-pim-p2mp-policy-ping-03.txt | |||||||||||||||||
| P2MP Policy Ping | |||||||||||||||||
|
SR P2MP policies are set of policies that enable architecture for P2MP service delivery. A P2MP Policy consists of candidate paths that connects the Root of the Tree to a set of Leaves. The P2MP policy is composed of replication segments. A replication segment is a forwarding instruction for a candidate path which is downloaded to the Root, transit nodes and the leaves. This document describes a simple and efficient mechanism that can be used to detect data plane failures in P2MP Policy Candidate Paths (CPs) and Path Instances (PIs). | ||||||||||||||||
| draft-ietf-pim-rfc8736bis-00.txt | |||||||||||||||||
| PIM Message Type Space Extension and Reserved Bits | |||||||||||||||||
|
The PIM version 2 messages share a common message header format. The common header definition contains eight reserved bits. This document specifies how these bits may be used by individual message types and creates a registry containing the per-message-type usage. This document also extends the PIM type space by defining three new message types. For each of the new types, four of the previously reserved bits are used to form an extended type range. This document updates RFCs 7761 and 3973 by defining the use of the currently Reserved field in the PIM common header. This document further updates RFCs 7761 and 3973, along with RFCs 5015, 5059, 6754, and 8364, by specifying the use of the currently reserved bits for each PIM message. This document obsoletes RFC 8736. | ||||||||||||||||
| draft-ietf-pim-sr-p2mp-policy-06.txt | |||||||||||||||||
| Segment Routing Point-to-Multipoint Policy | |||||||||||||||||
|
This document describes an architecture to construct a Point-to- Multipoint (P2MP) tree to deliver Multi-point services in a Segment Routing domain. A SR P2MP tree is constructed by stitching a set of Replication segments together. A SR Point-to-Multipoint (SR P2MP) Policy is used to define and instantiate a P2MP tree which is computed by a PCE. | ||||||||||||||||
| draft-ietf-ppm-dap-04.txt | |||||||||||||||||
| Distributed Aggregation Protocol for Privacy Preserving Measurement | |||||||||||||||||
|
There are many situations in which it is desirable to take measurements of data which people consider sensitive. In these cases, the entity taking the measurement is usually not interested in people's individual responses but rather in aggregated data. Conventional methods require collecting individual responses and then aggregating them, thus representing a threat to user privacy and rendering many such measurements difficult and impractical. This document describes a multi-party distributed aggregation protocol (DAP) for privacy preserving measurement (PPM) which can be used to collect aggregate data without revealing any individual user's data. | ||||||||||||||||
| draft-ietf-privacypass-architecture-11.txt | |||||||||||||||||
| The Privacy Pass Architecture | |||||||||||||||||
|
This document specifies the Privacy Pass architecture and requirements for its constituent protocols used for constructing privacy-preserving authentication mechanisms. It provides recommendations on how the architecture should be deployed to ensure the privacy of clients and the security of all participating entities. | ||||||||||||||||
| draft-ietf-privacypass-auth-scheme-09.txt | |||||||||||||||||
| The Privacy Pass HTTP Authentication Scheme | |||||||||||||||||
|
This document defines an HTTP authentication scheme that can be used by clients to redeem Privacy Pass tokens with an origin. It can also be used by origins to challenge clients to present an acceptable Privacy Pass token. | ||||||||||||||||
| draft-ietf-privacypass-key-consistency-00.txt | |||||||||||||||||
| Key Consistency and Discovery | |||||||||||||||||
|
This document describes the key consistency and correctness requirements of protocols such as Privacy Pass, Oblivious DoH, and Oblivious HTTP for user privacy. It discusses several mechanisms and proposals for enabling user privacy in varying threat models. In concludes with discussion of open problems in this area. | ||||||||||||||||
| draft-ietf-privacypass-protocol-10.txt | |||||||||||||||||
| Privacy Pass Issuance Protocol | |||||||||||||||||
|
This document specifies two variants of the two-message issuance protocol for Privacy Pass tokens: one that produces tokens that are privately verifiable using the issuance private key, and another that produces tokens that are publicly verifiable using the issuance public key. | ||||||||||||||||
| draft-ietf-privacypass-rate-limit-tokens-01.txt | |||||||||||||||||
| Rate-Limited Token Issuance Protocol | |||||||||||||||||
|
This document specifies a variant of the Privacy Pass issuance protocol that allows for tokens to be rate-limited on a per-origin basis. This enables origins to use tokens for use cases that need to restrict access from anonymous clients. | ||||||||||||||||
| draft-ietf-quic-ack-frequency-04.txt | |||||||||||||||||
| QUIC Acknowledgement Frequency | |||||||||||||||||
|
This document describes a QUIC extension for an endpoint to control its peer's delaying of acknowledgements. Note to Readers Discussion of this draft takes place on the QUIC working group mailing list (quic@ietf.org), which is archived at https://mailarchive.ietf.org/arch/search/?email_list=quic. Source code and issues list for this draft can be found at https://github.com/quicwg/ack-frequency. Working Group information can be found at https://github.com/quicwg. | ||||||||||||||||
| draft-ietf-quic-load-balancers-15.txt | |||||||||||||||||
| QUIC-LB: Generating Routable QUIC Connection IDs | |||||||||||||||||
|
QUIC address migration allows clients to change their IP address while maintaining connection state. To reduce the ability of an observer to link two IP addresses, clients and servers use new connection IDs when they communicate via different client addresses. This poses a problem for traditional "layer-4" load balancers that route packets via the IP address and port 4-tuple. This specification provides a standardized means of securely encoding routing information in the server's connection IDs so that a properly configured load balancer can route packets with migrated addresses correctly. As it proposes a structured connection ID format, it also provides a means of connection IDs self-encoding their length to aid some hardware offloads. | ||||||||||||||||
| draft-ietf-quic-multipath-04.txt | |||||||||||||||||
| Multipath Extension for QUIC | |||||||||||||||||
|
This document specifies a multipath extension for the QUIC protocol to enable the simultaneous usage of multiple paths for a single connection. Discussion Venues This note is to be removed before publishing as an RFC. Discussion of this document takes place on the QUIC Working Group mailing list (quic@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/quic/. Source for this draft and an issue tracker can be found at https://github.com/mirjak/draft-lmbdhk-quic-multipath. | ||||||||||||||||
| draft-ietf-quic-qlog-h3-events-04.txt | |||||||||||||||||
| HTTP/3 and QPACK qlog event definitions | |||||||||||||||||
|
This document describes concrete qlog event definitions and their metadata for HTTP/3 and QPACK-related events. These events can then be embedded in the higher level schema defined in [QLOG-MAIN]. | ||||||||||||||||
| draft-ietf-quic-qlog-main-schema-05.txt | |||||||||||||||||
| Main logging schema for qlog | |||||||||||||||||
|
This document describes a high-level schema for a standardized logging format called qlog. This format allows easy sharing of data and the creation of reusable visualization and debugging tools. The high-level schema in this document is intended to be protocol- agnostic. Separate documents specify how the format should be used for specific protocol data. The schema is also format-agnostic, and can be represented in for example JSON, csv or protobuf. | ||||||||||||||||
| draft-ietf-quic-qlog-quic-events-04.txt | |||||||||||||||||
| QUIC event definitions for qlog | |||||||||||||||||
|
This document describes concrete qlog event definitions and their metadata for QUIC events. These events can then be embedded in the higher level schema defined in [QLOG-MAIN]. | ||||||||||||||||
| draft-ietf-quic-v2-10.txt | |||||||||||||||||
| QUIC Version 2 | |||||||||||||||||
|
This document specifies QUIC version 2, which is identical to QUIC version 1 except for some trivial details. Its purpose is to combat various ossification vectors and exercise the version negotiation framework. It also serves as a template for the minimum changes in any future version of QUIC. Note that "version 2" is an informal name for this proposal that indicates it is the second standards-track QUIC version. The protocol specified here uses a version number other than 2 in the wire image, in order to minimize ossification risk. | ||||||||||||||||
| draft-ietf-quic-version-negotiation-14.txt | |||||||||||||||||
| Compatible Version Negotiation for QUIC | |||||||||||||||||
|
QUIC does not provide a complete version negotiation mechanism but instead only provides a way for the server to indicate that the version the client chose is unacceptable. This document describes a version negotiation mechanism that allows a client and server to select a mutually supported version. Optionally, if the client's chosen version and the negotiated version share a compatible first flight format, the negotiation can take place without incurring an extra round trip. This document updates RFC 8999. | ||||||||||||||||
| draft-ietf-rats-ar4si-04.txt | |||||||||||||||||
| Attestation Results for Secure Interactions | |||||||||||||||||
|
This document defines reusable Attestation Result information elements. When these elements are offered to Relying Parties as Evidence, different aspects of Attester trustworthiness can be evaluated. Additionally, where the Relying Party is interfacing with a heterogeneous mix of Attesting Environment and Verifier types, consistent policies can be applied to subsequent information exchange between each Attester and the Relying Party. | ||||||||||||||||
| draft-ietf-rats-concise-ta-stores-00.txt | |||||||||||||||||
| Concise TA Stores (CoTS) | |||||||||||||||||
|
Trust anchor (TA) stores may be used for several purposes in the Remote Attestation Procedures (RATS) architecture including verifying endorsements, reference values, digital letters of approval, attestations, or public key certificates. This document describes a Concise Reference Integrity Manifest (CoRIM) extension that may be used to convey optionally constrained trust anchor stores containing optionally constrained trust anchors in support of these purposes. | ||||||||||||||||
| draft-ietf-rats-corim-01.txt | |||||||||||||||||
| Concise Reference Integrity Manifest | |||||||||||||||||
|
Remote Attestation Procedures (RATS) enable Relying Parties to assess the trustworthiness of a remote Attester and therefore to decide whether to engage in secure interactions with it. Evidence about trustworthiness can be rather complex and it is deemed unrealistic that every Relying Party is capable of the appraisal of Evidence. Therefore that burden is typically offloaded to a Verifier. In order to conduct Evidence appraisal, a Verifier requires not only fresh Evidence from an Attester, but also trusted Endorsements and Reference Values from Endorsers and Reference Value Providers, such as manufacturers, distributors, or device owners. This document specifies Concise Reference Integrity Manifests (CoRIM) that represent Endorsements and Reference Values in CBOR format. Composite devices or systems are represented by a collection of Concise Module Identifiers (CoMID) and Concise Software Identifiers (CoSWID) bundled in a CoRIM document. | ||||||||||||||||
| draft-ietf-rats-daa-03.txt | |||||||||||||||||
| Direct Anonymous Attestation for the Remote Attestation Procedures Architecture | |||||||||||||||||
|
This document maps the concept of Direct Anonymous Attestation (DAA) to the Remote Attestation Procedures (RATS) Architecture. The protocol entity DAA Issuer is introduced and its mapping with existing RATS roles in DAA protocol steps is specified. | ||||||||||||||||
| draft-ietf-rats-eat-19.txt | |||||||||||||||||
| The Entity Attestation Token (EAT) | |||||||||||||||||
|
An Entity Attestation Token (EAT) provides an attested claims set that describes state and characteristics of an entity, a device like a smartphone, IoT device, network equipment or such. This claims set is used by a relying party, server or service to determine how much it wishes to trust the entity. An EAT is either a CBOR Web Token (CWT) or JSON Web Token (JWT) with attestation-oriented claims. | ||||||||||||||||
| draft-ietf-rats-eat-media-type-02.txt | |||||||||||||||||
| EAT Media Types | |||||||||||||||||
|
Payloads used in Remote Attestation Procedures may require an associated media type for their conveyance, for example when used in RESTful APIs. This memo defines media types to be used for Entity Attestation Tokens (EAT). | ||||||||||||||||
| draft-ietf-rats-network-device-subscription-03.txt | |||||||||||||||||
| Attestation Event Stream Subscription | |||||||||||||||||
|
This memo defines how to subscribe to YANG Event Streams for Remote Attestation Procedures (RATS). In RATS, Conceptional Messages, are defined. Analogously, the YANG module defined in this memo augments the YANG module for TPM-based Challenge-Response based Remote Attestation (CHARRA) to allow for subscription to remote attestation Evidence. Additionally, this memo provides the methods and means to define additional Event Streams for other Conceptual Message as illustrated in the RATS Architecture, e.g. Attestation Results, Endorsements, or Event Logs. | ||||||||||||||||
| draft-ietf-rats-reference-interaction-models-07.txt | |||||||||||||||||
| Reference Interaction Models for Remote Attestation Procedures | |||||||||||||||||
|
This document describes interaction models for remote attestation procedures (RATS). Three conveying mechanisms -- Challenge/Response, Uni-Directional, and Streaming Remote Attestation -- are illustrated and defined. Analogously, a general overview about the information elements typically used by corresponding conveyance protocols are highlighted. | ||||||||||||||||
| draft-ietf-rats-tpm-based-network-device-attest-14.txt | |||||||||||||||||
| TPM-based Network Device Remote Integrity Verification | |||||||||||||||||
|
This document describes a workflow for remote attestation of the integrity of firmware and software installed on network devices that contain Trusted Platform Modules [TPM1.2], [TPM2.0], as defined by the Trusted Computing Group (TCG)), or equivalent hardware implementations that include the protected capabilities, as provided by TPMs. | ||||||||||||||||
| draft-ietf-rats-uccs-05.txt | |||||||||||||||||
| A CBOR Tag for Unprotected CWT Claims Sets | |||||||||||||||||
|
CBOR Web Token (CWT, RFC 8392) Claims Sets sometimes do not need the protection afforded by wrapping them into COSE, as is required for a true CWT. This specification defines a CBOR tag for such unprotected CWT Claims Sets (UCCS) and discusses conditions for its proper use. | ||||||||||||||||
| draft-ietf-rats-yang-tpm-charra-21.txt | |||||||||||||||||
| A YANG Data Model for Challenge-Response-based Remote Attestation Procedures using TPMs | |||||||||||||||||
|
This document defines YANG RPCs and a few configuration nodes required to retrieve attestation evidence about integrity measurements from a device, following the operational context defined in TPM-based Network Device Remote Integrity Verification. Complementary measurement logs are also provided by the YANG RPCs, originating from one or more roots of trust for measurement (RTMs). The module defined requires at least one TPM 1.2 or TPM 2.0 as well as a corresponding TPM Software Stack (TSS), or equivalent hardware implementations that include the protected capabilities as provided by TPMs as well as a corresponding software stack, included in the device components of the composite device the YANG server is running on. | ||||||||||||||||
| draft-ietf-raw-architecture-11.txt | |||||||||||||||||
| Reliable and Available Wireless Architecture | |||||||||||||||||
|
Reliable and Available Wireless (RAW) provides for high reliability and availability for IP connectivity across any combination of wired and wireless network segments. The RAW Architecture extends the DetNet Architecture and other standard IETF concepts and mechanisms to adapt to the specific challenges of the wireless medium, in particular intermittently lossy connectivity. This document defines a network control loop that optimizes the use of constrained spectrum and energy while maintaining the expected connectivity properties, typically reliability and latency. The loop involves OAM, PCE, and PREOF extensions, and a new Controller plane Function called the Path Selection Engine, that dynamically selects the DetNet path for the next packets to route around local failures. | ||||||||||||||||
| draft-ietf-raw-oam-support-06.txt | |||||||||||||||||
| Operations,Administration and Maintenance (OAM) features for RAW | |||||||||||||||||
|
Some critical applications may use a wireless infrastructure. However, wireless networks exhibit a bandwidth of several orders of magnitude lower than wired networks. Besides, wireless transmissions are lossy by nature; the probability that a packet cannot be decoded correctly by the receiver may be quite high. In these conditions, providing high reliability and a low delay is challenging. This document lists the requirements of the Operation, Administration, and Maintenance (OAM) features are recommended to provide availability and reliability on top of a collection of wireless segments. This document describes the benefits, problems, and trade-offs for using OAM in wireless networks to achieve Service Level Objectives (SLO). | ||||||||||||||||
| draft-ietf-raw-technologies-06.txt | |||||||||||||||||
| Reliable and Available Wireless Technologies | |||||||||||||||||
|
This document presents a series of recent technologies that are capable of time synchronization and scheduling of transmission, making them suitable to carry time-sensitive flows with high reliability and availability. | ||||||||||||||||
| draft-ietf-raw-use-cases-11.txt | |||||||||||||||||
| RAW Use-Cases | |||||||||||||||||
|
The wireless medium presents significant specific challenges to achieve properties similar to those of wired deterministic networks. At the same time, a number of use-cases cannot be solved with wires and justify the extra effort of going wireless. This document presents wireless use-cases (such as aeronautical communications, amusement parks, industrial applications, pro audio and video, gaming, UAV and V2V control, edge robotics and emergency vehicles) demanding reliable and available behavior. | ||||||||||||||||
| draft-ietf-regext-datadictionary-03.txt | |||||||||||||||||
| Registration Data Dictionary | |||||||||||||||||
|
Multiple applications related to the registration of names and other identifiers are built around a list of data elements. There is currently no unified public list of these data elements, nor is there an organized and independent change control process. This document compiles the multiple similar but not quite identical lists of data elements into a neutral Data Dictionary to be maintained as an independent IANA Registry. The Data Dictionary defines data elements but does not specify which ones are to be used in any particular application; the Data Dictionary is policy-neutral. | ||||||||||||||||
| draft-ietf-regext-epp-eai-18.txt | |||||||||||||||||
| Use of Internationalized Email Addresses in the Extensible Provisioning Protocol (EPP) | |||||||||||||||||
|
This document describes an EPP command-response extension that permits the usage of Internationalized Email Addresses in the EPP protocol and specifies the terms when it can be used by EPP clients and servers. The Extensible Provisioning Protocol (EPP), being developed before the standards for SMTPUTF8 compliant addresses, does not support such email addresses. TO BE REMOVED on turning to RFC: The document is edited in the dedicated github repo (https://github.com/beldmit/eppeai). Please send your submissions via GitHub. | ||||||||||||||||
| draft-ietf-regext-rdap-jscontact-15.txt | |||||||||||||||||
| Using JSContact in Registration Data Access Protocol (RDAP) JSON Responses | |||||||||||||||||
|
This document describes an RDAP extension which represents entity contact information in JSON responses using JSContact. | ||||||||||||||||
| draft-ietf-regext-rdap-openid-22.txt | |||||||||||||||||
| Federated Authentication for the Registration Data Access Protocol (RDAP) using OpenID Connect | |||||||||||||||||
|
The Registration Data Access Protocol (RDAP) provides "RESTful" web services to retrieve registration metadata from domain name and regional internet registries. RDAP allows a server to make access control decisions based on client identity, and as such it includes support for client identification features provided by the Hypertext Transfer Protocol (HTTP). Identification methods that require clients to obtain and manage credentials from every RDAP server operator present management challenges for both clients and servers, whereas a federated authentication system would make it easier to operate and use RDAP without the need to maintain server-specific client credentials. This document describes a federated authentication system for RDAP based on OpenID Connect. | ||||||||||||||||
| draft-ietf-regext-rdap-redacted-11.txt | |||||||||||||||||
| Redacted Fields in the Registration Data Access Protocol (RDAP) Response | |||||||||||||||||
|
This document describes an RDAP extension for specifying methods of redaction of RDAP responses and explicitly identifying redacted RDAP response fields, using JSONPath as the default expression language. | ||||||||||||||||
| draft-ietf-regext-rdap-reverse-search-21.txt | |||||||||||||||||
| Registration Data Access Protocol (RDAP) Reverse Search | |||||||||||||||||
|
The Registration Data Access Protocol (RDAP) does not include query capabilities for finding the list of domains related to a set of entities matching a given search pattern. Considering that an RDAP entity can be associated with any defined object class and other relationships between RDAP object classes exist, a reverse search can be applied to other use cases besides the classic domain-entity scenario. This document describes an RDAP extension that allows servers to provide a reverse search feature based on the relationship defined in RDAP between an object class for search and any related object class. The reverse search based on the domain-entity relationship is treated as a particular case. | ||||||||||||||||
| draft-ietf-regext-rdap-rir-search-01.txt | |||||||||||||||||
| RDAP RIR Search | |||||||||||||||||
|
The Registration Data Access Protocol (RDAP) is used by Internet Number Resource (INR) registries and domain name registries to provide access to their resource registration information. The core specifications for RDAP define basic search functionality, but there are various IP and ASN-related search options provided by INR registries via their Whois services for which there is no corresponding RDAP functionality. This document extends RDAP to support those search options. | ||||||||||||||||
| draft-ietf-rift-applicability-10.txt | |||||||||||||||||
| RIFT Applicability | |||||||||||||||||
|
This document discusses the properties, applicability and operational considerations of RIFT in different network scenarios. It intends to provide a rough guide how RIFT can be deployed to simplify routing operations in Clos topologies and their variations. | ||||||||||||||||
| draft-ietf-rift-kv-registry-05.txt | |||||||||||||||||
| RIFT Key/Value Structure and Registry | |||||||||||||||||
|
The RIFT (Routing in Fat-Trees) protocol allows for key/value pairs to be advertised within Key-Value Topology Information Elements (KV- TIEs). The data contained within these KV-TIEs can be used for any imaginable purpose. This document defines the various Key-Types (i.e. Well-Known, OUI, and Experimental) and a method to structure corresponding values. | ||||||||||||||||
| draft-ietf-rift-rift-17.txt | |||||||||||||||||
| RIFT: Routing in Fat Trees | |||||||||||||||||
|
This document defines a specialized, dynamic routing protocol for Clos and fat tree network topologies optimized towards minimization of control plane state as well as configuration and operational complexity. | ||||||||||||||||
| draft-ietf-rift-yang-06.txt | |||||||||||||||||
| A YANG Data Model for Routing in Fat Trees (RIFT) | |||||||||||||||||
|
This document defines a YANG data model for the configuration and management of Routing in Fat Trees (RIFT) Protocol. | ||||||||||||||||
| draft-ietf-rmcat-rtp-cc-feedback-12.txt | |||||||||||||||||
| Sending RTP Control Protocol (RTCP) Feedback for Congestion Control in Interactive Multimedia Conferences | |||||||||||||||||
|
This memo discusses the rate at which congestion control feedback can be sent using the RTP Control Protocol (RTCP) and its suitability for implementing congestion control for unicast multimedia applications. | ||||||||||||||||
| draft-ietf-roll-aodv-rpl-17.txt | |||||||||||||||||
| Supporting Asymmetric Links in Low Power Networks: AODV-RPL | |||||||||||||||||
|
Route discovery for symmetric and asymmetric Peer-to-Peer (P2P) traffic flows is a desirable feature in Low power and Lossy Networks (LLNs). For that purpose, this document specifies a reactive P2P route discovery mechanism for both hop-by-hop routes and source routing: Ad Hoc On-demand Distance Vector Routing (AODV) based RPL protocol (AODV-RPL). Paired Instances are used to construct directional paths, for cases where there are asymmetric links between source and target nodes. | ||||||||||||||||
| draft-ietf-roll-dao-projection-31.txt | |||||||||||||||||
| Root initiated routing state in RPL | |||||||||||||||||
|
This document extends RFC 6550, RFC 6553, and RFC 8138 to enable a RPL Root to install and maintain Projected Routes within its DODAG, along a selected set of nodes that may or may not include itself, for a chosen duration. This potentially enables routes that are more optimized or resilient than those obtained with the classical distributed operation of RPL, either in terms of the size of a Routing Header or in terms of path length, which impacts both the latency and the packet delivery ratio. | ||||||||||||||||
| draft-ietf-roll-nsa-extension-11.txt | |||||||||||||||||
| Common Ancestor Objective Function and Parent Set DAG Metric Container Extension | |||||||||||||||||
|
High reliability and low jitter can be achieved by being able to send data packets through multiple paths, via different parents, in a network. This document details how to exchange the necessary information within RPL control packets to let a node better select the different parents that will be used to forward a packet over different paths. This document also describes the Objective Function which takes advantage of this information to implement multi-path routing. | ||||||||||||||||
| draft-ietf-rtgwg-atn-bgp-19.txt | |||||||||||||||||
| A Simple BGP-based Mobile Routing System for the Aeronautical Telecommunications Network | |||||||||||||||||
|
The International Civil Aviation Organization (ICAO) is investigating mobile routing solutions for a worldwide Aeronautical Telecommunications Network with Internet Protocol Services (ATN/IPS). The ATN/IPS will eventually replace existing communication services with an IP-based service supporting pervasive Air Traffic Management (ATM) for Air Traffic Controllers (ATC), Airline Operations Controllers (AOC), and all commercial aircraft worldwide. This informational document describes a simple and extensible mobile routing service based on industry-standard BGP to address the ATN/IPS requirements. | ||||||||||||||||
| draft-ietf-rtgwg-bgp-pic-19.txt | |||||||||||||||||
| BGP Prefix Independent Convergence | |||||||||||||||||
|
In a network comprising thousands of BGP peers exchanging millions of routes, many routes are reachable via more than one next-hop. Given the large scaling targets, it is desirable to restore traffic after failure in a time period that does not depend on the number of BGP prefixes. This document describes an architecture by which traffic can be re- routed to equal cost multi-path (ECMP) or pre-calculated backup paths in a timeframe that does not depend on the number of BGP prefixes. The objective is achieved through organizing the forwarding data structures in a hierarchical manner and sharing forwarding elements among the maximum possible number of routes. The described technique yields prefix independent convergence while ensuring incremental deployment, complete automation, and zero management and provisioning effort. It is noteworthy to mention that the benefits of BGP Prefix Independent Convergence (BGP-PIC) are hinged on the existence of more than one path whether as ECMP or primary-backup. | ||||||||||||||||
| draft-ietf-rtgwg-net2cloud-problem-statement-25.txt | |||||||||||||||||
| Status of this Memo | |||||||||||||||||
|
This document describes the network-related problems enterprises face at the moment of writing this specification when interconnecting their branch offices with dynamic workloads in third-party data centers (a.k.a. Cloud DCs) and some mitigation practices. There can be many problems associated with connecting to or among Cloud DCs; the Net2Cloud problem statements are mainly for enterprises that already have traditional VPN services and are interested in leveraging those networks (instead of altogether abandoning them). Other problems are out of the scope of this document. This document also describes the mitigation practices for getting around the identified problems. | ||||||||||||||||
| draft-ietf-rtgwg-qos-model-10.txt | |||||||||||||||||
| YANG Models for Quality of Service (QoS) | |||||||||||||||||
|
This document describes a YANG model for configuration and operational data of Quality of Service (QoS) in network devices. | ||||||||||||||||
| draft-ietf-rtgwg-segment-routing-ti-lfa-09.txt | |||||||||||||||||
| Topology Independent Fast Reroute using Segment Routing | |||||||||||||||||
|
This document presents Topology Independent Loop-free Alternate Fast Re-route (TI-LFA), aimed at providing protection of node and adjacency segments within the Segment Routing (SR) framework. This Fast Re-route (FRR) behavior builds on proven IP-FRR concepts being LFAs, remote LFAs (RLFA), and remote LFAs with directed forwarding (DLFA). It extends these concepts to provide guaranteed coverage in any two connected network using a link-state IGP. A key aspect of TI-LFA is the FRR path selection approach establishing protection over the expected post-convergence paths from the point of local repair, reducing the operational need to control the tie-breaks among various FRR options. | ||||||||||||||||
| draft-ietf-rtgwg-srv6-egress-protection-09.txt | |||||||||||||||||
| SRv6 Path Egress Protection | |||||||||||||||||
|
This document describes protocol extensions for protecting the egress node of a Segment Routing for IPv6 (SRv6) path or tunnel. | ||||||||||||||||
| draft-ietf-rtgwg-vrrp-bfd-p2p-01.txt | |||||||||||||||||
| Fast failure detection in VRRP with Point to Point BFD | |||||||||||||||||
|
This document describes how Point to Point Bidirectional Forwarding Detection (BFD) can be used to support sub-second detection of a Active Router failure in the Virtual Router Redundancy Protocol (VRRP). | ||||||||||||||||
| draft-ietf-rtgwg-vrrp-p2mp-bfd-04.txt | |||||||||||||||||
| Applicability of Bidirectional Forwarding Detection (BFD) for Multi-point Networks in Virtual Router Redundancy Protocol (VRRP) | |||||||||||||||||
|
This document discusses the applicability of Bidirectional Forwarding Detection (BFD) for multipoint networks to provide Virtual Router Redundancy Protocol (VRRP) with sub-second convergence of the Active router and defines the extension to bootstrap point-to-multipoint BFD session. This draft updates RFC 5798. | ||||||||||||||||
| draft-ietf-rtgwg-vrrp-rfc5798bis-06.txt | |||||||||||||||||
| Virtual Router Redundancy Protocol (VRRP) Version 3 for IPv4 and IPv6 | |||||||||||||||||
|
This document defines version 3 of the Virtual Router Redundancy Protocol (VRRP) for IPv4 and IPv6. It is based on VRRP (version 2) for IPv4 that is defined in RFC 3768 and in "Virtual Router Redundancy Protocol for IPv6", and obsoletes the prevision specification of this version documented in RFC 5798. VRRP specifies an election protocol that dynamically assigns responsibility for a virtual router to one of the VRRP routers on a LAN. The VRRP router controlling the IPv4 or IPv6 address(es) associated with a virtual router is called the VRRP Active Router, and it forwards packets sent to these IPv4 or IPv6 addresses. VRRP Active Routers are configured with virtual IPv4 or IPv6 addresses, and VRRP Backup Routers infer the address family of the virtual addresses being advertised based on the IP protocol version. Within a VRRP router, the virtual routers in each of the IPv4 and IPv6 address families are independent of one another and always treated as separate virtual router instances. The election process provides dynamic failover in the forwarding responsibility should the Active Router become unavailable. For IPv4, the advantage gained from using VRRP is a higher-availability default path without requiring configuration of dynamic routing or router discovery protocols on every end-host. For IPv6, the advantage gained from using VRRP for IPv6 is a quicker switchover to Backup Routers than can be obtained with standard IPv6 Neighbor Discovery mechanisms. The VRRP terminology has been updated conform to inclusive language guidelines for IETF technologies. The IETF has designated National Institute of Standards and Technology (NIST) "Guidance for NIST Staff on Using Inclusive Language in Documentary Standards" for its inclusive language guidelines. | ||||||||||||||||
| draft-ietf-rtgwg-yang-rib-extend-14.txt | |||||||||||||||||
| RIB Extension YANG Data Model | |||||||||||||||||
|
A Routing Information Base (RIB) is a list of routes and their corresponding administrative data and operational state. RFC 8349 defines the basic building blocks for RIB, and this model augments it to support multiple next-hops (aka, paths) for each route as well as additional attributes. | ||||||||||||||||
| draft-ietf-sacm-coswid-24.txt | |||||||||||||||||
| Concise Software Identification Tags | |||||||||||||||||
|
ISO/IEC 19770-2:2015 Software Identification (SWID) tags provide an extensible XML-based structure to identify and describe individual software components, patches, and installation bundles. SWID tag representations can be too large for devices with network and storage constraints. This document defines a concise representation of SWID tags: Concise SWID (CoSWID) tags. CoSWID supports a similar set of semantics and features as SWID tags, as well as new semantics that allow CoSWIDs to describe additional types of information, all in a more memory efficient format. | ||||||||||||||||
| draft-ietf-schc-architecture-00.txt | |||||||||||||||||
| LPWAN Static Context Header Compression (SCHC) Architecture | |||||||||||||||||
|
This document defines the LPWAN SCHC architecture. | ||||||||||||||||
| draft-ietf-scim-cursor-pagination-00.txt | |||||||||||||||||
| Cursor-based Pagination of SCIM Resources | |||||||||||||||||
|
This document defines additional SCIM query parameters and result attributes to allow use of cursor-based pagination in SCIM implementations that are implemented with existing code bases, databases, or APIs where cursor-based pagination is already well- established. | ||||||||||||||||
| draft-ietf-scim-events-01.txt | |||||||||||||||||
| SCIM Profile for Security Event Tokens | |||||||||||||||||
|
This specification defines a set of Security Event types using the Security Event Token format (RFC8417). These events can be used across domains by SCIM Service Providers and receivers to exchange security event signals used for: request confirmations, replication, provisioning co-ordination, and security signals. | ||||||||||||||||
| draft-ietf-scim-roles-entitlements-00.txt | |||||||||||||||||
| SCIM Roles and Entitlements Extension | |||||||||||||||||
|
The System for Cross-domain Identity Management (SCIM) protocol's schema RFC RFC7643 (https://datatracker.ietf.org/doc/html/rfc7643) defines the complex core schema attributes "roles" and "entitlements". For both of these concepts, frequently only a predetermined set of values are accepted by a SCIM service provider. The values that are accepted may vary per customer or tenant based on customizable configuration in the service provider's application or based on other criteria such as what services have been purchased. This document defines an extension to the SCIM 2.0 standard to allow SCIM service providers to represent available data pertaining to roles and entitlements so that SCIM clients can consume this information and provide easier management of role and entitlement assignments. | ||||||||||||||||
| draft-ietf-scitt-architecture-01.txt | |||||||||||||||||
| An Architecture for Trustworthy and Transparent Digital Supply Chains | |||||||||||||||||
|
Traceability of physical and digital artifacts in supply chains is a long-standing, but increasingly serious security concern. The rise in popularity of verifiable data structures as a mechanism to make actors more accountable for breaching their compliance promises has found some successful applications to specific use cases (such as the supply chain for digital certificates), but lacks a generic and scalable architecture that can address a wider range of use cases. This memo defines a generic and scalable architecture to enable transparency across any supply chain with minimum adoption barriers for producers (who can register their Signed Statements on any Transparency Service, with the guarantee that all consumers will be able to verify them) and enough flexibility to allow different implementations of Transparency Services with various auditing and compliance requirements. | ||||||||||||||||
| draft-ietf-scitt-software-use-cases-00.txt | |||||||||||||||||
| Detailed Software Supply Chain Uses Cases for SCITT | |||||||||||||||||
|
This document includes a collection of representative Software Supply Chain Use Case Descriptions. These use cases aim to identify software supply chain problems that the industry faces today and acts as a guideline for developing a comprehensive solution for these classes of scenarios. | ||||||||||||||||
| draft-ietf-secevent-subject-identifiers-16.txt | |||||||||||||||||
| Subject Identifiers for Security Event Tokens | |||||||||||||||||
|
Security events communicated within Security Event Tokens may support a variety of identifiers to identify subjects related to the event. This specification formalizes the notion of subject identifiers as structured information that describe a subject, and named formats that define the syntax and semantics for encoding subject identifiers as JSON objects. It also defines a registry for defining and allocating names for such formats, as well as the sub_id JSON Web Token (JWT) claim. | ||||||||||||||||
| draft-ietf-sedate-datetime-extended-07.txt | |||||||||||||||||
| Date and Time on the Internet: Timestamps with additional information | |||||||||||||||||
|
This document defines an extension to the timestamp format defined in RFC3339 for representing additional information including a time zone. It updates RFC3339 in the specific interpretation of the local offset Z, which is no longer understood to "imply that UTC is the preferred reference point for the specified time"; see Section 2. // The present version (-07) reflects the WGLC comments. In // particular, information has been added to the Security // Considerations section. | ||||||||||||||||
| draft-ietf-sfc-ioam-nsh-11.txt | |||||||||||||||||
| Network Service Header (NSH) Encapsulation for In-situ OAM (IOAM) Data | |||||||||||||||||
|
In-situ Operations, Administration, and Maintenance (IOAM) is used for recording and collecting operational and telemetry information while the packet traverses a path between two points in the network. This document outlines how IOAM data fields are encapsulated with the Network Service Header (NSH). | ||||||||||||||||
| draft-ietf-sfc-multi-layer-oam-23.txt | |||||||||||||||||
| Active OAM for Service Function Chaining (SFC) | |||||||||||||||||
|
A set of requirements for active Operation, Administration, and Maintenance (OAM) of Service Function Chains (SFCs) in a network is presented in this document. Based on these requirements, an encapsulation of active OAM messages in SFC and a mechanism to detect and localize defects are described. | ||||||||||||||||
| draft-ietf-sfc-oam-packet-03.txt | |||||||||||||||||
| OAM Packet and Behavior in the Network Service Header (NSH) | |||||||||||||||||
|
This document clarifies an ambiguity in the Network Service Header (NSH) specification related to the handling of O bit. In particular, this document clarifies the meaning of "OAM packet". This document updates RFC 8300. | ||||||||||||||||
| draft-ietf-sframe-enc-01.txt | |||||||||||||||||
| Secure Frame (SFrame) | |||||||||||||||||
|
This document describes the Secure Frame (SFrame) end-to-end encryption and authentication mechanism for media frames in a multiparty conference call, in which central media servers (selective forwarding units or SFUs) can access the media metadata needed to make forwarding decisions without having access to the actual media. The proposed mechanism differs from the Secure Real-Time Protocol (SRTP) in that it is independent of RTP (thus compatible with non-RTP media transport) and can be applied to whole media frames in order to be more bandwidth efficient. | ||||||||||||||||
| draft-ietf-shmoo-online-meeting-05.txt | |||||||||||||||||
| Guidelines for the Organization of Fully Online Meetings | |||||||||||||||||
|
This document provides guidelines for the planning and organization of fully online meetings, regarding the number, length, and composition of sessions on the meeting agenda. These guidelines are based on the experience with online meetings during the COVID-19 pandemic in 2020 and 2021. | ||||||||||||||||
| draft-ietf-shmoo-remote-fee-06.txt | |||||||||||||||||
| Open Participation Principle regarding Remote Registration Fee | |||||||||||||||||
|
This document outlines a principle for open participation that extends the open process principle defined in RFC3935 by stating that there must be a free option for online participation to IETF meetings and, if possible, related IETF-hosted events over the Internet. | ||||||||||||||||
| draft-ietf-sidrops-8210bis-10.txt | |||||||||||||||||
| The Resource Public Key Infrastructure (RPKI) to Router Protocol,Version 2 | |||||||||||||||||
|
In order to verifiably validate the origin Autonomous Systems and Autonomous System Paths of BGP announcements, routers need a simple but reliable mechanism to receive Resource Public Key Infrastructure (RFC 6480) prefix origin data and router keys from a trusted cache. This document describes a protocol to deliver them. This document describes version 2 of the RPKI-Router protocol. RFC 6810 describes version 0, and RFC 8210 describes version 1. This document is compatible with both. | ||||||||||||||||
| draft-ietf-sidrops-aspa-profile-12.txt | |||||||||||||||||
| A Profile for Autonomous System Provider Authorization | |||||||||||||||||
|
This document defines a Cryptographic Message Syntax (CMS) protected content type for Autonomous System Provider Authorization (ASPA) objects for use with the Resource Public Key Infrastructure (RPKI). An ASPA is a digitally signed object through which the issuer (the holder of an Autonomous System identifier), can authorize one or more other Autonomous Systems (ASes) as its upstream providers. When validated, an ASPA's eContent can be used for detection and mitigation of route leaks. | ||||||||||||||||
| draft-ietf-sidrops-aspa-verification-14.txt | |||||||||||||||||
| BGP AS_PATH Verification Based on Autonomous System Provider Authorization (ASPA) Objects | |||||||||||||||||
|
This document describes procedures that make use of Autonomous System Provider Authorization (ASPA) objects in the Resource Public Key Infrastructure (RPKI) to verify the Border Gateway Protocol (BGP) AS_PATH attribute of advertised routes. This type of AS_PATH verification provides detection and mitigation of route leaks and improbable AS paths. It also to some degree provides protection against prefix hijacks with forged-origin or forged-path-segment. | ||||||||||||||||
| draft-ietf-sidrops-bar-sav-01.txt | |||||||||||||||||
| Source Address Validation Using BGP UPDATEs,ASPA,and ROA (BAR-SAV) | |||||||||||||||||
|
Designing an efficient source address validation (SAV) filter requires minimizing false positives (i.e., avoiding blocking legitimate traffic) while maintaining directionality (see RFC8704). This document advances the technology for SAV filter design through a method that makes use of BGP UPDATE messages, Autonomous System Provider Authorization (ASPA), and Route Origin Authorization (ROA). The proposed method's name is abbreviated as BAR-SAV. BAR-SAV can be used by network operators to derive more robust SAV filters and thus improve network resilience. This document updates RFC8704. | ||||||||||||||||
| draft-ietf-sidrops-lta-use-cases-06.txt | |||||||||||||||||
| Use Cases for Localized Versions of the RPKI | |||||||||||||||||
|
There are a number of critical circumstances where a localized routing domain needs to augment or modify its view of the Global RPKI. This document attempts to outline a few of them. | ||||||||||||||||
| draft-ietf-sidrops-prefer-rrdp-02.txt | |||||||||||||||||
| Resource Public Key Infrastructure (RPKI) Repository Requirements | |||||||||||||||||
|
This document formulates a plan of a phased transition to a state where RPKI repositories and Relying Party software performing RPKI Validation will use the RPKI Repository Delta Protocol (RRDP) [RFC8182] as the preferred access protocol, and require rsync as a fallback option only. In phase 0, today's deployment, RRDP is supported by most, but not all Repositories, and most but not all RP software. In the proposed phase 1 RRDP will become mandatory to implement for Repositories, in addition to rsync. This phase can start as soon as this document is published. Phase 2 will start once the proposed updates are implemented by all compliant Repositories. In this phase RRDP will become mandatory to implement for all compliant RP software, and rsync will be required as a fallback option only. It should be noted that although this document currently includes descriptions and updates to RFCs for each of these phases, we may find that it will be beneficial to have one or more separate documents for these phases, so that it might be more clear to all when the updates to RFCs take effect. | ||||||||||||||||
| draft-ietf-sidrops-rfc6482bis-02.txt | |||||||||||||||||
| A Profile for Route Origin Authorizations (ROAs) | |||||||||||||||||
|
This document defines a standard profile for Route Origin Authorizations (ROAs). A ROA is a digitally signed object that provides a means of verifying that an IP address block holder has authorized an Autonomous System (AS) to originate routes to one or more prefixes within the address block. This document obsoletes RFC 6482. | ||||||||||||||||
| draft-ietf-sidrops-roa-considerations-07.txt | |||||||||||||||||
| Avoidance for ROA Containing Multiple IP Prefixes | |||||||||||||||||
|
When using the RPKI, address space holders need to issue ROA object(s) to authorize one or more ASes to originate routes to IP prefix(es). This memo discusses operational problems which may arise from ROAs containing multiple IP prefixes and recommends that each ROA contain a single IP prefix. | ||||||||||||||||
| draft-ietf-sidrops-signed-tal-13.txt | |||||||||||||||||
| RPKI Signed Object for Trust Anchor Key | |||||||||||||||||
|
A Trust Anchor Locator (TAL) is used by Relying Parties (RPs) in the Resource Public Key Infrastructure (RPKI) to locate and validate a Trust Anchor (TA) Certification Authority (CA) certificate used in RPKI validation. This document defines an RPKI signed object for a Trust Anchor Key (TAK), that can be used by a TA to signal the location(s) of the accompanying CA certificate for the current key to RPs, as well as the successor key and the location(s) of its CA certificate. This object helps to support planned key rolls without impacting RPKI validation. | ||||||||||||||||
| draft-ietf-sipcore-callinfo-rcd-05.txt | |||||||||||||||||
| SIP Call-Info Parameters for Rich Call Data | |||||||||||||||||
|
This document describes a SIP Call-Info header field usage defined to include Rich Call Data (RCD) associated with the identity of the calling party that can be rendered to a called party for providing more descriptive information about the caller or more details about the reason for the call. This includes extended information about the caller beyond the telephone number such as a calling name, a logo or photo representing the caller or a jCard object representing the calling party. The elements defined for this purpose are intended to be extensible to accommodate related information about calls that helps people decide whether to pick up the phone and with the use of icon and newly defined jCard and other elements to be compatible and complimentary with the STIR/PASSporT Rich Call Data framework. | ||||||||||||||||
| draft-ietf-sipcore-callinfo-spam-04.txt | |||||||||||||||||
| SIP Call-Info Parameters for Labeling Calls | |||||||||||||||||
|
Called parties often wish to decide whether to accept, reject or redirect calls based on the likely nature of the call. For example, they may want to reject unwanted telemarketing or fraudulent calls, but accept emergency alerts from numbers not in their address book. This document describes SIP Call-Info parameters and a feature tag that allow originating, intermediate and terminating SIP entities to label calls as to their type, confidence and references to additional information. | ||||||||||||||||
| draft-ietf-snac-simple-01.txt | |||||||||||||||||
| Automatically Connecting Stub Networks to Unmanaged Infrastructure | |||||||||||||||||
|
This document describes a set of practices for connecting stub networks to adjacent infrastructure networks. This is applicable in cases such as constrained (Internet of Things) networks where there is a need to provide functional parity of service discovery and reachability between devices on the stub network and devices on an adjacent infrastructure link (for example, a home network). | ||||||||||||||||
| draft-ietf-spring-bfd-06.txt | |||||||||||||||||
| Bidirectional Forwarding Detection (BFD) in Segment Routing Networks Using MPLS Dataplane | |||||||||||||||||
|
Segment Routing (SR) architecture leverages the paradigm of source routing. It can be realized in the Multiprotocol Label Switching (MPLS) network without any change to the data plane. A segment is encoded as an MPLS label, and an ordered list of segments is encoded as a stack of labels. Bidirectional Forwarding Detection (BFD) is expected to monitor any existing path between systems. This document defines how to use Label Switched Path Ping to bootstrap a BFD session, control an SR Policy in the reverse direction of the SR-MPLS tunnel, and applicability of BFD Demand mode in the SR-MPLS domain. Also, the document describes the use of BFD Echo with BFD Control packet payload. | ||||||||||||||||
| draft-ietf-spring-compression-analysis-03.txt | |||||||||||||||||
| Compressed SRv6 SID List Analysis | |||||||||||||||||
|
Several mechanisms have been proposed to compress the SRv6 SID list. This document analyzes each mechanism with regard to the requirements stated in the companion requirements document. | ||||||||||||||||
| draft-ietf-spring-compression-requirement-03.txt | |||||||||||||||||
| Compressed SRv6 SID List Requirements | |||||||||||||||||
|
This document specifies requirements for solutions to compress SRv6 SID lists. | ||||||||||||||||
| draft-ietf-spring-mpls-path-segment-08.txt | |||||||||||||||||
| Path Segment in MPLS Based Segment Routing Network | |||||||||||||||||
|
A Segment Routing (SR) path is identified by an SR segment list. Only the complete segment list can identify the end-to-end SR path, and a sub-set of segments from the segment list cannot distinguish one SR path from another as they may be partially congruent. SR path identification is a pre-requisite for various use-cases such as Performance Measurement (PM), bidirectional paths correlation, and end-to-end 1+1 path protection. In SR for MPLS data plane (SR-MPLS), the segment identifiers are stripped from the packet through label popping as the packet transits the network. This means that when a packet reaches the egress of the SR path, it is not possible to determine on which SR path it traversed the network. This document defines a new type of segment that is referred to as Path Segment, which is used to identify an SR path in an SR-MPLS network. When used, it is inserted by the ingress node of the SR path and immediately follows the last segment identifier in the segment list of the SR path. The Path Segment is preserved until it reaches the egress node for SR path identification and correlation. | ||||||||||||||||
| draft-ietf-spring-nsh-sr-12.txt | |||||||||||||||||
| Integration of Network Service Header (NSH) and Segment Routing for Service Function Chaining (SFC) | |||||||||||||||||
|
This document describes the integration of the Network Service Header (NSH) and Segment Routing (SR), as well as encapsulation details, to support Service Function Chaining (SFC) in an efficient manner while maintaining separation of the service and transport planes as originally intended by the SFC architecture. Combining these technologies allows SR to be used for steering packets between Service Function Forwarders (SFF) along a given Service Function Path (SFP) while NSH has the responsibility for maintaining the integrity of the service plane, the SFC instance context, and any associated metadata. This integration demonstrates that NSH and SR can work cooperatively and provide a network operator with the flexibility to use whichever transport technology makes sense in specific areas of their network infrastructure while still maintaining an end-to-end service plane using NSH. | ||||||||||||||||
| draft-ietf-spring-segment-protection-sr-te-paths-04.txt | |||||||||||||||||
| Segment Protection for SR-TE Paths | |||||||||||||||||
|
Segment routing supports the creation of explicit paths using Adj- Segment-ID (SID), Node-SIDs, and BSIDs. It is important to provide fast reroute (FRR) mechanisms to respond to failures of links and nodes in the Segment-Routed Traffic-Engineered(SR-TE) path. A point of local repair (PLR) can provide FRR protection against the failure of a link in an SR-TE path by examining only the first (top) label in the SR label stack. In order to protect against the failure of a node, a PLR may need to examine the second label in the stack as well, in order to determine SR-TE path beyond the failed node. This document specifies how a PLR can use the first and second label in the SR-MPLS label stack describing an SR-TE path to provide protection against node failures. | ||||||||||||||||
| draft-ietf-spring-sr-replication-segment-13.txt | |||||||||||||||||
| SR Replication Segment for Multi-point Service Delivery | |||||||||||||||||
|
This document describes the SR Replication segment for Multi-point service delivery. A SR Replication segment allows a packet to be replicated from a Replication Node to Downstream nodes. | ||||||||||||||||
| draft-ietf-spring-sr-service-programming-07.txt | |||||||||||||||||
| Service Programming with Segment Routing | |||||||||||||||||
|
This document defines data plane functionality required to implement service segments and achieve service programming in SR-enabled MPLS and IPv6 networks, as described in the Segment Routing architecture. | ||||||||||||||||
| draft-ietf-spring-srv6-path-segment-05.txt | |||||||||||||||||
| Path Segment for SRv6 (Segment Routing in IPv6) | |||||||||||||||||
|
Segment Routing (SR) allows for a flexible definition of end-to-end paths by encoding an ordered list of instructions, called "segments". The SR architecture can be implemented over an MPLS data plane as well as an IPv6 data plane. Currently, Path Segment has been defined to identify an SR path in SR-MPLS networks, and is used for various use-cases such as end-to- end SR Path Protection and Performance Measurement (PM) of an SR path. This document defines the Path Segment to identify an SRv6 path in an IPv6 network. | ||||||||||||||||
| draft-ietf-spring-srv6-srh-compression-04.txt | |||||||||||||||||
| Compressed SRv6 Segment List Encoding in SRH | |||||||||||||||||
|
This document specifies new flavors for the SR endpoint behaviors defined in RFC 8986, which enable a compressed SRv6 Segment-List encoding in the Segment Routing Header (SRH). | ||||||||||||||||
| draft-ietf-spring-stamp-srpm-06.txt | |||||||||||||||||
| Performance Measurement Using Simple TWAMP (STAMP) for Segment Routing Networks | |||||||||||||||||
|
Segment Routing (SR) leverages the source routing paradigm. SR is applicable to both Multiprotocol Label Switching (SR-MPLS) and IPv6 (SRv6) data planes. This document describes procedures for Performance Measurement in SR networks using the mechanisms defined in RFC 8762 (Simple Two-Way Active Measurement Protocol (STAMP)) and its optional extensions defined in RFC 8972 and further augmented in draft-ietf-ippm-stamp-srpm. The procedure described is applicable to SR-MPLS and SRv6 data planes and is used for both links and end-to- end SR paths including SR Policies. | ||||||||||||||||
| draft-ietf-stir-certificates-ocsp-03.txt | |||||||||||||||||
| OCSP Usage for Secure Telephone Identity Certificates | |||||||||||||||||
|
When certificates are used as credentials to attest the assignment or ownership of telephone numbers, some mechanism is required to convey certificate freshness to relying parties. Certififcate Revocation Lists (CRLs) are commonly used for this purpose, but for certain classes of certificates, including delegate certificates conveying their scope of authority by-reference in Secure Telephone Identity Revisited (STIR) systems, they may not be aligned with the needs of relying parties. This document specifies the use of the Online Certificate Status Protocol (OCSP) as a means of retrieving real-time status information about such certificates, defining new extensions to compensate for the dynamism of telephone number assignments. | ||||||||||||||||
| draft-ietf-stir-identity-header-errors-handling-08.txt | |||||||||||||||||
| Identity Header Errors Handling for STIR | |||||||||||||||||
|
This document extends STIR and the Authenticated Identity Management in the Session Initiation Protocol (SIP) error handling procedures to include the mapping of verification failure reasons to STIR defined 4xx codes so the failure reason of an Identity header field can be conveyed to the upstream authentication service when local policy dictates that the call should continue in the presence of a verification failure. This document also defines procedures that enable a failure reason to be mapped to a specific Identity header field for scenarios that use multiple Identity header fields where some may have errors and others may not and the handling of those situations is defined. | ||||||||||||||||
| draft-ietf-stir-messaging-07.txt | |||||||||||||||||
| Messaging Use Cases and Extensions for STIR | |||||||||||||||||
|
Secure Telephone Identity Revisited (STIR) provides a means of attesting the identity of a telephone caller via a signed token in order to prevent impersonation of a calling party number, which is a key enabler for illegal robocalling. Similar impersonation is sometimes leveraged by bad actors in the text and multimedia messaging space. This document explores the applicability of STIR's Personal Assertion Token (PASSporT) and certificate issuance framework to text and multimedia messaging use cases, including support both for messages carried as a payload in SIP requests and for messages sent in sessions negotiated by SIP. | ||||||||||||||||
| draft-ietf-stir-passport-rcd-24.txt | |||||||||||||||||
| PASSporT Extension for Rich Call Data | |||||||||||||||||
|
This document extends PASSporT, a token for conveying cryptographically-signed call information about personal communications, to include rich meta-data about a call and caller that can be signed and integrity protected, transmitted, and subsequently rendered to the called party. This framework is intended to include and extend caller and call specific information beyond human-readable display name comparable to the "Caller ID" function common on the telephone network and is also enhanced with a integrity mechanism that is designed to protect the authoring and transport of this information for different authoritative use-cases. | ||||||||||||||||
| draft-ietf-stir-rfc4916-update-02.txt | |||||||||||||||||
| Connected Identity for STIR | |||||||||||||||||
|
The SIP Identity header conveys cryptographic identity information about the originators of SIP requests. The Secure Telephone Identity Revisited (STIR) framework however provides no means for determining the identity of the called party in a traditional telephone calling scenario. This document updates prior guidance on the "connected identity" problem to reflect the changes to SIP Identity that accompanied STIR, and considers a revised problem space for connected identity as a means of detecting calls that have been retargeted to a party impersonating the intended destination, as well as the spoofing of mid-dialog or dialog-terminating events by intermediaries or third parties. | ||||||||||||||||
| draft-ietf-stir-servprovider-oob-04.txt | |||||||||||||||||
| Out-of-Band STIR for Service Providers | |||||||||||||||||
|
The Secure Telephone Identity Revisited (STIR) framework defines means of carrying its Persona Assertion Tokens (PASSporTs) either in- band, within the headers of a SIP request, or out-of-band, through a service that stores PASSporTs for retrieval by relying parties. This specification defines a way that the out-of-band conveyance of PASSporTs can be used to support large service providers, for cases in which in-band STIR conveyance is not universally available. | ||||||||||||||||
| draft-ietf-suit-firmware-encryption-12.txt | |||||||||||||||||
| Encrypted Payloads in SUIT Manifests | |||||||||||||||||
|
This document specifies techniques for encrypting software, firmware and personalization data by utilizing the IETF SUIT manifest. Key agreement is provided by ephemeral-static (ES) Diffie-Hellman (DH) and AES Key Wrap (AES-KW). ES-DH uses public key cryptography while AES-KW uses a pre-shared key-encryption key. Encryption of the plaintext is accomplished with conventional symmetric key cryptography. | ||||||||||||||||
| draft-ietf-suit-manifest-22.txt | |||||||||||||||||
| A Concise Binary Object Representation (CBOR)-based Serialization Format for the Software Updates for Internet of Things (SUIT) Manifest | |||||||||||||||||
|
This specification describes the format of a manifest. A manifest is a bundle of metadata about code/data obtained by a recipient (chiefly the firmware for an IoT device), where to find the that code/data, the devices to which it applies, and cryptographic information protecting the manifest. Software updates and Trusted Invocation both tend to use sequences of common operations, so the manifest encodes those sequences of operations, rather than declaring the metadata. | ||||||||||||||||
| draft-ietf-suit-mti-00.txt | |||||||||||||||||
| Mandatory-to-Implement Algorithms for Authors and Recipients of Software Update for the Internet of Things manifests | |||||||||||||||||
|
This document specifies algorithm profiles for SUIT manifest parsers and authors to ensure better interoperability. These profiles apply specifically to a constrained node software update use case. | ||||||||||||||||
| draft-ietf-suit-mud-03.txt | |||||||||||||||||
| Strong Assertions of IoT Network Access Requirements | |||||||||||||||||
|
The Manufacturer Usage Description (MUD) specification describes the access and network functionality required a device to properly function. The MUD description has to reflect the software running on the device and its configuration. Because of this, the most appropriate entity for describing device network access requirements is the same as the entity developing the software and its configuration. A network presented with a MUD file by a device allows detection of misbehavior by the device software and configuration of access control. This document defines a way to link a SUIT manifest to a MUD file offering a stronger binding between the two. | ||||||||||||||||
| draft-ietf-suit-report-05.txt | |||||||||||||||||
| Secure Reporting of Update Status | |||||||||||||||||
|
The Software Update for the Internet of Things (SUIT) manifest provides a way for many different update and boot workflows to be described by a common format. However, this does not provide a feedback mechanism for developers in the event that an update or boot fails. This specification describes a lightweight feedback mechanism that allows a developer in possession of a manifest to reconstruct the decisions made and actions performed by a manifest processor. | ||||||||||||||||
| draft-ietf-suit-trust-domains-02.txt | |||||||||||||||||
| SUIT Manifest Extensions for Multiple Trust Domains | |||||||||||||||||
|
This specification describes extensions to the SUIT manifest format (as defined in [I-D.ietf-suit-manifest]) for use in deployments with multiple trust domains. A device has more than one trust domain when it enables delegation of different rights to mutually distrusting entities for use for different purposes or components in the context of firmware or software update. | ||||||||||||||||
| draft-ietf-suit-update-management-01.txt | |||||||||||||||||
| Update Management Extensions for Software Updates for Internet of Things (SUIT) Manifests | |||||||||||||||||
|
This specification describes extensions to the SUIT manifest format defined in [I-D.ietf-suit-manifest]. These extensions allow an update author, update distributor or device operator to more precisely control the distribution and installation of updates to IoT devices. These extensions also provide a mechanism to inform a management system of Software Identifier and Software Bill Of Materials information about an updated device. | ||||||||||||||||
| draft-ietf-taps-arch-17.txt | |||||||||||||||||
| An Architecture for Transport Services | |||||||||||||||||
|
This document describes an architecture for exposing transport protocol features to applications for network communication, a Transport Services system. The Transport Services Application Programming Interface (API) is based on an asynchronous, event-driven interaction pattern. This API uses messages for representing data transfer to applications, and describes how implementations can use multiple IP addresses, multiple protocols, and multiple paths, and provide multiple application streams. This document further defines common terminology and concepts to be used in definitions of a Transport Service API and a Transport Services implementation. | ||||||||||||||||
| draft-ietf-taps-impl-15.txt | |||||||||||||||||
| Implementing Interfaces to Transport Services | |||||||||||||||||
|
The Transport Services system enables applications to use transport protocols flexibly for network communication and defines a protocol- independent Transport Services Application Programming Interface (API) that is based on an asynchronous, event-driven interaction pattern. This document serves as a guide to implementation on how to build such a system. | ||||||||||||||||
| draft-ietf-taps-interface-20.txt | |||||||||||||||||
| An Abstract Application Layer Interface to Transport Services | |||||||||||||||||
|
This document describes an abstract application programming interface, API, to the transport layer that enables the selection of transport protocols and network paths dynamically at runtime. This API enables faster deployment of new protocols and protocol features without requiring changes to the applications. The specified API follows the Transport Services architecture by providing asynchronous, atomic transmission of messages. It is intended to replace the BSD sockets API as the common interface to the transport layer, in an environment where endpoints could select from multiple interfaces and potential transport protocols. | ||||||||||||||||
| draft-ietf-tcpm-accurate-ecn-24.txt | |||||||||||||||||
| More Accurate Explicit Congestion Notification (ECN) Feedback in TCP | |||||||||||||||||
|
Explicit Congestion Notification (ECN) is a mechanism where network nodes can mark IP packets instead of dropping them to indicate incipient congestion to the endpoints. Receivers with an ECN-capable transport protocol feed back this information to the sender. ECN was originally specified for TCP in such a way that only one feedback signal can be transmitted per Round-Trip Time (RTT). Recent new TCP mechanisms like Congestion Exposure (ConEx), Data Center TCP (DCTCP) or Low Latency, Low Loss, and Scalable Throughput (L4S) need more accurate ECN feedback information whenever more than one marking is received in one RTT. This document updates the original ECN specification in RFC 3168 to specify a scheme that provides more than one feedback signal per RTT in the TCP header. Given TCP header space is scarce, it allocates a reserved header bit previously assigned to the ECN-Nonce. It also overloads the two existing ECN flags in the TCP header. The resulting extra space is exploited to feed back the IP-ECN field received during the 3-way handshake as well. Supplementary feedback information can optionally be provided in two new TCP option alternatives, which are never used on the TCP SYN. The document also specifies the treatment of this updated TCP wire protocol by middleboxes. | ||||||||||||||||
| draft-ietf-tcpm-ack-rate-request-01.txt | |||||||||||||||||
| TCP ACK Rate Request Option | |||||||||||||||||
|
TCP Delayed Acknowledgments (ACKs) is a widely deployed mechanism that allows reducing protocol overhead in many scenarios. However, Delayed ACKs may also contribute to suboptimal performance. When a relatively large congestion window (cwnd) can be used, less frequent ACKs may be desirable. On the other hand, in relatively small cwnd scenarios, eliciting an immediate ACK may avoid unnecessary delays that may be incurred by the Delayed ACKs mechanism. This document specifies the TCP ACK Rate Request (TARR) option. This option allows a sender to request the ACK rate to be used by a receiver, and it also allows to request immediate ACKs from a receiver. | ||||||||||||||||
| draft-ietf-tcpm-generalized-ecn-11.txt | |||||||||||||||||
| ECN++: Adding Explicit Congestion Notification (ECN) to TCP Control Packets | |||||||||||||||||
|
This document specifies an experimental modification to ECN when used with TCP. It allows the use of ECN in the IP header of the following TCP packets: SYNs, SYN/ACKs, pure ACKs, Window probes, FINs, RSTs and retransmissions. This specification obsoletes RFC5562, which described a different way to use ECN on SYN/ACKs alone. | ||||||||||||||||
| draft-ietf-tcpm-hystartplusplus-14.txt | |||||||||||||||||
| HyStart++: Modified Slow Start for TCP | |||||||||||||||||
|
This document describes HyStart++, a simple modification to the slow start phase of congestion control algorithms. Slow start can overshoot the ideal send rate in many cases, causing high packet loss and poor performance. HyStart++ uses increase in round-trip delay as a heuristic to find an exit point before possible overshoot. It also adds a mitigation to prevent jitter from causing premature slow start exit. | ||||||||||||||||
| draft-ietf-tcpm-prr-rfc6937bis-03.txt | |||||||||||||||||
| Proportional Rate Reduction for TCP | |||||||||||||||||
|
This document updates the experimental Proportional Rate Reduction (PRR) algorithm, described RFC 6937, to standards track. PRR potentially replaces the Fast Recovery to regulate the amount of data sent by TCP or other transport protocol during loss recovery. PRR accurately regulates the actual flight size through recovery such that at the end of recovery it will be as close as possible to the slow start threshold (ssthresh), as determined by the congestion control algorithm. | ||||||||||||||||
| draft-ietf-tcpm-rfc8312bis-15.txt | |||||||||||||||||
| CUBIC for Fast and Long-Distance Networks | |||||||||||||||||
|
CUBIC is a standard TCP congestion control algorithm that uses a cubic function instead of a linear congestion window increase function to improve scalability and stability over fast and long- distance networks. CUBIC has been adopted as the default TCP congestion control algorithm by the Linux, Windows, and Apple stacks. This document updates the specification of CUBIC to include algorithmic improvements based on these implementations and recent academic work. Based on the extensive deployment experience with CUBIC, it also moves the specification to the Standards Track, obsoleting RFC 8312. This also requires updating RFC 5681, to allow for CUBIC's occasionally more aggressive sending behavior. | ||||||||||||||||
| draft-ietf-tcpm-tcp-edo-13.txt | |||||||||||||||||
| TCP Extended Data Offset Option | |||||||||||||||||
|
TCP segments include a Data Offset field to indicate space for TCP options but the size of the field can limit the space available for complex options such as SACK and Multipath TCP and can limit the combination of such options supported in a single connection. This document updates RFC 9293 with an optional TCP extension to that space to support the use of multiple large options. It also explains why the initial SYN of a connection cannot be extending a single segment. | ||||||||||||||||
| draft-ietf-tcpm-yang-tcp-09.txt | |||||||||||||||||
| A YANG Model for Transmission Control Protocol (TCP) Configuration and State | |||||||||||||||||
|
This document specifies a minimal YANG model for TCP on devices that are configured and managed by network management protocols. The YANG model defines a container for all TCP connections, and groupings of authentication parameters that can be imported and used in TCP implementations or by other models that need to configure TCP parameters. The model also includes basic TCP statistics. The model is compliant with Network Management Datastore Architecture (NMDA) (RFC 8342). | ||||||||||||||||
| draft-ietf-teas-actn-pm-telemetry-autonomics-10.txt | |||||||||||||||||
| YANG models for Virtual Network (VN)/TE Performance Monitoring Telemetry and Scaling Intent Autonomics | |||||||||||||||||
|
This document provides YANG data models that describe performance monitoring parameters and scaling intent mechanisms for TE-tunnels and Virtual Networks (VNs). There performance monitoring parameters are exposed as the key telemetry data for tunnels and VN. The models presented in this document allow customers to subscribe to and monitor the key performance data of the TE-tunnel or the VN. The models also provide customers with the ability to program autonomic scaling intent mechanisms on the level of TE-tunnel as well as VN. | ||||||||||||||||
| draft-ietf-teas-actn-poi-applicability-08.txt | |||||||||||||||||
| Applicability of Abstraction and Control of Traffic Engineered Networks (ACTN) to Packet Optical Integration (POI) | |||||||||||||||||
|
This document considers the applicability of Abstraction and Control of TE Networks (ACTN) architecture to Packet Optical Integration (POI)in the context of IP/MPLS and optical internetworking. It identifies the YANG data models defined by the IETF to support this deployment architecture and specific scenarios relevant to Service Providers. Existing IETF protocols and data models are identified for each multi-layer (packet over optical) scenario with a specific focus on the MPI (Multi-Domain Service Coordinator to Provisioning Network Controllers Interface)in the ACTN architecture. | ||||||||||||||||
| draft-ietf-teas-actn-vn-yang-18.txt | |||||||||||||||||
| A YANG Data Model for Virtual Network (VN) Operations | |||||||||||||||||
|
This document provides a YANG data model generally applicable to any mode of Virtual Network (VN) operations. | ||||||||||||||||
| draft-ietf-teas-actn-yang-11.txt | |||||||||||||||||
| Applicability of YANG models for Abstraction and Control of Traffic Engineered Networks | |||||||||||||||||
|
Abstraction and Control of TE Networks (ACTN) refers to the set of virtual network operations needed to orchestrate, control and manage large-scale multi-domain TE networks, so as to facilitate network programmability, automation, efficient resource sharing, and end-to- end virtual service aware connectivity and network function virtualization services. This document explains how the different types of YANG models defined in the Operations and Management Area and in the Routing Area are applicable to the ACTN framework. This document also shows how the ACTN architecture can be satisfied using classes of data model that have already been defined, and discusses the applicability of specific data models that are under development. It also highlights where new data models may need to be developed. | ||||||||||||||||
| draft-ietf-teas-applicability-actn-slicing-03.txt | |||||||||||||||||
| Applicability of Abstraction and Control of Traffic Engineered Networks (ACTN) to Network Slicing | |||||||||||||||||
|
Network abstraction is a technique that can be applied to a network domain to obtain a view of potential connectivity across the network by utilizing a set of policies to select network resources. Network slicing is an approach to network operations that builds on the concept of network abstraction to provide programmability, flexibility, and modularity. It may use techniques such as Software Defined Networking (SDN) and Network Function Virtualization (NFV) to create multiple logical or virtual networks, each tailored for a set of services that share the same set of requirements. Abstraction and Control of Traffic Engineered Networks (ACTN) is described in RFC 8453. It defines an SDN-based architecture that relies on the concept of network and service abstraction to detach network and service control from the underlying data plane. This document outlines the applicability of ACTN to network slicing in a Traffic Engineered (TE) network that utilizes IETF technologies. It also identifies the features of network slicing not currently within the scope of ACTN, and indicates where ACTN might be extended. | ||||||||||||||||
| draft-ietf-teas-enhanced-vpn-12.txt | |||||||||||||||||
| A Framework for Enhanced Virtual Private Network (VPN+) | |||||||||||||||||
|
This document describes the framework for Enhanced Virtual Private Network (VPN+) to support the needs of applications with specific traffic performance requirements (e.g., low latency, bounded jitter). VPN+ leverages the VPN and Traffic Engineering (TE) technologies and adds characteristics that specific services require beyond those provided by conventional VPNs. Typically, VPN+ will be used to underpin network slicing, but could also be of use in its own right providing enhanced connectivity services between customer sites. This document also provides an overview of relevant technologies in different network layers, and identifies some areas for potential new work. | ||||||||||||||||
| draft-ietf-teas-gmpls-controller-inter-work-11.txt | |||||||||||||||||
| Interworking of GMPLS Control and Centralized Controller Systems | |||||||||||||||||
|
Generalized Multi-Protocol Label Switching (GMPLS) control allows each network element (NE) to perform local resource discovery, routing and signaling in a distributed manner. On the other hand, with the development of software-defined transport networking technology, a set of NEs can be controlled via centralized controller hierarchies to address the issues from multi- domain, multi-vendor, and multi-technology. An example of such centralized architecture is Abstraction and Control of Traffic Engineered Networks (ACTN) controller hierarchy described in RFC 8453. Instead of competing with each other, both the distributed and the centralized control plane have their own advantages, and should be complementary in the system. This document describes how the GMPLS distributed control plane can interwork with a centralized controller system in a transport network. | ||||||||||||||||
| draft-ietf-teas-ietf-network-slice-nbi-yang-04.txt | |||||||||||||||||
| A YANG Data Model for the IETF Network Slice Service | |||||||||||||||||
|
This document defines a YANG data model for the IETF Network Slice Service. The model can be used in the IETF Network Slice Service interface between a customer and a provider that offers IETF Network Slices. | ||||||||||||||||
| draft-ietf-teas-ietf-network-slice-use-cases-01.txt | |||||||||||||||||
| IETF Network Slice Use Cases and Attributes for the Slice Service Interface of IETF Network Slice Controllers | |||||||||||||||||
|
This document analyses the needs of potential customers of network slices realized with IETF techniques in several use cases, identifies the functionalities for the IETF Network Slice Service Interface of an IETF Network Slice Controller to satisfy such requests. This document is intended to provide motivation and support for work on YANG models for the IETF Network Slice Service interface. | ||||||||||||||||
| draft-ietf-teas-ietf-network-slices-19.txt | |||||||||||||||||
| A Framework for IETF Network Slices | |||||||||||||||||
|
This document describes network slicing in the context of networks built from IETF technologies. It defines the term "IETF Network Slice" and establishes the general principles of network slicing in the IETF context. The document discusses the general framework for requesting and operating IETF Network Slices, the characteristics of an IETF Network Slice, the necessary system components and interfaces, and how abstract requests can be mapped to more specific technologies. The document also discusses related considerations with monitoring and security. This document also provides definitions of related terms to enable consistent usage in other IETF documents that describe or use aspects of IETF Network Slices. | ||||||||||||||||
| draft-ietf-teas-nrp-scalability-01.txt | |||||||||||||||||
| Scalability Considerations for Network Resource Partition | |||||||||||||||||
|
The IETF Network Slice aims to offer a connectivity service to a network slice customer with specific Service Level Objectives (SLOs) and Service Level Expectations (SLEs) over a common underlay network. A Network Resource Partition (NRP) is a set of network resources that are allocated from the underlay network to carry a specific set of network slice service traffic and meet specific SLOs and SLEs. As the demand for IETF Network Slice increases, scalability would become an important factor for the deployment of IETF Network Slices. Although the scalability of IETF Network Slices can be improved by mapping a group of IETF Network Slices to one NRP, that design may not be suitable or possible for all deployments, thus there are concerns about the scalability of NRPs. This document discusses some scalability considerations about NRPs in the network control and data plane. It also investigates a set of optimization mechanisms. | ||||||||||||||||
| draft-ietf-teas-ns-ip-mpls-02.txt | |||||||||||||||||
| Realizing Network Slices in IP/MPLS Networks | |||||||||||||||||
|
Realizing network slices may require the Service Provider to have the ability to partition a physical network into multiple logical networks of varying sizes, structures, and functions so that each slice can be dedicated to specific services or customers. Multiple network slices can be realized on the same network while ensuring slice elasticity in terms of network resource allocation. This document describes a scalable solution to realize network slicing in IP/MPLS networks by supporting multiple services on top of a single physical network by relying on compliant domains and nodes to provide forwarding treatment (scheduling, drop policy, resource usage) on to packets that carry identifiers that indicate the slicing service that is to be applied to the packets. | ||||||||||||||||
| draft-ietf-teas-pcecc-use-cases-13.txt | |||||||||||||||||
| The Use Cases for Path Computation Element (PCE) as a Central Controller (PCECC). | |||||||||||||||||
|
The Path Computation Element (PCE) is a core component of a Software- Defined Networking (SDN) systems. It can compute optimal paths for traffic across a network and update paths to reflect changes in the network or traffic demands. PCE was developed to derive paths for MPLS Label Switched Paths (LSPs), which are supplied to the head end of the LSP using the Path Computation Element Communication Protocol (PCEP). SDN has a much broader applicability than signal MPLS traffic- engineered (TE) paths, and the PCE may be used to determine paths in a range of use cases including static LSPs, Segment Routing (SR), Service Function Chaining (SFC), and most forms of a routed or switched network. It is, therefore, reasonable to consider PCEP as a control protocol for use in these environments to allow the PCE to be fully enabled as a central controller. A PCE as a Central Controller (PCECC) can simplify the processing of a distributed control plane by blending it with elements of SDN and without necessarily completely replacing it. This document describes general considerations for PCECC deployment and examines its applicability and benefits, as well as its challenges and limitations, through a number of use cases. PCEP extensions which required for the PCECC use cases are covered in separate documents. | ||||||||||||||||
| draft-ietf-teas-rfc3272bis-22.txt | |||||||||||||||||
| Overview and Principles of Internet Traffic Engineering | |||||||||||||||||
|
This document describes the principles of traffic engineering (TE) in the Internet. The document is intended to promote better understanding of the issues surrounding traffic engineering in IP networks and the networks that support IP networking, and to provide a common basis for the development of traffic engineering capabilities for the Internet. The principles, architectures, and methodologies for performance evaluation and performance optimization of operational networks are also discussed. This work was first published as RFC 3272 in May 2002. This document obsoletes RFC 3272 by making a complete update to bring the text in line with best current practices for Internet traffic engineering and to include references to the latest relevant work in the IETF. | ||||||||||||||||
| draft-ietf-teas-rfc8776-update-02.txt | |||||||||||||||||
| Common YANG Data Types for Traffic Engineering | |||||||||||||||||
|
This document defines a collection of common data types and groupings in YANG data modeling language. These derived common types and groupings are intended to be imported by modules that model Traffic Engineering (TE) configuration and state capabilities. This document obsoletes RFC 8776. | ||||||||||||||||
| draft-ietf-teas-sf-aware-topo-model-11.txt | |||||||||||||||||
| SF Aware TE Topology YANG Model | |||||||||||||||||
|
This document describes a YANG data model for TE network topologies that are network service and function aware. | ||||||||||||||||
| draft-ietf-teas-te-service-mapping-yang-13.txt | |||||||||||||||||
| Traffic Engineering (TE) and Service Mapping YANG Data Model | |||||||||||||||||
|
This document provides a YANG data model to map customer service models (e.g., L3VPN Service Delivery model) to Traffic Engineering (TE) models (e.g., the TE Tunnel or the Virtual Network (VN) model). These models are referred to as TE Service Mapping Model and are applicable generically to the operator's need for seamless control and management of their VPN services with underlying TE support. The models are principally used for monitoring and diagnostics of the management systems to show how the service requests are mapped onto underlying network resource and TE models. | ||||||||||||||||
| draft-ietf-teas-yang-l3-te-topo-14.txt | |||||||||||||||||
| YANG Data Model for Layer 3 TE Topologies | |||||||||||||||||
|
This document defines a YANG data model for layer 3 traffic engineering topologies. | ||||||||||||||||
| draft-ietf-teas-yang-path-computation-20.txt | |||||||||||||||||
| A YANG Data Model for requesting path computation | |||||||||||||||||
|
There are scenarios, typically in a hierarchical Software-Defined Networking (SDN) context, where the topology information provided by a Traffic Engineering (TE) network provider may be insufficient for its client to perform multi-domain path computation. In these cases the client would need to request the TE network provider to compute some intra-domain paths to be used by the client to choose the optimal multi-domain paths. This document provides a mechanism to request path computation by augmenting the Remote Procedure Calls (RPCs) defined in RFC YYYY. [RFC EDITOR NOTE: Please replace RFC YYYY with the RFC number of draft-ietf-teas-yang-te once it has been published. Moreover, this document describes some use cases where the path computation request, via YANG-based protocols (e.g., NETCONF or RESTCONF), can be needed. | ||||||||||||||||
| draft-ietf-teas-yang-sr-te-topo-17.txt | |||||||||||||||||
| YANG Data Model for SR and SR TE Topologies on MPLS Data Plane | |||||||||||||||||
|
This document defines a YANG data model for Segment Routing (SR) topology and Segment Routing (SR) traffic engineering (TE) topology, using MPLS data plane. | ||||||||||||||||
| draft-ietf-teas-yang-te-32.txt | |||||||||||||||||
| A YANG Data Model for Traffic Engineering Tunnels,Label Switched Paths and Interfaces | |||||||||||||||||
|
This document defines a YANG data model for the provisioning and management of Traffic Engineering (TE) tunnels, Label Switched Paths (LSPs), and interfaces. The model covers data that is independent of any technology or dataplane encapsulation and is divided into two YANG modules that cover device-specific, and device independent data. This model covers data for configuration, operational state, remote procedural calls, and event notifications. | ||||||||||||||||
| draft-ietf-teep-architecture-19.txt | |||||||||||||||||
| Trusted Execution Environment Provisioning (TEEP) Architecture | |||||||||||||||||
|
A Trusted Execution Environment (TEE) is an environment that enforces that any code within that environment cannot be tampered with, and that any data used by such code cannot be read or tampered with by any code outside that environment. This architecture document motivates the design and standardization of a protocol for managing the lifecycle of trusted applications running inside such a TEE. | ||||||||||||||||
| draft-ietf-teep-otrp-over-http-15.txt | |||||||||||||||||
| HTTP Transport for Trusted Execution Environment Provisioning: Agent Initiated Communication | |||||||||||||||||
|
The Trusted Execution Environment Provisioning (TEEP) Protocol is used to manage code and configuration data in a Trusted Execution Environment (TEE). This document specifies the HTTP transport for TEEP communication where a Trusted Application Manager (TAM) service is used to manage code and data in TEEs on devices that can initiate communication to the TAM. | ||||||||||||||||
| draft-ietf-teep-protocol-12.txt | |||||||||||||||||
| Trusted Execution Environment Provisioning (TEEP) Protocol | |||||||||||||||||
|
This document specifies a protocol that installs, updates, and deletes Trusted Components in a device with a Trusted Execution Environment (TEE). This specification defines an interoperable protocol for managing the lifecycle of Trusted Components. | ||||||||||||||||
| draft-ietf-teep-usecase-for-cc-in-network-03.txt | |||||||||||||||||
| TEEP Usecase for Confidential Computing in Network | |||||||||||||||||
|
Confidential computing is the protection of data in use by performing computation in a hardware-based Trusted Execution Environment. Confidential computing could provide integrity and confidentiality for users who want to run applications and process data in that environment. When confidential computing is used in scenarios which need network to provision user data and applications in the TEE environment, TEEP architecture[I-D.ietf-teep-architecture] and protocol [I-D.ietf-teep-protocol] could be used. This document focuses on using TEEP to provision Network User data and applications in confidential computing. This document is a use case and extension of TEEP and could provide guidance for cloud computing, [MEC] and other scenarios to use confidential computing in network. | ||||||||||||||||
| draft-ietf-tictoc-ptp-enterprise-profile-22.txt | |||||||||||||||||
| Enterprise Profile for the Precision Time Protocol With Mixed Multicast and Unicast Messages | |||||||||||||||||
|
This document describes a profile for the use of the Precision Time Protocol in an IPV4 or IPv6 Enterprise information system environment. The profile uses the End to End Delay Measurement Mechanism, allows both multicast and unicast Delay Request and Delay Response Messages. | ||||||||||||||||
| draft-ietf-tls-ctls-08.txt | |||||||||||||||||
| Compact TLS 1.3 | |||||||||||||||||
|
This document specifies a "compact" version of TLS 1.3 and DTLS 1.3. It saves bandwidth by trimming obsolete material, tighter encoding, a template-based specialization technique, and alternative cryptographic techniques. cTLS is not directly interoperable with TLS 1.3 or DTLS 1.3 since the over-the-wire framing is different. A single server can, however, offer cTLS alongside TLS or DTLS. | ||||||||||||||||
| draft-ietf-tls-deprecate-obsolete-kex-02.txt | |||||||||||||||||
| Deprecating Obsolete Key Exchange Methods in TLS 1.2 | |||||||||||||||||
|
This document deprecates the use of RSA key exchange and Diffie Hellman over a finite field in TLS 1.2, and discourages the use of static elliptic curve Diffie Hellman cipher suites. Note that these prescriptions apply only to TLS 1.2 since TLS 1.0 and 1.1 are deprecated by [RFC8996] and TLS 1.3 either does not use the affected algorithm or does not share the relevant configuration options. | ||||||||||||||||
| draft-ietf-tls-dtls-rrc-08.txt | |||||||||||||||||
| Return Routability Check for DTLS 1.2 and DTLS 1.3 | |||||||||||||||||
|
This document specifies a return routability check for use in context of the Connection ID (CID) construct for the Datagram Transport Layer Security (DTLS) protocol versions 1.2 and 1.3. Discussion Venues This note is to be removed before publishing as an RFC. Discussion of this document takes place on the Transport Layer Security Working Group mailing list (tls@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/tls/. Source for this draft and an issue tracker can be found at https://github.com/tlswg/dtls-rrc. | ||||||||||||||||
| draft-ietf-tls-esni-16.txt | |||||||||||||||||
| TLS Encrypted Client Hello | |||||||||||||||||
|
This document describes a mechanism in Transport Layer Security (TLS) for encrypting a ClientHello message under a server public key. Discussion Venues This note is to be removed before publishing as an RFC. Source for this draft and an issue tracker can be found at https://github.com/tlswg/draft-ietf-tls-esni (https://github.com/tlswg/draft-ietf-tls-esni). | ||||||||||||||||
| draft-ietf-tls-hybrid-design-06.txt | |||||||||||||||||
| Hybrid key exchange in TLS 1.3 | |||||||||||||||||
|
Hybrid key exchange refers to using multiple key exchange algorithms simultaneously and combining the result with the goal of providing security even if all but one of the component algorithms is broken. It is motivated by transition to post-quantum cryptography. This document provides a construction for hybrid key exchange in the Transport Layer Security (TLS) protocol version 1.3. Discussion of this work is encouraged to happen on the TLS IETF mailing list tls@ietf.org or on the GitHub repository which contains the draft: https://github.com/dstebila/draft-ietf-tls-hybrid-design. | ||||||||||||||||
| draft-ietf-tls-rfc8446bis-07.txt | |||||||||||||||||
| The Transport Layer Security (TLS) Protocol Version 1.3 | |||||||||||||||||
|
This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. This document updates RFCs 5705, 6066, 7627, and 8422 and obsoletes RFCs 5077, 5246, 6961, and 8446. This document also specifies new requirements for TLS 1.2 implementations. | ||||||||||||||||
| draft-ietf-tls-rfc8447bis-04.txt | |||||||||||||||||
| IANA Registry Updates for TLS and DTLS | |||||||||||||||||
|
This document updates the changes to TLS and DTLS IANA registries made in RFC 8447. It adds a new value "D" for discouraged to the recommended column of the selected TLS registries. This document updates the following RFCs: 3749, 5077, 4680, 5246, 5705, 5878, 6520, 7301, and 8447. | ||||||||||||||||
| draft-ietf-tls-subcerts-15.txt | |||||||||||||||||
| Delegated Credentials for (D)TLS | |||||||||||||||||
|
The organizational separation between operators of TLS and DTLS endpoints and the certification authority can create limitations. For example, the lifetime of certificates, how they may be used, and the algorithms they support are ultimately determined by the certification authority. This document describes a mechanism to to overcome some of these limitations by enabling operators to delegate their own credentials for use in TLS and DTLS without breaking compatibility with peers that do not support this specification. | ||||||||||||||||
| draft-ietf-tls-tlsflags-11.txt | |||||||||||||||||
| A Flags Extension for TLS 1.3 | |||||||||||||||||
|
A number of extensions are proposed in the TLS working group that carry no interesting information except the 1-bit indication that a certain optional feature is supported. Such extensions take 4 octets each. This document defines a flags extension that can provide such indications at an average marginal cost of 1 bit each. More precisely, it provides as many flag extensions as needed at 4 + the order of the last set bit divided by 8. | ||||||||||||||||
| draft-ietf-tls-wkech-01.txt | |||||||||||||||||
| A well-known URI for publishing ECHConfigList values. | |||||||||||||||||
|
We propose use of a well-known URI at which an HTTP origin can inform an authoritative DNS server, or other interested parties, about this origin's Service Bindings, i.e. its "HTTPS" DNS records. These instructions can include Encrypted ClientHello (ECH) configurations, allowing the origin to publish and rotate its own ECH keys. | ||||||||||||||||
| draft-ietf-trill-ecn-support-07.txt | |||||||||||||||||
| TRILL (TRansparent Interconnection of Lots of Links): ECN (Explicit Congestion Notification) Support | |||||||||||||||||
|
Explicit congestion notification (ECN) allows a forwarding element to notify downstream devices, including the destination, of the onset of congestion without having to drop packets. This can improve network efficiency through better congestion control without packet drops. This document extends ECN to TRILL (TRansparent Interconnection of Lots of Links) switches, including integration with IP ECN, and provides for ECN marking in the TRILL Header Extension Flags Word (see RFC 7179). | ||||||||||||||||
| draft-ietf-trill-group-keying-11.txt | |||||||||||||||||
| Simple Group Keying Protocol (SGKP) | |||||||||||||||||
|
This document specifies a simple general group keying protocol that provides for the distribution of shared secret keys to group members and the management of such keys. It assumes that secure pairwise keys can be created between any two group members. | ||||||||||||||||
| draft-ietf-tsvwg-dscp-considerations-13.txt | |||||||||||||||||
| Considerations for Assigning a new Recommended DiffServ Codepoint (DSCP) | |||||||||||||||||
|
This document discusses considerations for assigning a new recommended DiffServ Code Point (DSCP) for a new standard Per Hop Behavior (PHB). It considers the common observed re-marking behaviors that the DiffServ field might be subjected to along an Internet path. It also notes some implications of using a specific DSCP. | ||||||||||||||||
| draft-ietf-tsvwg-dtls-over-sctp-bis-05.txt | |||||||||||||||||
| Datagram Transport Layer Security (DTLS) over Stream Control Transmission Protocol (SCTP) | |||||||||||||||||
|
This document describes the usage of the Datagram Transport Layer Security (DTLS) protocol to protect user messages sent over the Stream Control Transmission Protocol (SCTP). It is an improved alternative to the existing RFC 6083. DTLS over SCTP provides mutual authentication, confidentiality, integrity protection, and replay protection for applications that use SCTP as their transport protocol and allows client/server applications to communicate in a way that is designed to give communications privacy and to prevent eavesdropping and detect tampering or message forgery. Applications using DTLS over SCTP can use almost all transport features provided by SCTP and its extensions. This document is an improved alternative to RFC 6083 and removes the 16 kB limitation on protected user message size by defining a secure user message fragmentation so that multiple DTLS records can be used to protect a single user message. It further contains a large number of security fixes and improvements. It updates the DTLS versions and SCTP-AUTH HMAC algorithms to use. It mitigates reflection attacks of data and control chunks and replay attacks of data chunks. It simplifies secure implementation by some stricter requirements on the establishment procedures as well as rekeying to align with zero trust principles. | ||||||||||||||||
| draft-ietf-tsvwg-l4sops-04.txt | |||||||||||||||||
| Operational Guidance for Deployment of L4S in the Internet | |||||||||||||||||
|
This document is intended to provide guidance in order to ensure successful deployment of Low Latency Low Loss Scalable throughput (L4S) in the Internet. Other L4S documents provide guidance for running an L4S experiment, but this document is focused solely on potential interactions between L4S flows and flows using the original ('Classic') ECN over a Classic ECN bottleneck link. The document discusses the potential outcomes of these interactions, describes mechanisms to detect the presence of Classic ECN bottlenecks, and identifies opportunities to prevent and/or detect and resolve fairness problems in such networks. This guidance is aimed at operators of end-systems, operators of networks, and researchers. | ||||||||||||||||
| draft-ietf-tsvwg-multipath-dccp-07.txt | |||||||||||||||||
| DCCP Extensions for Multipath Operation with Multiple Addresses | |||||||||||||||||
|
DCCP communications as defined in [RFC4340] are restricted to a single path per connection, yet multiple paths often exist between peers. The simultaneous use of available multiple paths for a DCCP session could improve resource usage within the network and, thus, improve user experience through higher throughput and improved resilience to network failures. Use cases for a Multipath DCCP (MP- DCCP) are mobile devices (e.g., handsets, vehicles) and residential home gateways simultaneously connected to distinct networks as, e.g., a cellular and a Wireless Local Area (WLAN) networks or a cellular and a fixed access networks. Compared to existing multipath protocols, such as MPTCP, MP-DCCP provides specific support for non- TCP user traffic (e.g., UDP or plain IP). More details on potential use cases are provided in [website], [slide], and [paper]. All these use cases profit from an Open Source Linux reference implementation provided under [website]. This document specifies a set of extensions to DCCP to support multipath operations. Multipath DCCP provides the ability to simultaneously use multiple paths between peers. The protocol offers the same type of service to applications as DCCP and it provides the components necessary to establish and use multiple DCCP flows across different paths simultaneously. | ||||||||||||||||
| draft-ietf-tsvwg-nqb-17.txt | |||||||||||||||||
| A Non-Queue-Building Per-Hop Behavior (NQB PHB) for Differentiated Services | |||||||||||||||||
|
This document specifies properties and 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, low-data-rate, application-limited traffic flows, which would ordinarily share a queue with bursty and capacity-seeking traffic, to avoid the latency, latency variation and loss caused by such traffic. This PHB is implemented without prioritization and can be implemented without rate policing, making it suitable for environments where the use of these features is restricted. The NQB PHB has been developed primarily for use by access network segments, where queuing delays and queuing loss caused by Queue-Building protocols are manifested, but its use is not limited to such segments. In particular, applications to cable broadband links, Wi-Fi links, and mobile network radio and core segments are discussed. This document recommends a specific Differentiated Services Code Point (DSCP) to identify Non-Queue-Building flows. [NOTE (to be removed by RFC-Editor): This document references an ISE submission draft (I-D.briscoe-docsis-q-protection) that is approved for publication as an RFC. This draft should be held for publication until the queue protection RFC can be referenced.] | ||||||||||||||||
| draft-ietf-tsvwg-rfc6040update-shim-16.txt | |||||||||||||||||
| Propagating Explicit Congestion Notification Across IP Tunnel Headers Separated by a Shim | |||||||||||||||||
|
RFC 6040 on "Tunnelling of Explicit Congestion Notification" made the rules for propagation of ECN consistent for all forms of IP in IP tunnel. This specification updates RFC 6040 to clarify that its scope includes tunnels where two IP headers are separated by at least one shim header that is not sufficient on its own for wide area packet forwarding. It surveys widely deployed IP tunnelling protocols that use such shim header(s) and updates the specifications of those that do not mention ECN propagation (that is RFC 2661, RFC 3931, RFC 2784, RFC 4380 and RFC 7450, which respectively specify L2TPv2, L2TPv3, GRE, Teredo and AMT). This specification also updates RFC 6040 with configuration requirements needed to make any legacy tunnel ingress safe. | ||||||||||||||||
| draft-ietf-tsvwg-udp-options-20.txt | |||||||||||||||||
| Transport Options for UDP | |||||||||||||||||
|
Transport protocols are extended through the use of transport header options. This document extends UDP by indicating the location, syntax, and semantics for UDP transport layer options. | ||||||||||||||||
| draft-ietf-tsvwg-udp-options-dplpmtud-07.txt | |||||||||||||||||
| Datagram PLPMTUD for UDP Options | |||||||||||||||||
|
This document specifies how a UDP Options sender implements Datagram Packetization Layer Path Maximum Transmission Unit Discovery (DPLPMTUD) as a robust method for Path Maximum Transmission Unit discovery. This method uses the UDP Options packetization layer. It allows an application to discover the largest size of datagram that can be sent across the network path. It also provides a way to allow the application to periodically verify the current maximum packet size supported by a path and to update this when required. | ||||||||||||||||
| draft-ietf-tsvwg-usr-exp-01.txt | |||||||||||||||||
| User Ports for Experiments | |||||||||||||||||
|
This document defines user ports for experiments using transport protocols. It describes the use of experiment identifiers to enable shared use of these user ports, as well as updating the use of system ports for experiments in the same manner. | ||||||||||||||||
| draft-ietf-tvr-use-cases-00.txt | |||||||||||||||||
| TVR (Time-Variant Routing) Use Cases | |||||||||||||||||
|
Time-Variant Routing (TVR) refers to the calculation of a path or subpath through a network where the time of message transmission (or receipt) is part of the overall route computation. This means that, all things being equal, a TVR computation might produce different results depending on the time that the computation is performed without other detectable changes to the network topology or other cost functions associated with the route. This document introduces use cases where TVR computations could improve message exchange in a network. | ||||||||||||||||
| draft-ietf-uta-ciphersuites-in-sec-syslog-03.txt | |||||||||||||||||
| Updates to the Cipher Suites in Secure Syslog | |||||||||||||||||
|
The Syslog Working Group published two specifications, namely RFC 5425 and RFC 6012, for securing the Syslog protocol using TLS and DTLS, respectively. This document updates the cipher suites in RFC 5425, Transport Layer Security (TLS) Transport Mapping for Syslog, and RFC 6012, Datagram Transport Layer Security (DTLS) Transport Mapping for Syslog. It also updates the transport protocol in RFC 6012. | ||||||||||||||||
| draft-ietf-uta-rfc6125bis-12.txt | |||||||||||||||||
| Service Identity in TLS | |||||||||||||||||
|
Many application technologies enable secure communication between two entities by means of Transport Layer Security (TLS) with Internet Public Key Infrastructure Using X.509 (PKIX) certificates. This document specifies procedures for representing and verifying the identity of application services in such interactions. This document obsoletes RFC 6125. | ||||||||||||||||
| draft-ietf-uta-tls13-iot-profile-06.txt | |||||||||||||||||
| TLS/DTLS 1.3 Profiles for the Internet of Things | |||||||||||||||||
|
This document is a companion to RFC 7925 and defines TLS/DTLS 1.3 profiles for Internet of Things devices. It also updates RFC 7925 with regards to the X.509 certificate profile. | ||||||||||||||||
| draft-ietf-uuidrev-rfc4122bis-03.txt | |||||||||||||||||
| Universally Unique IDentifiers (UUID) | |||||||||||||||||
|
This specification defines a Uniform Resource Name namespace for UUIDs (Universally Unique IDentifiers), also known as GUIDs (Globally Unique IDentifiers). A UUID is 128 bits long, and is intended to guarantee uniqueness across space and time. UUIDs were originally used in the Apollo Network Computing System and later in the Open Software Foundation's (OSF) Distributed Computing Environment (DCE), and then in Microsoft Windows platforms. This specification is derived from the DCE specification with the kind permission of the OSF (now known as The Open Group). Information from earlier versions of the DCE specification have been incorporated into this document. This document obsoletes RFC4122. | ||||||||||||||||
| draft-ietf-v6ops-464xlat-optimization-04.txt | |||||||||||||||||
| 464XLAT/MAT-T Optimization | |||||||||||||||||
|
IP/ICMP Translation Algorithm (SIIT) can be used to provide access for IPv4-only hosts or applications to IPv4-only or dual-stack destinations over IPv6-only infrastructure. In that case, the traffic flows are translated twice: first from IPv4 to IPv6 (stateless NAT46 at the ingress point to the IPv6-only infrastructure) and then from IPv6 back to IPv4 (stateful NAT64, at the egress point). When the destination is IPv6-enabled, the second translation might be avoided. This document describes a possible optimization to 464XLAT and MAP-T to avoid translating IPv6 flows back to IPv4 if the destination is reachable over IPv6. The proposed solution would significantly reduce the NAT64 utilization in the operator's network, increasing the performance. | ||||||||||||||||
| draft-ietf-v6ops-framework-md-ipv6only-underlay-01.txt | |||||||||||||||||
| Framework of Multi-domain IPv6-only Underlay Networks and IPv4-as-a-Service | |||||||||||||||||
|
For the IPv6 transition, dual-stack deployments require both IPv4 and IPv6 forwarding capabilities to be deployed in parallel. IPv6-only is considered as the ultimate stage where only IPv6 bearer capabilities are used while ensuring global reachability for both IPv6 and IPv4 service(usually known as IPv4aaS). This document proposes a general framework for deploying IPv6-only in multi-domain underlay networks. It discusses the requirements of service traffic, major components and interfaces, IPv6 mapping prefix allocation, typical procedures for service delivery. The document also discusses related security considerations. | ||||||||||||||||
| draft-ietf-v6ops-hbh-04.txt | |||||||||||||||||
| Operational Issues with Processing of the Hop-by-Hop Options Header | |||||||||||||||||
|
This document describes the processing of the Hop-by-Hop Options Header (HBH) in current routers in the aspects of standards specification, common implementations, and default operations. This document outlines reasons why the Hop-by-Hop Options Header is rarely utilized in current networks. In addition, this document describes how HBH Options Header could be used as a powerful mechanism allowing deployment and operations of new services requiring a more optimized way to leverage network resources of an infrastructure. The purpose of this draft is to document reasons why HBH Options Header is rarely used within networks. It motivates the benefits and requirements needed to enable wider use of HBH Options. | ||||||||||||||||
| draft-ietf-v6ops-nd-considerations-00.txt | |||||||||||||||||
| Selectively Applying Host Isolation to Simplify IPv6 First-hop Deployment | |||||||||||||||||
|
Neighbor Discovery (ND) is a key protocol of IPv6 first-hop. ND uses multicast extensively and trusts all hosts. In some scenarios like wireless networks, multicast can be inefficient. In other scenarios like public access networks, hosts may not be trustable. Consequently, ND has potential issues in various scenarios. The issues and the solutions for them are documented in more than 30 RFCs. It is difficult to keep track of all these issues and solutions. Therefore, an overview and some guidelines are useful. This document firstly summarizes the known ND issues and optimization solutions into a one-stop reference. Analyzing these solutions reveals an insight: isolating hosts is effective in preventing ND issues. Four isolation methods are proposed and their applicability is discussed. Guidelines are then described for selecting a suitable isolation method based on the deployment scenario. | ||||||||||||||||
| draft-ietf-v6ops-ula-02.txt | |||||||||||||||||
| Unintended Operational Issues With ULA | |||||||||||||||||
|
The behavior of ULA addressing as defined by [RFC6724] is preferred below legacy IPv4 addressing, thus rendering ULA IPv6 deployment functionally unusable in IPv4 / IPv6 dual-stacked environments. The lack of a consistent and supportable way to manipulate this behavior, across all platforms and at scale is counter to the operational behavior of GUA IPv6 addressing on nearly all modern operating systems that leverage a preference model based on [RFC6724] . | ||||||||||||||||
| draft-ietf-webtrans-http2-05.txt | |||||||||||||||||
| WebTransport over HTTP/2 | |||||||||||||||||
|
WebTransport defines a set of low-level communications features designed for client-server interactions that are initiated by Web clients. This document describes a protocol that can provide many of the capabilities of WebTransport over HTTP/2. This protocol enables the use of WebTransport when a UDP-based protocol is not available. | ||||||||||||||||
| draft-ietf-webtrans-http3-05.txt | |||||||||||||||||
| WebTransport over HTTP/3 | |||||||||||||||||
|
WebTransport [OVERVIEW] is a protocol framework that enables clients constrained by the Web security model to communicate with a remote server using a secure multiplexed transport. This document describes a WebTransport protocol that is based on HTTP/3 [HTTP3] and provides support for unidirectional streams, bidirectional streams and datagrams, all multiplexed within the same HTTP/3 connection. | ||||||||||||||||
| draft-ietf-webtrans-overview-05.txt | |||||||||||||||||
| The WebTransport Protocol Framework | |||||||||||||||||
|
The WebTransport Protocol Framework enables clients constrained by the Web security model to communicate with a remote server using a secure multiplexed transport. It consists of a set of individual protocols that are safe to expose to untrusted applications, combined with a model that allows them to be used interchangeably. This document defines the overall requirements on the protocols used in WebTransport, as well as the common features of the protocols, support for some of which may be optional. | ||||||||||||||||
| draft-ietf-wish-whip-08.txt | |||||||||||||||||
| WebRTC-HTTP ingestion protocol (WHIP) | |||||||||||||||||
|
This document describes a simple HTTP-based protocol that will allow WebRTC-based ingestion of content into streaming services and/or CDNs. | ||||||||||||||||
| draft-ietf0-idr-srv6-flowspec-path-redirect-09.txt | |||||||||||||||||
| Flowspec Indirection-id Redirect for SRv6 | |||||||||||||||||
|
This document defines extensions to "FlowSpec Redirect to indirection-id Extended Community" for SRv6. This extended community can trigger advanced redirection capabilities to flowspec clients for SRv6. When activated, this flowspec extended community is used by a flowspec client to retrieve the corresponding next-hop and encoding information within a localised indirection-id mapping table. The functionality detailed in this document allows a network controller to decouple the BGP flowspec redirection instruction from the operation of the available paths. | ||||||||||||||||
| draft-ihlar-masque-datagram-numbers-01.txt | |||||||||||||||||
| A Sequence Number Extension for HTTP Datagrams | |||||||||||||||||
|
This document defines a sequence number extension to HTTP datagrams used to carry proxied UDP payload or IP datagrams. This extension is useful when HTTP datagrams are transported on top of a multipath protocol that does not ensure in-order delivery as it allows a masque endpoint to implement reordering logic specific to its needs. | ||||||||||||||||
| draft-industrial-internet-identifier-data-escrow-06.txt | |||||||||||||||||
| Abstract | |||||||||||||||||
|
This document specifies the format and contents of data escrow deposits targeted primarily for Industrial Internet Identifier Node (IIIN) which provides identifier registration. However, this specification was designed to be independent of the underlying objects that are being escrowed, therefore it could be used for purposes other than IIIN. | ||||||||||||||||
| draft-ingles-eap-edhoc-04.txt | |||||||||||||||||
| Using the Extensible Authentication Protocol with Ephemeral Diffie-Hellman over COSE (EDHOC) | |||||||||||||||||
|
The Extensible Authentication Protocol (EAP), defined in RFC 3748, provides a standard mechanism for support of multiple authentication methods. This document specifies the use of EAP-EDHOC with Ephemeral Diffie-Hellman Over COSE (EDHOC). EDHOC provides a lightweight authenticated Diffie-Hellman key exchange with ephemeral keys, using COSE (RFC 8152) to provide security services efficiently encoded in CBOR (RFC 8949). This document also provides guidance on authentication and authorization for EAP-EDHOC. | ||||||||||||||||
| draft-intesigroup-dlts-05.txt | |||||||||||||||||
| Distributed Ledger Time-Stamp | |||||||||||||||||
|
This document defines a standard to extend Time Stamp Tokens with Time Attestations recorded on Distributed Ledgers. The aim is to provide long-term validity to Time Stamp Tokens, backward compatible with currently available software. | ||||||||||||||||
| draft-iplir-protocol-03.txt | |||||||||||||||||
| IPlir network layer security protocol | |||||||||||||||||
|
This document specifies the IPlir network layer security protocol. It describes how to provide a set of security services for traffic over public and corporate networks using the TCP/IP stack. | ||||||||||||||||
| draft-irtf-cfrg-aead-limits-06.txt | |||||||||||||||||
| Usage Limits on AEAD Algorithms | |||||||||||||||||
|
An Authenticated Encryption with Associated Data (AEAD) algorithm provides confidentiality and integrity. Excessive use of the same key can give an attacker advantages in breaking these properties. This document provides simple guidance for users of common AEAD functions about how to limit the use of keys in order to bound the advantage given to an attacker. It considers limits in both single- and multi-key settings. | ||||||||||||||||
| draft-irtf-cfrg-aead-properties-01.txt | |||||||||||||||||
| Properties of AEAD algorithms | |||||||||||||||||
|
Authenticated Encryption with Associated Data (AEAD) algorithms provide confidentiality and integrity of data. The extensive use of AEAD algorithms in various high-level applications has caused the need for AEAD algorithms with additional properties and motivated research in the area. This document gives definitions for the most common of those properties intending to improve consistency in the field. | ||||||||||||||||
| draft-irtf-cfrg-aegis-aead-02.txt | |||||||||||||||||
| The AEGIS family of authenticated encryption algorithms | |||||||||||||||||
|
This document describes AEGIS-128L and AEGIS-256, two AES-based authenticated encryption algorithms designed for high-performance applications. This document is a product of the Crypto Forum Research Group (CFRG). It is not an IETF product and is not a standard. Discussion Venues This note is to be removed before publishing as an RFC. Source for this draft and an issue tracker can be found at https://github.com/jedisct1/draft-aegis-aead. | ||||||||||||||||
| draft-irtf-cfrg-bbs-signatures-02.txt | |||||||||||||||||
| The BBS Signature Scheme | |||||||||||||||||
|
BBS is a digital signature scheme categorized as a form of short group signature that supports several unique properties. Notably, the scheme supports signing multiple messages whilst producing a single output digital signature. Through this capability, the possessor of a signature is able to generate proofs that selectively disclose subsets of the originally signed set of messages, whilst preserving the verifiable authenticity and integrity of the messages. Furthermore, these proofs are said to be zero-knowledge in nature as they do not reveal the underlying signature; instead, what they reveal is a proof of knowledge of the undisclosed signature. | ||||||||||||||||
| draft-irtf-cfrg-cpace-07.txt | |||||||||||||||||
| CPace,a balanced composable PAKE | |||||||||||||||||
|
This document describes CPace which is a protocol that allows two parties that share a low-entropy secret (password) to derive a strong shared key without disclosing the secret to offline dictionary attacks. The CPace protocol was tailored for constrained devices, is compatible with any cyclic group of prime- and non-prime order. | ||||||||||||||||
| draft-irtf-cfrg-dnhpke-00.txt | |||||||||||||||||
| Deterministic Nonce-less Hybrid Public Key Encryption | |||||||||||||||||
|
This document describes enhancements to the Hybrid Public Key Encryption standard published by CFRG. These include use of "compact representation" of relevant public keys, support for key-wrapping, and two ways to address the use of HPKE on lossy networks: a determinstic, nonce-less AEAD scheme, and use of a rolling sequence number with existing AEAD schemes. | ||||||||||||||||
| draft-irtf-cfrg-frost-12.txt | |||||||||||||||||
| Two-Round Threshold Schnorr Signatures with FROST | |||||||||||||||||
|
This document specifies the Flexible Round-Optimized Schnorr Threshold (FROST) signing protocol. FROST signatures can be issued after a threshold number of entities cooperate to compute a signature, allowing for improved distribution of trust and redundancy with respect to a secret key. FROST depends only on a prime-order group and cryptographic hash function. This document specifies a number of ciphersuites to instantiate FROST using different prime- order groups and hash functions. One such ciphersuite can be used to produce signatures that can be verified with an Edwards-Curve Digital Signature Algorithm (EdDSA, as defined in RFC8032) compliant verifier. However, unlike EdDSA, the signatures produced by FROST are not deterministic. This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF. | ||||||||||||||||
| draft-irtf-cfrg-hash-to-curve-16.txt | |||||||||||||||||
| Hashing to Elliptic Curves | |||||||||||||||||
|
This document specifies a number of algorithms for encoding or hashing an arbitrary string to a point on an elliptic curve. This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF. | ||||||||||||||||
| draft-irtf-cfrg-kangarootwelve-10.txt | |||||||||||||||||
| KangarooTwelve and TurboSHAKE | |||||||||||||||||
|
This document defines three eXtendable Output Functions (XOF), hash functions with output of arbitrary length, named TurboSHAKE128, TurboSHAKE256 and KangarooTwelve. All three functions provide efficient and secure hashing primitive, and the latter is able to exploit the parallelism of the implementation in a scalable way. This document builds up on the definitions of the permutations and of the sponge construction in [FIPS 202], and is meant to serve as a stable reference and an implementation guide. | ||||||||||||||||
| draft-irtf-cfrg-opaque-10.txt | |||||||||||||||||
| The OPAQUE Asymmetric PAKE Protocol | |||||||||||||||||
|
This document describes the OPAQUE protocol, a secure asymmetric password-authenticated key exchange (aPAKE) that supports mutual authentication in a client-server setting without reliance on PKI and with security against pre-computation attacks upon server compromise. In addition, the protocol provides forward secrecy and the ability to hide the password from the server, even during password registration. This document specifies the core OPAQUE protocol and one instantiation based on 3DH. | ||||||||||||||||
| draft-irtf-cfrg-pairing-friendly-curves-11.txt | |||||||||||||||||
| Pairing-Friendly Curves | |||||||||||||||||
|
Pairing-based cryptography, a subfield of elliptic curve cryptography, has received attention due to its flexible and practical functionality. Pairings are special maps defined using elliptic curves and it can be applied to construct several cryptographic protocols such as identity-based encryption, attribute- based encryption, and so on. At CRYPTO 2016, Kim and Barbulescu proposed an efficient number field sieve algorithm named exTNFS for the discrete logarithm problem in a finite field. Several types of pairing-friendly curves such as Barreto-Naehrig curves are affected by the attack. In particular, a Barreto-Naehrig curve with a 254-bit characteristic was adopted by a lot of cryptographic libraries as a parameter of 128-bit security, however, it ensures no more than the 100-bit security level due to the effect of the attack. In this memo, we list the security levels of certain pairing-friendly curves, and motivate our choices of curves. First, we summarize the adoption status of pairing-friendly curves in standards, libraries and applications, and classify them in the 128-bit, 192-bit, and 256-bit security levels. Then, from the viewpoints of "security" and "widely used", we select the recommended pairing-friendly curves considering exTNFS. | ||||||||||||||||
| draft-irtf-cfrg-ristretto255-decaf448-07.txt | |||||||||||||||||
| The ristretto255 and decaf448 Groups | |||||||||||||||||
|
This memo specifies two prime-order groups, ristretto255 and decaf448, suitable for safely implementing higher-level and complex cryptographic protocols. The ristretto255 group can be implemented using Curve25519, allowing existing Curve25519 implementations to be reused and extended to provide a prime-order group. Likewise, the decaf448 group can be implemented using edwards448. This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF. | ||||||||||||||||
| draft-irtf-cfrg-rsa-blind-signatures-12.txt | |||||||||||||||||
| RSA Blind Signatures | |||||||||||||||||
|
This document specifies an RSA-based blind signature protocol. RSA blind signatures were first introduced by Chaum for untraceable payments. A signature that is output from this protocol can be verified as an RSA-PSS signature. This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF. 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/chris-wood/draft-wood-cfrg-blind-signatures. | ||||||||||||||||
| draft-irtf-cfrg-signature-key-blinding-03.txt | |||||||||||||||||
| Key Blinding for Signature Schemes | |||||||||||||||||
|
This document describes extensions to existing digital signature schemes for key blinding. The core property of signing with key blinding is that a blinded public key and all signatures produced using the blinded key pair are independent of the unblinded key pair. Moreover, signatures produced using blinded key pairs are indistinguishable from signatures produced using unblinded key pairs. This functionality has a variety of applications, including Tor onion services and privacy-preserving airdrop for bootstrapping cryptocurrency systems. | ||||||||||||||||
| draft-irtf-cfrg-spake2-26.txt | |||||||||||||||||
| SPAKE2,a PAKE | |||||||||||||||||
|
This document describes SPAKE2 which is a protocol for two parties that share a password to derive a strong shared key without disclosing the password. This method is compatible with any group, is computationally efficient, and SPAKE2 has a security proof. This document predated the CFRG PAKE competition and it was not selected, however, given existing use of variants in Kerberos and other applications it was felt publication was beneficial. Applications that need a symmetric PAKE (password authenticated key exchange) and where hashing onto an elliptic curve at execution time is not possible can use SPAKE2. This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF. | ||||||||||||||||
| draft-irtf-cfrg-vdaf-05.txt | |||||||||||||||||
| Verifiable Distributed Aggregation Functions | |||||||||||||||||
|
This document describes Verifiable Distributed Aggregation Functions (VDAFs), a family of multi-party protocols for computing aggregate statistics over user measurements. These protocols are designed to ensure that, as long as at least one aggregation server executes the protocol honestly, individual measurements are never seen by any server in the clear. At the same time, VDAFs allow the servers to detect if a malicious or misconfigured client submitted an input that would result in an incorrect aggregate result. | ||||||||||||||||
| draft-irtf-cfrg-voprf-21.txt | |||||||||||||||||
| Oblivious Pseudorandom Functions (OPRFs) using Prime-Order Groups | |||||||||||||||||
|
An Oblivious Pseudorandom Function (OPRF) is a two-party protocol between client and server for computing the output of a Pseudorandom Function (PRF). The server provides the PRF private key, and the client provides the PRF input. At the end of the protocol, the client learns the PRF output without learning anything about the PRF private key, and the server learns neither the PRF input nor output. An OPRF can also satisfy a notion of 'verifiability', called a VOPRF. A VOPRF ensures clients can verify that the server used a specific private key during the execution of the protocol. A VOPRF can also be partially-oblivious, called a POPRF. A POPRF allows clients and servers to provide public input to the PRF computation. This document specifies an OPRF, VOPRF, and POPRF instantiated within standard prime-order groups, including elliptic curves. This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF. | ||||||||||||||||
| draft-irtf-cfrg-vrf-15.txt | |||||||||||||||||
| Verifiable Random Functions (VRFs) | |||||||||||||||||
|
A Verifiable Random Function (VRF) is the public-key version of a keyed cryptographic hash. Only the holder of the secret key can compute the hash, but anyone with the public key can verify the correctness of the hash. VRFs are useful for preventing enumeration of hash-based data structures. This document specifies VRF constructions based on RSA and elliptic curves that are secure in the cryptographic random oracle model. This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF. | ||||||||||||||||
| draft-irtf-coinrg-coin-terminology-00.txt | |||||||||||||||||
| Terminology for Computing in the Network | |||||||||||||||||
|
The term Computing in the Network (COIN) is used for a diverse set of scenarios. Often associated with leveraging richer computing capabilities within network elements, its clear scope is yet unknown. This document tries to bring clarity to the current understanding of COIN through defining a terminology to streamline corresponding discussions. | ||||||||||||||||
| draft-irtf-coinrg-use-case-analysis-00.txt | |||||||||||||||||
| Use Case Analysis for Computing in the Network | |||||||||||||||||
|
Computing in the Network (COIN) has the potential to enable a wide variety of use cases. The diversity in use cases makes general considerations challenging. In an effort to capture the breadth of possible scenarios, another COINRG document presents a selection of concrete use cases, each representing a broader set of settings. This document analyzes the described use cases (and potentially further settings) to identify general aspects of interest across all use cases to steer future COIN discussions. | ||||||||||||||||
| draft-irtf-coinrg-use-cases-03.txt | |||||||||||||||||
| Use Cases for In-Network Computing | |||||||||||||||||
|
Computing in the Network (COIN) comes with the prospect of deploying processing functionality on networking devices, such as switches and network interface cards. While such functionality can be beneficial, it has to be carefully placed into the context of the general Internet communication and it needs to be clearly identified where and how those benefits apply. This document presents some use cases to demonstrate how a number of salient COIN-related applications can benefit from COIN, further identifying their essential requirements. | ||||||||||||||||
| draft-irtf-hrpc-association-13.txt | |||||||||||||||||
| Internet Protocols and the Human Rights to Freedom of Association and Assembly | |||||||||||||||||
|
This document explores whether the relationship between the Internet architecture and the ability of people to exercise their rights to peaceful assembly and association online. It does so by asking the question: what are the protocol development considerations for freedom of assembly and association? The Internet increasingly mediates our lives, our relationships, and our ability to exercise our human rights. As a global assemblage, the Internet provides a public space, yet it is predominantly built on private infrastructure. Since Internet protocols and architecture play a central role in the management, development, and use of the Internet, we analyze the relation between protocols, architecture, and the rights to assemble and associate to mitigate infringements on those rights. This document concludes that the way in which infrastructure is designed and implemented impacts people’s ability to exercise their freedom of assembly and association. It is therefore recommended that the potential impacts of Internet technologies should be assessed, reflecting recommendations of various UN bodies and international norms. Finally, the document considers both the limitations on changing association and impact of "forced association" in the context of online platforms. | ||||||||||||||||
| draft-irtf-hrpc-guidelines-18.txt | |||||||||||||||||
| Guidelines for Human Rights Protocol and Architecture Considerations | |||||||||||||||||
|
This document sets guidelines for human rights considerations for developers working on network protocols and architectures, similar to the work done on the guidelines for privacy considerations [RFC6973]. This is an updated version of the guidelines for human rights considerations in [RFC8280]. This document is not an Internet Standards Track specification; it is published for informational purposes. This informational document has consensus for publication from the Internet Research Task Force (IRTF) Human Right Protocol Considerations Research (HRPC) Group. It has been reviewed, tried, and tested by both by the research group as well as by researchers and practitioners from outside the research group (for example see: https://gitlab.com/hr-rt/documents). The research group acknowledges that the understanding of the impact of Internet protocols and architecture on society is a developing practice and is a body of research that is still in development. | ||||||||||||||||
| draft-irtf-iccrg-rledbat-03.txt | |||||||||||||||||
| rLEDBAT: receiver-driven Low Extra Delay Background Transport for TCP | |||||||||||||||||
|
This document specifies the rLEDBAT, a set of mechanisms that enable the execution of a less-than-best-effort congestion control algorithm for TCP at the receiver end. | ||||||||||||||||
| draft-irtf-icnrg-ccnx-timetlv-02.txt | |||||||||||||||||
| Alternative Delta Time Encoding for CCNx Using Compact Floating-Point Arithmetic | |||||||||||||||||
|
CCNx utilizes delta time for a number of functions. When using CCNx in environments with constrained nodes or bandwidth constrained networks, it is valuable to have a compressed representation of delta time. In order to do so, either accuracy or dynamic range has to be sacrificed. Since the current uses of delta time do not require both simultaneously, one can consider a logarithmic encoding such as that specified in [RFC5497] and [IEEE.754.2019]. This document updates _CCNx messages in TLV Format_ [RFC8609] to specify this alternative encoding. This document is a product of the IRTF Information-Centric Networking Research Group (ICNRG). | ||||||||||||||||
| draft-irtf-icnrg-flic-04.txt | |||||||||||||||||
| File-Like ICN Collections (FLIC) | |||||||||||||||||
|
This document describes a simple "index table" data structure and its associated Information Centric Networking (ICN) data objects for organizing a set of primitive ICN data objects into a large, File- Like ICN Collection (FLIC). At the core of this collection is a _manifest_ which acts as the collection's root node. The manifest contains an index table with pointers, each pointer being a hash value pointing to either a final data block or another index table node. | ||||||||||||||||
| draft-irtf-nmrg-network-digital-twin-arch-02.txt | |||||||||||||||||
| Digital Twin Network: Concepts and Reference Architecture | |||||||||||||||||
|
Digital Twin technology has been seen as a rapid adoption technology in Industry 4.0. The application of Digital Twin technology in the networking field is meant to develop various rich network applications and realize efficient and cost effective data driven network management and accelerate network innovation. This document presents an overview of the concepts of Digital Twin Network, provides the basic definitions and a reference architecture, lists a set of application scenarios, and discusses the benefits and key challenges of such technology. | ||||||||||||||||
| draft-irtf-nwcrg-bats-07.txt | |||||||||||||||||
| BATS Coding Scheme for Multi-hop Data Transport | |||||||||||||||||
|
Linear network coding can in general improve the network communication performance in terms of throughput, latency and reliability. BATched Sparse (BATS) code is a class of efficient linear network coding scheme with a matrix generalization of fountain codes as the outer code, and batch-based linear network coding as the inner code. This document describes a baseline BATS coding scheme for communication through multi-hop networks, and discusses the related research issues towards a more sophisticated BATS coding scheme. This document is a product of the Coding for Efficient Network Communications Research Group (NWCRG). | ||||||||||||||||
| draft-irtf-nwcrg-tetrys-04.txt | |||||||||||||||||
| Tetrys,an On-the-Fly Network Coding Protocol | |||||||||||||||||
|
This document describes Tetrys, an On-The-Fly Network Coding (NC) protocol that can be used to transport delay-sensitive and loss- sensitive data over a lossy network. Tetrys may recover from erasures within an RTT-independent delay, thanks to the transmission of Coded Packets. This document is a record of the experience gained by the authors while developing and testing the Tetrys protocol in real conditions. This document is a product of the Coding for Efficient Network Communications Research Group (NWCRG). It conforms to the NWCRG taxonomy[RFC8406]. | ||||||||||||||||
| draft-irtf-panrg-path-properties-08.txt | |||||||||||||||||
| A Vocabulary of Path Properties | |||||||||||||||||
|
This document is a product of the Path Aware Networking Research Group (PANRG). Path properties express information about paths across a network and the services provided via such paths. In a path-aware network, path properties may be fully or partially available to entities such as endpoints. This document defines and categorizes path properties. Furthermore, the document identifies several path properties which might be useful to endpoints or other entities, e.g., for selecting between paths or for invoking some of the provided services. | ||||||||||||||||
| draft-irtf-pearg-censorship-10.txt | |||||||||||||||||
| A Survey of Worldwide Censorship Techniques | |||||||||||||||||
|
This document describes technical mechanisms employed in network censorship that regimes around the world use for blocking or impairing Internet traffic. It aims to make designers, implementers, and users of Internet protocols aware of the properties exploited and mechanisms used for censoring end-user access to information. This document makes no suggestions on individual protocol considerations, and is purely informational, intended as a reference. This document is a product of the Privacy Enhancement and Assessment Research Group (PEARG) in the IRTF. | ||||||||||||||||
| draft-irtf-pearg-ip-address-privacy-considerations-01.txt | |||||||||||||||||
| IP Address Privacy Considerations | |||||||||||||||||
|
This document provides an overview of privacy considerations related to user IP addresses. It includes an analysis of some current use cases for tracking of user IP addresses, mainly in the context of anti-abuse. It discusses the privacy issues associated with such tracking and provides input on mechanisms to improve the privacy of this existing model. It then captures requirements for proposed 'replacement signals' for IP addresses from this analysis. In addition, existing and under-development techniques are evaluated for fulfilling these requirements. | ||||||||||||||||
| draft-irtf-pearg-numeric-ids-generation-12.txt | |||||||||||||||||
| On the Generation of Transient Numeric Identifiers | |||||||||||||||||
|
This document performs an analysis of the security and privacy implications of different types of "transient numeric identifiers" used in IETF protocols, and tries to categorize them based on their interoperability requirements and their associated failure severity when such requirements are not met. Subsequently, it provides advice on possible algorithms that could be employed to satisfy the interoperability requirements of each identifier category, while minimizing the negative security and privacy implications, thus providing guidance to protocol designers and protocol implementers. Finally, it describes a number of algorithms that have been employed in real implementations to generate transient numeric identifiers, and analyzes their security and privacy properties. This document is a product of the Privacy Enhancement and Assessment Research Group (PEARG) in the IRTF. | ||||||||||||||||
| draft-irtf-pearg-numeric-ids-history-11.txt | |||||||||||||||||
| Unfortunate History of Transient Numeric Identifiers | |||||||||||||||||
|
This document analyzes the timeline of the specification and implementation of different types of "transient numeric identifiers" used in IETF protocols, and how the security and privacy properties of such protocols have been affected as a result of it. It provides empirical evidence that advice in this area is warranted. This document is a product of the Privacy Enhancement and Assessment Research Group (PEARG) in the IRTF. | ||||||||||||||||
| draft-irtf-pearg-safe-internet-measurement-07.txt | |||||||||||||||||
| Guidelines for Performing Safe Measurement on the Internet | |||||||||||||||||
|
Internet measurement is important to researchers from industry, academia and civil society. While measurement can give insight into the functioning and usage of the Internet, it can present risks to user privacy. This document describes briefly those risks and proposes guidelines for ensuring that internet measurements can be carried out safely, with examples. | ||||||||||||||||
| draft-irtf-qirg-quantum-internet-use-cases-15.txt | |||||||||||||||||
| Application Scenarios for the Quantum Internet | |||||||||||||||||
|
The Quantum Internet has the potential to improve application functionality by incorporating quantum information technology into the infrastructure of the overall Internet. This document provides an overview of some applications expected to be used on the Quantum Internet and categorizes them. Some general requirements for the Quantum Internet are also discussed. The intent of this document is to describe a framework for applications, and describe a few selected application scenarios for the Quantum Internet. | ||||||||||||||||
| draft-irtf-t2trg-amplification-attacks-02.txt | |||||||||||||||||
| Amplification Attacks Using the Constrained Application Protocol (CoAP) | |||||||||||||||||
|
Protecting Internet of Things (IoT) devices against attacks is not enough. IoT deployments need to make sure that they are not used for Distributed Denial-of-Service (DDoS) attacks. DDoS attacks are typically done with compromised devices or with amplification attacks using a spoofed source address. This document gives examples of different theoretical amplification attacks using the Constrained Application Protocol (CoAP). The goal with this document is to raise awareness and to motivate generic and protocol-specific recommendations on the usage of CoAP. Some of the discussed attacks can be mitigated by not using NoSec or by using the Echo option. | ||||||||||||||||
| draft-irtf-t2trg-iot-edge-08.txt | |||||||||||||||||
| IoT Edge Challenges and Functions | |||||||||||||||||
|
Many IoT applications have requirements that cannot be met by the traditional Cloud (aka cloud computing). These include time sensitivity, data volume, connectivity cost, operation in the face of intermittent services, privacy, and security. As a result, the IoT is driving the Internet toward Edge computing. This document outlines the requirements of the emerging IoT Edge and its challenges. It presents a general model, and major components of the IoT Edge, to provide a common base for future discussions in T2TRG and other IRTF and IETF groups. This document is a product of the IRTF Thing-to-Thing Research Group (T2TRG). | ||||||||||||||||
| draft-irtf-t2trg-rest-iot-11.txt | |||||||||||||||||
| Guidance on RESTful Design for Internet of Things Systems | |||||||||||||||||
|
This document gives guidance for designing Internet of Things (IoT) systems that follow the principles of the Representational State Transfer (REST) architectural style. This document is a product of the IRTF Thing-to-Thing Research Group (T2TRG). | ||||||||||||||||
| draft-irtf-t2trg-security-setup-iot-devices-00.txt | |||||||||||||||||
| Terminology and processes for initial security setup of IoT devices | |||||||||||||||||
|
This document provides an overview of terms that are commonly used when discussing the initial security setup of Internet of Things (IoT) devices. This document also presents a brief but illustrative survey of protocols and standards available for initial security setup of IoT devices. For each protocol, we identify the terminology used, the entities involved, the initial assumptions, the processes necessary for completion, and the knowledge imparted to the IoT devices after the setup is complete. | ||||||||||||||||
| draft-irtf-t2trg-taxonomy-manufacturer-anchors-00.txt | |||||||||||||||||
| A Taxonomy of operational security considerations for manufacturer installed keys and Trust Anchors | |||||||||||||||||
|
This document provides a taxonomy of methods used by manufacturers of silicon and devices to secure private keys and public trust anchors. This deals with two related activities: how trust anchors and private keys are installed into devices during manufacturing, and how the related manufacturer held private keys are secured against disclosure. This document does not evaluate the different mechanisms, but rather just serves to name them in a consistent manner in order to aid in communication. RFCEDITOR: please remove this paragraph. This work is occurring in https://github.com/mcr/idevid-security-considerations | ||||||||||||||||
| draft-iurman-6man-carry-identifier-00.txt | |||||||||||||||||
| Carrying an Identifier in IPv6 packets | |||||||||||||||||
|
Some recent use cases have a need for carrying an identifier in IPv6 packets. While those drafts might perfectly make sense on their own, each document requires IANA to allocate a new code point for a new option, and so for very similar situations, which could quickly exhaust the allocation space if similar designs are proposed in the future. As an example, one might need an 8-bit ID, while another one might need a 32-bit, 64-bit or 128-bit ID. Or, even worse, one might need a 32-bit ID in a specific context, while someone else might also need a 32-bit ID in another context. Therefore, allocating a new code point for each similar option is probably not the way to go. | ||||||||||||||||
| draft-jags-mpls-ps-mna-hdr-00.txt | |||||||||||||||||
| Post-Stack MPLS Network Action (MNA) Solution | |||||||||||||||||
|
This document defines the Post-Stack MPLS Network Action (MNA) solution for carrying Network Actions and Ancillary Data after the MPLS label stack based on In-Stack MNA solution defined in draft- ietf-mpls-mna-hdr. MPLS Network Actions can be used to influence packet forwarding decisions, carry additional OAM information in the MPLS packet or perform user-defined operations. This document addresses the MNA requirements specified in draft-ietf-mpls-mna- requirements. This document follows the MNA framework specified in draft-ietf-mpls-mna-fwk. | ||||||||||||||||
| draft-jain-lisp-site-external-connectivity-08.txt | |||||||||||||||||
| LISP Site External Connectivity | |||||||||||||||||
|
This draft defines how to register/retrieve pETR mapping information in LISP when the destination is not registered/known to the local site and its mapping system (e.g. the destination is an internet or external site destination). | ||||||||||||||||
| draft-janz-nmrg-performance-digital-twin-00.txt | |||||||||||||||||
| Functional Design Aspects of Performance-Oriented Digital Twins | |||||||||||||||||
|
Performance-Oriented Digital Twins (PODTs) provide "what-if" analysis - predictions of performance or, perhaps, of other behaviours in hypothetical situations of network, services, traffic, etc. Key functional and design aspects of PODTs in support of multiple, concurrently-operating use case Management Plane (MP) applications are discussed. Data and model management in concurrent session handling, inter-working with variable composition (from data and functional model perspectives) networks, performance and scalability are considered. | ||||||||||||||||
| draft-jennings-dispatch-game-state-over-rtp-01.txt | |||||||||||||||||
| Game State over Real Time Protocol | |||||||||||||||||
|
This specification defines an Real Time Protocol (RTP) payload to send game moves and the state of game objects over RTP. This is useful for games as well collaboration systems that use augment or virtual reality. RTP provide a way to synchronize game state between players with robust technique for recovery from network packet loss while still having low latency. | ||||||||||||||||
| draft-jennings-mimi-quicr-proto-00.txt | |||||||||||||||||
| QuicR - Media Delivery Protocol over QUIC | |||||||||||||||||
|
This specification QuicR, an unified media delivery protocol over QUIC. It aims at supporting multiple application classes with varying latency requirements including ultra low latency applications such as interactive communication and gaming. It is based on a publish/subscribe metaphor where entities publish and subscribe to data that is sent through, and received from, relays in the cloud. The information subscribed to is named such that this forms an overlay information centric network. The relays allow for efficient large scale deployments. | ||||||||||||||||
| draft-jennings-moq-proto-00.txt | |||||||||||||||||
| QuicR - Media Delivery Protocol over QUIC | |||||||||||||||||
|
This specification QuicR, an unified media delivery protocol over QUIC. It aims at supporting multiple application classes with varying latency requirements including ultra low latency applications such as interactive communication and gaming. It is based on a publish/subscribe metaphor where entities publish and subscribe to data that is sent through, and received from, relays in the cloud. The information subscribed to is named such that this forms an overlay information centric network. The relays allow for efficient large scale deployments. | ||||||||||||||||
| draft-jeong-6man-ipmon-problem-statement-01.txt | |||||||||||||||||
| IPv6 Mobile Object Networking (IPMON): Problem Statement and Use Cases | |||||||||||||||||
|
This document discusses the problem statement and use cases of IPv6 Mobile Object Networking (IPMON). A moving object is a physically movable networked device with 5G communication capability, such as a terrestrial vehicle (e.g., car and motorcycle), a user's smart device (e.g., smartphone, smart watch, and tablet), an aerial vehicle (e.g., drone and helicopter), and a marine vehicle (e.g., boat and ship). These mobile objects are called vehicles in this document. The main scenarios of vehicular communications are vehicle-to-vehicle (V2V), vehicle-to-infrastructure (V2I), and vehicle-to-everything (V2X) communications. First, this document explains use cases using V2V, V2I, and V2X networking over 5G. Next, for IPv6-over-5G vehicular networks, it makes a gap analysis of current IPv6 protocols (e.g., IPv6 Neighbor Discovery). | ||||||||||||||||
| draft-jeong-6man-ipv6-over-5g-v2x-01.txt | |||||||||||||||||
| Basic Support for IPv6 Networks Operating over 5G Vehicle-to-Everything Communications | |||||||||||||||||
|
This document provides methods and settings for using IPv6 to communicate among IPv6 nodes within the communication range of one another over 5G V2X (i.e., the 5th Generation Vehicle-to-Everything) links. Support for these methods and settings require minimal changes to existing protocol stacks. This document also describes limitations associated with using these methods. Optimizations and usage of IPv6 over more complex scenarios are not covered in this specification and are a subject for future work. | ||||||||||||||||
| draft-jeong-i2nsf-security-management-automation-05.txt | |||||||||||||||||
| Security Management Automation of Cloud-Based Security Services in I2NSF Framework | |||||||||||||||||
|
This document describes Security Management Automation (SMA) of cloud-based security services in the framework of Interface to Network Security Functions (I2NSF). The security management automation in this document deals with closed-loop security control, security policy translation, and security audit. To support these three features in SMA, this document specifies an augmented architecture of the I2NSF framework with new system components and new interfaces. | ||||||||||||||||
| draft-jeong-ipwave-context-aware-navigator-07.txt | |||||||||||||||||
| Context-Aware Navigation Protocol for IP-Based Vehicular Networks | |||||||||||||||||
|
This document proposes a Context-Aware Navigation Protocol (CNP) for IP-based vehicular networks for cooperative navigation among vehicles in road networks. This CNP aims at the enhancement of driving safety through a light-weight driving information sharing method. The CNP protocol uses an IPv6 Neighbor Discovery (ND) option to convey driving information such as a vehicle's position, speed, acceleration/deceleration, and direction, and a driver's driving action (e.g., braking and accelerating). | ||||||||||||||||
| draft-jeong-ipwave-iot-dns-autoconf-15.txt | |||||||||||||||||
| DNS Name Autoconfiguration for Internet-of-Things Devices in IP-Based Vehicular Networks | |||||||||||||||||
|
This document specifies an autoconfiguration scheme for device discovery and service discovery in IP-based vehicular networks. Through the device discovery, this document supports the global (or local) DNS naming of Internet-of-Things (IoT) devices, such as sensors, actuators, and in-vehicle units. By this scheme, the DNS name of an IoT device can be autoconfigured with the device's model information in wired and wireless target networks (e.g., vehicle, road network, home, office, shopping mall, and smart grid). Through the service discovery, IoT users (e.g., drivers, passengers, home residents, and customers) in the Internet (or local network) can easily identify each device for monitoring and remote-controlling it in a target network. | ||||||||||||||||
| draft-jeong-ipwave-security-privacy-07.txt | |||||||||||||||||
| Basic Support for Security and Privacy in IP-Based Vehicular Networks | |||||||||||||||||
|
This document describes possible attacks of security and privacy in IP Wireless Access in Vehicular Environments (IPWAVE). It also proposes countermeasures for those attacks. | ||||||||||||||||
| draft-jeong-ipwave-vehicular-mobility-management-09.txt | |||||||||||||||||
| Vehicular Mobility Management for IP-Based Vehicular Networks | |||||||||||||||||
|
This document specifies a Vehicular Mobility Management (VMM) scheme for IP-based vehicular networks. The VMM scheme takes advantage of a vehicular link model based on a multi-link subnet. With a vehicle's mobility information (e.g., position, speed, acceleration/ deceleration, and direction) and navigation path (i.e., trajectory), it can provide a moving vehicle with proactive and seamless handoff along with its trajectory. | ||||||||||||||||
| draft-jeong-ipwave-vehicular-neighbor-discovery-15.txt | |||||||||||||||||
| Vehicular Neighbor Discovery for IP-Based Vehicular Networks | |||||||||||||||||
|
This document specifies a Vehicular Neighbor Discovery (VND) as an extension of IPv6 Neighbor Discovery (ND) for IP-based vehicular networks. An optimized Address Registration and a multihop Duplicate Address Detection (DAD) mechanism are performed for having operation efficiency and also saving both wireless bandwidth and vehicle energy. In addition, three new ND options for prefix discovery, service discovery, and mobility information report are defined to announce the network prefixes and services inside a vehicle (i.e., a vehicle's internal network). | ||||||||||||||||
| draft-jeong-nmrg-ibn-network-management-automation-00.txt | |||||||||||||||||
| Intent-Based Network Management Automation in 5G Core Networks | |||||||||||||||||
|
This document describes Network Management Automation (NMA) of cellular network services in 5G core networks. For NMA, it proposes a framework empowered with Intent-Based Networking (IBN). The NMA in this document deals with closed-loop network control, network policy translation, and network management audit. To support these three features in NMA, it specifies an architectural framework with system components and interfaces. Also, this framework can support the use cases of NMA in 5G core networks such as the data aggregation of Internet of Things (IoT) devices, network slicing, and the Quality of Service (QoS) in Vehicle-to-Everything (V2X). | ||||||||||||||||
| draft-jesske-update-p-visited-network-04.txt | |||||||||||||||||
| Update to Private Header Field P-Visited-Network-ID in Session Initiation Protocol (SIP) Requests and Responses | |||||||||||||||||
|
The Third Generation Partnership Project (3GPP) has identified cases where the private header field P-Visited-Network-ID SIP private header extensions, which is defined in RFC 7315 and updated by RFC 7976, needs to be included in SIP requests and responses. This document updates RFC 7976, in order to allow inclusion of the P- Visited-Network-ID header field in responses. | ||||||||||||||||
| draft-jfinkhaeuser-caps-for-distributed-auth-00.txt | |||||||||||||||||
| Capabilities for Distributed Authorization | |||||||||||||||||
|
Authorization is often the last remaining centralized function in a distributed system. Advances in compute capabilities of miniaturized CPUs make alternative cryptographic approaches feasible that did not find such use when first envisioned. This document describes the elements of such cryptographically backed distributed authorization schemes as a reference for implementations. | ||||||||||||||||
| draft-jgc-netconf-privcand-01.txt | |||||||||||||||||
| NETCONF Private Candidates | |||||||||||||||||
|
This document provides a mechanism to extend the Network Configuration Protocol (NETCONF) to support multiple clients making configuration changes simultaneously and ensuring that they commit only those changes that they defined. This document addresses two specific aspects: The interaction with a private candidate over the NETCONF protocol and the methods to identify and resolve conflicts between clients. | ||||||||||||||||
| draft-jiang-spring-parent-sr-policy-use-cases-01.txt | |||||||||||||||||
| Use Cases for Parent SR Policy | |||||||||||||||||
|
Segment Routing is a source routing paradigm that explicitly indicates the forwarding path for packets at the ingress node. An SR Policy is associated with one or more candidate paths, and each candidate path is dynamic, explicit or composite. This document illustrates some use cases for parent SR policy in MPLS and IPv6 environment. | ||||||||||||||||
| draft-jiang7369-webrtc-uri-scheme-02.txt | |||||||||||||||||
| The WebRTC URI Scheme | |||||||||||||||||
|
This document registers the "wr://" and "wrs://" URI schemes to aid in the connect of WebRTC. | ||||||||||||||||
| draft-jilongwang-opsawg-crc-04.txt | |||||||||||||||||
| Framework for Cyberspace Resources Categorization | |||||||||||||||||
|
This memo presents the definition of cyberspace resource, and then discusses a classification framework for cyberspace resources. Cyberspace is widely applied in people's daily life and it is regarded as a new space, paralleled to the geographic space. There are various resources in cyberspace. However, they have not been systematically defined and classified. The objective of this draft is to present the deifinition of cyberspace resource and a standard classification framework, thus, supporting the unified resource storage and shares. | ||||||||||||||||
| draft-jilongwang-opsawg-cybersmap-07.txt | |||||||||||||||||
| Design of the native Cyberspace Map | |||||||||||||||||
|
This memo discusses the design of the native cyberspace map which is stable and flexible to describe cyberspace. Although we have accepted the cyberspace as a parallel new world, we even have not defined its basic coordinate system, which means cyberspace have no its basic space dimension till now. The objective of this draft is to illustrate the basic design methodology of the native coordinate system of cyberspace, and show how to design cyberspace map on this basis. | ||||||||||||||||
| draft-jilongwang-opsawg-iog-00.txt | |||||||||||||||||
| A Collaborative Framework for Cyberspace Governance: the Internet of Governance | |||||||||||||||||
|
This document proposes the Internet of Governance (IoG), a new technology supporting platform for cyberspace collaborative governance. This document illustrates IoG definition, two roles and four functionalities, and develops architectural models to carry out these functionalities. This document provides the design of IoG framework and the collaboration life-cycle and uses some practical applications as examples. | ||||||||||||||||
| draft-jmiller-jose-json-proof-algorithms-01.txt | |||||||||||||||||
| JSON Proof Algorithms | |||||||||||||||||
|
The JSON Proof Algorithms (JPA) specification registers cryptographic algorithms and identifiers to be used with the JSON Web Proof (JWP) (https://www.ietf.org/archive/id/draft-jmiller-jose-json-web-proof- 01.html) and JSON Web Key (JWK) specifications. It defines several IANA registries for these identifiers. | ||||||||||||||||
| draft-jmiller-jose-json-proof-token-01.txt | |||||||||||||||||
| JSON Proof Token | |||||||||||||||||
|
JSON Proof Token (JPT) is a compact, URL-safe, privacy-preserving representation of claims to be transferred between three parties. The claims in a JPT are encoded as base64url-encoded JSON objects that are used as the payloads of a JSON Web Proof (JWP) (https://www.ietf.org/archive/id/draft-jmiller-jose-json-web-proof- 01.html) structure, enabling them to be digitally signed and selectively disclosed. JPTs also support reusability and unlinkability when using Zero-Knowledge Proofs (ZKPs). | ||||||||||||||||
| draft-jmiller-jose-json-web-proof-01.txt | |||||||||||||||||
| JSON Web Proof | |||||||||||||||||
|
The JOSE set of standards established JSON-based container formats for Keys (https://datatracker.ietf.org/doc/rfc7517/), Signatures (https://datatracker.ietf.org/doc/rfc7515/), and Encryption (https://datatracker.ietf.org/doc/rfc7516/). They also established IANA registries (https://www.iana.org/assignments/jose/jose.xhtml) to enable the algorithms and representations used for them to be extended. Since those were created, newer cryptographic algorithms that support selective disclosure and unlinkability have matured and started seeing early market adoption. This document defines a new container format similar in purpose and design to JSON Web Signature (JWS) called a _JSON Web Proof (JWP)_. Unlike JWS, which integrity-protects only a single payload, JWP can integrity-protect multiple payloads in one message. It also specifies a new presentation form that supports selective disclosure of individual payloads, enables additional proof computation, and adds a protected header to prevent replay and support binding mechanisms. | ||||||||||||||||
| draft-johani-tld-zone-pipeline-00.txt | |||||||||||||||||
| TLD Zone Pipeline: Requirements And Design Principles | |||||||||||||||||
|
Today most TLD registries publish DNSSEC signed zones. The sequence of steps from generating the unsigned zone, via DNSSEC signing and various types of verification is referred to as the "zone pipeline". The robustness and correctness of the zone pipeline is of crucial importance and the zone pipeline is one of the most critical parts of the operations of a TLD registry. After a serious incident in 2022, the .SE Registry decided to re- evaluate the requirements on the zone pipeline. This has led to several new design choices and a decision to create a more robust implementation from scratch. The goal of this document is to describe the requirements that the .SE Registry choose in preparation for the implementation of the new zone pipeline. The document also describes some of the design consequences that follow from the requirements. Hence this document is intended to work as a guide for understanding the actual implementation, which is planned to be released as open source. TO BE REMOVED: This document is being collaborated on in Github at: https://github.com/johanix/draft-johani-tld-zone-pipeline (https://github.com/johanix/draft-johani-tld-zone-pipeline). The most recent working version of the document, open issues, etc. should all be available there. The authors (gratefully) accept pull requests. | ||||||||||||||||
| draft-jones-oauth-resource-metadata-02.txt | |||||||||||||||||
| OAuth 2.0 Protected Resource Metadata | |||||||||||||||||
|
This specification defines a metadata format that an OAuth 2.0 client can use to obtain the information needed to interact with an OAuth 2.0 protected resource. | ||||||||||||||||
| draft-joung-detnet-asynch-detnet-framework-02.txt | |||||||||||||||||
| Asynchronous Deterministic Networking Framework for Large-Scale Networks | |||||||||||||||||
|
This document describes an overall framework of Asynchronous Deterministic Networking (ADN) for large-scale networks. It specifies the functional architecture and requirements for providing latency and jitter bounds to high priority traffic, without strict time-synchronization of network nodes. | ||||||||||||||||
| draft-jt-add-dns-server-redirection-01.txt | |||||||||||||||||
| Handling Encrypted DNS Server Redirection | |||||||||||||||||
|
This document defines Encrypted DNS Server Redirection (EDSR), a mechanism for encrypted DNS servers to redirect clients to other encrypted DNS servers. This enables dynamic routing to geo-located or otherwise more desirable encrypted DNS servers without modifying DNS client endpoint configurations or the use of anycast by the DNS server. | ||||||||||||||||
| draft-kaippallimalil-tsvwg-media-hdr-wireless-01.txt | |||||||||||||||||
| Media Header Extensions 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 are able to dynamically adjust the size and quality of a stream to match available network bandwidth. However, catering to such media flows over a radio link where the capacity changes rapidly requires the buffers and QoS in general to be managed carefully. This draft proposes additional information about the media transported in each packet to manage the buffers and optimize the scheduling of radio resources. The set of information proposed here includes importance of the packet, burst length and time budget to be conveyed by the media application in a new UDP option. The metadata in the UDP option is used to provide the wireless network the flexibility to prioritize packets that are essential when the radio capacity is temporarily low, defer packets that can tolerate some additional delay, or even drop packets selectively in more extreme conditions. This draft defines media metadata, a new UDP option to carry this metadata and the operational aspects for using it between a UDP source and a on-path wireless entity. | ||||||||||||||||
| draft-kaliraj-bess-bgp-sig-private-mpls-labels-05.txt | |||||||||||||||||
| BGP signaled MPLS namespaces | |||||||||||||||||
|
The MPLS forwarding layer in a core network is a shared resource. The MPLS FIB at nodes in this layer contains labels that are dynamically allocated and locally significant at that node. These labels are scoped in context of the global loopback address. Let us call this the global MPLS namespace. For some usecases like upstream label allocation, it is useful to create private MPLS namespaces (virtual MPLS FIB) over this shared MPLS forwarding layer. This allows installing deterministic label values in the private FIBs created at nodes participating in the private MPLS namespace, while preserving the "locally significant" nature of the underlying shared global MPLS FIB. This specification describes the procedures to create such virtual private MPLS forwarding layers (private MPLS namespaces) using a new BGP family. And gives a few example use-cases on how this private forwarding layers can be used. | ||||||||||||||||
| draft-kaliraj-idr-multinexthop-attribute-04.txt | |||||||||||||||||
| BGP MultiNexthop Attribute | |||||||||||||||||
|
Today, a BGP speaker can advertise one nexthop for a set of NLRIs in an Update. This nexthop can be encoded in either the BGP-Nexthop attribute (code 3), or inside the MP_REACH_NLRI attribute (code 14). For cases where multiple nexthops need to be advertised, BGP-Addpath is used. Though Addpath allows basic ability to advertise multiple- nexthops, it does not allow the sender to specify desired relationship between the multiple nexthops being advertised e.g., relative-preference, type of load-balancing. These are local decisions at the receiving speaker based on local configuration and path-selection between the various additional-paths, which may tie- break on some arbitrary step like Router-Id or BGP nexthop address. Some scenarios with a BGP-free core may benefit from having a mechanism, where egress-node can signal multiple-nexthops along with their relationship, in one BGP route, to ingress nodes. This document defines a new BGP attribute "MultiNexthop (MNH)" that can be used for this purpose. This attribute can be used for both labeled and unlabled BGP families. The MNH can be used to advertise MPLS label along with nexthop for unlabeled families (e.g. Inet Unicast, Inet6 Unicast). Such that, mechanisms at the transport layer can work uniformly on labeled and unlabled BGP families. Service route scale can be confined closer to the service edge nodes, making the transport layer nodes light and nimble. They dont have any service route state, only have service end-point state. The MNH plays different role in "downstream allocation" scenario than "upstream allocation" scenario. E.g. for [RFC8277] families that advertise downstream allocated labels, the MNH can play the "Label Descriptor" role, describing the forwarding semantics of the label being advertised. This can be useful in network visualization and controller based traffic engineering (e.g. EPE). | ||||||||||||||||
| draft-kampanakis-curdle-ssh-pq-ke-01.txt | |||||||||||||||||
| Post-quantum Hybrid Key Exchange in SSH | |||||||||||||||||
|
This document defines post-quantum hybrid key exchange methods based on classical ECDH key exchange and post-quantum key encapsulation schemes. These methods are defined for use in the SSH Transport Layer Protocol. Note [EDNOTE: Discussion of this work is encouraged to happen on the IETF WG Mailing List or in the GitHub repository which contains the draft: https://github.com/csosto-pk/pq-ssh/issues.] | ||||||||||||||||
| draft-kampanakis-tls-scas-latest-03.txt | |||||||||||||||||
| Suppressing CA Certificates in TLS 1.3 | |||||||||||||||||
|
A TLS client or server that has access to the complete set of published intermediate certificates can inform its peer to avoid sending certificate authority certificates, thus reducing the size of the TLS handshake. | ||||||||||||||||
| draft-kang-quic-apps-multiplexing-a-session-02.txt | |||||||||||||||||
| Applications Multiplexing a QUIC Session | |||||||||||||||||
|
This document describes the requirements for extensions on QUIC transport protocol in the use case when multiple application protocols reuse the same QUIC session for data transmission. | ||||||||||||||||
| draft-kang-quic-oneway-delays-in-multipath-02.txt | |||||||||||||||||
| Comparing One-way Delays in Multipath | |||||||||||||||||
|
This document provides a solution for comparing one-way delays in multipath quic. In this solution, through message interaction between data receiver and data sender, the data sender can obtain delay rankings of multiple specified uniflows, providing reference for sending data packets. | ||||||||||||||||
| draft-kang-tcpm-accurate-data-scheduling-by-server-04.txt | |||||||||||||||||
| Accurate Data Scheduling by Server in MPTCP | |||||||||||||||||
|
This document defines a new mechanism that enables MPTCP server to send requests to MPTCP client for data scheduling between specified subflows during a MPTCP session. | ||||||||||||||||
| draft-kang-tcpm-fault-management-in-mptcp-session-02.txt | |||||||||||||||||
| Fault Management Mechanism in MPTCP Session | |||||||||||||||||
|
This document presents a mechanism for fault management during a MPTCP session. It is used to convey subflow failure information from client to server by other subflow running normally. It includes: 1) a new Fault Announce Option for describing subflow failure, 2) implementation and interoperability of this option during a MPTCP session when one subflow suffers a failure. In fact, the server is able to determine network problems accurately based on these fault information reported from multiple clients for their connections. | ||||||||||||||||
| draft-kang-tcpm-subtype-capability-exchange-02.txt | |||||||||||||||||
| Subtype Capability Exchange During MPTCP Handshake | |||||||||||||||||
|
Multipath TCP provides the ability to simultaneously use multiple paths between peers. MPTCP protocol defines seven subtypes in MPTCP v0 [RFC6824] and ten subtypes in MPTCP v1 [RFC8684] to differentiate message types and implement some additional functions during a session. This draft proposes an enhancement to support Subtype Capability Exchange during MPTCP connection establishment in order to improve elastic scalability of MPTCP protocol. It includes: 1) requirements for which this kind of capability exchange during handshake is important for a MPTCP session; 2) a typical flow for Subtype Capability Exchange between peers; 3) a feasible solution on protocol design is suggested. | ||||||||||||||||
| draft-karcz-uuas-01.txt | |||||||||||||||||
| Unified User-Agent String | |||||||||||||||||
|
User-Agent is a HTTP request-header field. It contains information about the user agent originating the request, which is often used by servers to help identify the scope of reported interoperability problems, to work around or tailor responses to avoid particular user agent limitations, and for analytics regarding browser or operating system use. Over the years contents of this field got complicated and ambiguous. That was the reaction for sending altered version of websites to web browsers other than popular ones. During the development of the WWW, authors of the new web browsers used to construct User-Agent strings similar to Netscape's one. Nowadays contents of the User-Agent field are much longer than 15 years ago. This Memo proposes the Uniform User-Agent String as a way to simplify the User-Agent field contents, while maintaining the previous possibility of their use. | ||||||||||||||||
| draft-karstens-dnssd-dns-msd-01.txt | |||||||||||||||||
| DNS-Based Multicast Stream Discovery | |||||||||||||||||
|
This document describes an application of DNS-SD for the advertisement and discovery of multicast streams. This is especially useful with multicast streams that use a dynamically-assigned multicast address. | ||||||||||||||||
| draft-karstens-pim-ipv6-zeroconf-assignment-01.txt | |||||||||||||||||
| Zero-Configuration Assignment of IPv6 Multicast Addresses | |||||||||||||||||
|
Marine networks contain a combination of sensors, controls, and displays. The latest marine industry standards require IPv6. The most optimal way to distribute sensor data to all displays on the network is multicast. However, use of traditional switches can be problematic (overwhelm links) when both high-bandwidth and low- bandwidth devices are installed. To solve this problem, the network requires switches with multicast snooping. However, source-specific multicast (SSM) is not supported on marine switches so the destination address is the only way to differentiate multicast streams. This limitation creates several challenges including with the pre-allocation of multicast group addresses. The solution, described in this draft, provides a decentralized, zero-configuration method for dynamically assigning multicast group addresses through defining an extension to the multicast portion of the IPv6 addressing architecture along with a new table in the IPv6 Multicast Address Space Registry. | ||||||||||||||||
| draft-khatri-sipcore-call-transfer-fail-response-04.txt | |||||||||||||||||
| A SIP Response Code (497) for Call Transfer Failure | |||||||||||||||||
|
This document defines the 497 (Call Transfer Failure) SIP response code, allowing Call Pull and Call Push parties to indicate that the operation was rejected. Optional warning codes are defined to carry granular information. SIP entities may use this information to adjust how subsequent calls can be handled intelligently. | ||||||||||||||||
| draft-kim-i2nsf-security-controller-interface-dm-01.txt | |||||||||||||||||
| I2NSF Security Controller-Facing Interface YANG Data Model for Cross-Domain IPsec Flow Protection | |||||||||||||||||
|
This document defines an information model and a YANG data model for the Security Controller-Facing Interface between two security controllers in an Interface to Network Security Functions (I2NSF) framework located in different Domains. This interface is used for the exchange of IPsec flow protection to protect the IP Communication between two Network Security Functions (NSFs) in cross-domain environments. The YANG data model in this document is built on the basis of the YANG data model for IPsec flow protection based on Software-Defined Networking (SDN). | ||||||||||||||||
| draft-king-rtgwg-challenges-in-routing-01.txt | |||||||||||||||||
| Challenges for the Internet Routing Systems Introduced by Semantic Networking | |||||||||||||||||
|
Historically, the meaning of an IP address has been to identify an interface on a network device. Routing protocols were developed based on the assumption that a destination address had this semantic. Over time, routing decisions have been enhanced to determine paths on which packets could be forwarded according to additional information carried principally within the packet headers, and dependent on policy coded in, configured at, or signaled to the routers. Many proposals have been made to add semantics to IP packets by placing additional information into existing fields, by adding semantics to IP addresses, or by adding fields to the packets. The intent is always to facilitate routing decisions based on these additional semantics in order to provide differentiated paths to enable forwarding of different packet flows on paths that may be distinct from those derived by shortest path first or path vector routing. We call this approach "Semantic Networking". This document describes the challenges to the existing routing system that are introduced by Semantic Networking. It then summarizes the opportunities for research into new or modified routing and forwarding approaches that make use of additional semantics. This document is presented as a study to support further research into clarifying and understanding the issues. It does not pass comment on the advisability or practicality of any of the proposals and does not define any technical solutions. | ||||||||||||||||
| draft-king-rtgwg-semantic-networking-survey-00.txt | |||||||||||||||||
| A Survey of Semantic Internet Networking Techniques | |||||||||||||||||
|
The Internet Protocol (IP) has become the global standard in any computer network, independent of the connectivity to the Internet. Generally, an IP address is used to identify an interface on a network device. Routing protocols are also required and developed based on the assumption that a destination address has this semantic with routing decisions made on addresses and additional fields in the packet headers. Over time, routing decisions were enhanced to route packets according to additional information carried within the packets and dependent on policy coded in, configured at, or signaled to the routers. Many proposals have been made to add semantics to IP addresses. The intent is usually to facilitate routing decisions based solely on the address and without finding and processing information carried in other fields within the packets. This document is presented as a survey to support the study and further research into clarifying and understanding the issues. It does not pass comment on the advisability or practicality of any of the proposals and does not define any technical solutions | ||||||||||||||||
| draft-king-tvr-ntn-challanges-00.txt | |||||||||||||||||
| Time Variant Challenges for Non-Terrestrial Networks | |||||||||||||||||
|
Advanced networks, including the Internet, will utilise an increasing amount of Non-Terrestrial Network (NTN) infrastructure. NTNs include Low Earth Orbit (LEO) satellites, High Altitude Long Endurance (HALE) aviation, and High-Altitude Platform Stations (HAPS). In addition, NTN infrastructure will facilitate the deployment of advanced 5G use cases and services. NTNs infrastructure is typically mobile, with various links and nodes operating at different altitudes and latencies. Some NTN nodes and links are temporal and need to be scheduled and established at specific times based on line-of-sight availability, traffic demand and power budgets. This document summarises time variant NTN requirements and challenges not met by existing routing and traffic engineering techniques. | ||||||||||||||||
| draft-kjsun-lisp-dyncast-03.txt | |||||||||||||||||
| LISP for Computing-Aware Networking | |||||||||||||||||
|
When a service has been distributed over many locations in the network, providing service by utilizing computing resources hosted in various servers is required to consider supporting delay-sensitive service and optimizing network loads. For that reason, Computing- Aware Networking (CAN) is a new routing approach to balance services using service-specific metrics instead of simply dispatching the service request in a static way or optimizing solely connectivity metrics [draft-liu-can-ps-usecases]. Currently, CAN solutions are discussed with both existing technologies (e.g., DNS, L7 Load Balancer, etc.) and a new approach. In this document, it describes the LISP-based CAN approach and related standard works to meet requirements. | ||||||||||||||||
| draft-klensin-idna-rfc5891bis-06.txt | |||||||||||||||||
| Internationalized Domain Names in Applications (IDNA): Registry Restrictions and Recommendations | |||||||||||||||||
|
The IDNA specifications for internationalized domain names combine rules that determine the labels that are allowed in the DNS without violating the protocol itself and an assignment of responsibility, consistent with earlier specifications, for determining the labels that are allowed in particular zones. Conformance to IDNA by registries and other implementations requires both parts. Experience strongly suggests that the language describing those responsibilities was insufficiently clear to promote safe and interoperable use of the specifications and that more details and discussion of circumstances would have been helpful. Without making any substantive changes to IDNA, this specification updates two of the core IDNA documents (RFCs 5890 and 5891) and the IDNA explanatory document (RFC 5894) to provide that guidance and to correct some technical errors in the descriptions. | ||||||||||||||||
| draft-klh-dnsop-rfc8109bis-05.txt | |||||||||||||||||
| Initializing a DNS Resolver with Priming Queries | |||||||||||||||||
|
This document describes the queries that a DNS resolver should emit to initialize its cache. The result is that the resolver gets both a current NS Resource Record Set (RRset) for the root zone and the necessary address information for reaching the root servers. This document, when published, obsoletes RFC 8109. | ||||||||||||||||
| draft-km-detnet-for-ocn-00.txt | |||||||||||||||||
| Using Deterministic Networks for Industry Operations and Control | |||||||||||||||||
|
Remote industrial process control & operations improve automation, resource efficiency, safety and better overall control from the software-defined application logic. So far, industrial/process automation connectivity is mostly localized. In order to use cloud- based connectivity, not only deterministic networks are needed but an interface between the endpoints and the DetNet is required to be clearly described. This document describes an interface to deterministic networks from the view of end-points to support process control and operations. | ||||||||||||||||
| draft-knodel-e2ee-definition-09.txt | |||||||||||||||||
| Definition of End-to-end Encryption | |||||||||||||||||
|
This document provides a definition of end-to-end encryption (E2EE) rom both the perspective of a regular internet user as well as from the perspective of required properties for implementers. | ||||||||||||||||
| draft-knodel-terminology-13.txt | |||||||||||||||||
| Terminology,Power,and Inclusive Language in Internet-Drafts and RFCs | |||||||||||||||||
|
This document argues for more inclusive language conventions sometimes used by RFC authors and the RFC Production Centre in Internet-Drafts that are work in progress, and in new RFCs that may be published in any of the RFC series, in order to foster greater knowledge transfer and improve diversity of participation in the IETF. It is important to note that this is not standard, it does not represent IETF consensus, and should not be misconstrued as anything other than the authors' views. | ||||||||||||||||
| draft-koch-openpgp-2015-rfc4880bis-01.txt | |||||||||||||||||
| OpenPGP Message Format | |||||||||||||||||
|
{ Work in progress to update the OpenPGP specification from RFC4880. Editorial notes are enclosed in curly braces. } { This draft is based on the Git head as pf rfc4880bis-10 before the great refactoring. That refactoring, dubbed crypto-refresh, basically started from scratch with lots of re-formatting and switching to a Gitlab based approach with merge requests mainly prepared in advance by one of the chairs. This was done despite that -10 was basically ready for last call after a long iterative process adding feature by feature with rough consent from the WG. Due to the IETF submission system the draft was renamed but nevertheless is in apostolic succession of draft-ietf-openpgp- rfc4880bis-10 } This document specifies the message formats used in OpenPGP. OpenPGP provides encryption with public-key or symmetric cryptographic algorithms, digital signatures, compression and key management. This document is maintained in order to publish all necessary information needed to develop interoperable applications based on the OpenPGP format. It is not a step-by-step cookbook for writing an application. It describes only the format and methods needed to read, check, generate, and write conforming packets crossing any network. It does not deal with storage and implementation questions. It does, however, discuss implementation issues necessary to avoid security flaws. | ||||||||||||||||
| draft-koch-openpgp-webkey-service-15.txt | |||||||||||||||||
| OpenPGP Web Key Directory | |||||||||||||||||
|
This specification describes a service to locate OpenPGP keys by mail address using a Web service and the HTTPS protocol. It also provides a method for secure communication between the key owner and the mail provider to publish and revoke the public key. | ||||||||||||||||
| draft-kohno-dmm-srv6mob-arch-06.txt | |||||||||||||||||
| Architecture Discussion on SRv6 Mobile User plane | |||||||||||||||||
|
This document discusses the solution approach and its architectural benefits of translating mobile session information into routing information, applying segment routing capabilities, and operating in a routing paradigm. | ||||||||||||||||
| draft-koldychev-pce-operational-07.txt | |||||||||||||||||
| PCEP Operational Clarification | |||||||||||||||||
|
This document updates, simplifies and clarifies certain aspects of the PCEP protocol. The content of this document has been compiled based on several interop exercises. | ||||||||||||||||
| draft-kozuka-quic-failover-00.txt | |||||||||||||||||
| Multipath QUIC Path Failover Mechanism | |||||||||||||||||
|
The proposed path failover mechanism provides a seamless way to recover from path failures in Multipath QUIC. It allows the protocol to take advantage of multiple paths while maintaining reliability and security. The implementation and deployment of this mechanism should be done with careful consideration of security and performance. | ||||||||||||||||
| draft-krose-multicast-security-04.txt | |||||||||||||||||
| Security and Privacy Considerations for Multicast Transports | |||||||||||||||||
|
Interdomain multicast has unique potential to solve delivery scalability for popular content, but it carries a set of security and privacy issues that differ from those in unicast delivery. This document analyzes the security threats unique to multicast-based delivery for Internet and Web traffic under the Internet and Web threat models. | ||||||||||||||||
| draft-kucherawy-bcp97bis-04.txt | |||||||||||||||||
| Procedures for Standards Track Documents to Refer Normatively to Documents at a Lower Level | |||||||||||||||||
|
IETF procedures generally require that a standards track RFC may not have a normative reference to another standards track document at a lower maturity level or to a non standards track specification (other than specifications from other standards bodies). For example, a standards track document may not have a normative reference to an informational RFC. Exceptions to this rule are sometimes needed as the IETF uses informational RFCs to describe non-IETF standards or IETF-specific modes of use of such standards. This document defines the procedure used in these circumstances. This document merges and updates, and thus obsoletes, RFC 3967, RFC 4897, and RFC 8067. | ||||||||||||||||
| draft-kucherawy-dkim-anti-replay-03.txt | |||||||||||||||||
| Replay-Resistant DomainKeys Identified Mail (DKIM) Signatures | |||||||||||||||||
|
DomainKeys Identified Mail (DKIM) provides a digital signature mechanism for Internet messages, allowing a domain name owner to affix its domain name in a way that can be cryptographically validated. DKIM signatures protect the integrity of the message header and body only. By design, it decoupled itself from the transport and storage mechanisms used to handle messages. This gives rise to a possible replay attack, which the original DKIM specification acknowledged but did not provide a mitigation strategy. This document presents an optional method for binding a signature to a specific recipient or set of recipients so that broader replay attacks can be mitigated. | ||||||||||||||||
| draft-kucherawy-full-docket-00.txt | |||||||||||||||||
| A Document Forcing A 400-page Docket | |||||||||||||||||
|
The sole purpose of this document is to push the length of the current IESG docket to an even 400 pages. | ||||||||||||||||
| draft-kuehlewind-rswg-updates-tag-00.txt | |||||||||||||||||
| Definition of new tags for relations between RFCs | |||||||||||||||||
|
An RFC can include a tag called "Updates" which can be used to link a new RFC to an existing RFC. On publication of such an RFC, the existing RFC will include an additional metadata tag called "Updated by" which provides a link to the new RFC. However, this tag pair is not well-defined and therefore it is currently used for multiple different purposes, which leads to confusion about the actual meaning of this tag and inconsistency in its use. This document recommends the discontinuation of the use of the updates/updated by tag pair, and instead proposes three new tag pairs that have well-defined meanings and use cases. | ||||||||||||||||
| draft-kuehlewind-system-ports-05.txt | |||||||||||||||||
| Reassignment of System Ports to the IESG | |||||||||||||||||
|
In the IANA Service Name and Transport Protocol Port Number Registry, a large number of System Ports are currently assigned to individuals or companies who have registered the port for the use with a certain protocol before RFC6335 was published. For some of these ports, RFCs exist that describe the respective protocol; for others, RFCs are under development that define, re-define, or assign the protocol used for the respective port, such as in case of so-far unused UDP ports that have been registered together with the respective TCP port. In these cases the IESG has the change control about the protocol used on the port (as described in the corresponding RFC) but change control for the port allocation iis designated to others. Under existing operational procedures, this means the original assignee needs to be involved in chnage to the port assignment. As it is not always possible to get in touch with the original assignee, particularly because of out-dated contact information, this current practice of handling historical allocation of System Ports does not scale well on a case-by-case basis. To address this, this document instructs IANA to perform actions with the goal to reassign System Ports to the IESG that were assigned to individuals prior to the publication of RFC6335, where appropriate. | ||||||||||||||||
| draft-kuhn-quic-bdpframe-extension-01.txt | |||||||||||||||||
| BDP Frame Extension | |||||||||||||||||
|
This document describes the BDP_FRAME extension for QUIC. The frame enables the exchange of CC parameters related to the path characteristics between the receiver and the sender during a connection. These CC parameters can be utilised by the Careful Resume method when a new connection is established or for application-limited traffic. The CC parameters allows a receiver to prepare to use the additional capacity that could be amde available when the method is used. This CC parameters can also be used by the receiver to request that previously computed CC parameters related to the path characteristics, are not used, when the receiver has additional information about the path or traffic to be sent. | ||||||||||||||||
| draft-kuhn-tsvwg-careful-resume-00.txt | |||||||||||||||||
| Careful convergence of congestion control from retained state with QUIC | |||||||||||||||||
|
This document discusses careful convergence of Congestion Control (CC) in QUIC, providing a cautious method that enables fast startup in a wide range of connections : reconnections using previous transport security credentials (0-RTT context), reconnections between 2 peers (prior knowledge of transport context), application-limited traffic. The method provides QUIC with transport services that resemble those currently available in TCP, such as TCP Control Block (TCB) [RFC9040] caching or updates to support application-limited traffic. The method reuses a set of computed CC parameters that are based on the previously observed path characteristics between the the same pair of transport endpoints, such as the bottleneck bandwidth, available capacity, or the RTT. These parameters are stored, allowing then to be later used to modify the CC behavior of a subsequent connection. The document also discusses assumptions and defines requirements around how a sender utilizes these parameters to provide opportunities for a new connection to more quickly get up to speed (i.e. utilize the available capacity). It discusses how these changes impact the capacity at a shared network bottleneck and the safe response that is needed after any indication that the new rate is inappropriate. | ||||||||||||||||
| draft-kumar-ippm-ifa-06.txt | |||||||||||||||||
| Inband Flow Analyzer | |||||||||||||||||
|
Inband Flow Analyzer (IFA) records flow specific information from an end station and/or switches across a network. This document discusses the method to collect data on a per hop basis across a network and perform localized or end to end analytics operations on the data. This document also describes a transport-agnostic header definition that may be used for tunneled and non-tunneled flows alike. | ||||||||||||||||
| draft-kunze-ark-36.txt | |||||||||||||||||
| The ARK Identifier Scheme | |||||||||||||||||
|
The ARK (Archival Resource Key) naming scheme is designed to facilitate the high-quality and persistent identification of information objects. The label "ark:" marks the start of a core ARK identifier that can be made actionable by prepending the beginning of a URL. Meant to be usable after today's networking technologies become obsolete, that core should be recognizable in the future as a globally unique ARK independent of the URL hostname, HTTP, etc. A founding principle of ARKs is that persistence is purely a matter of service and neither inherent in an object nor conferred on it by a particular naming syntax. The best any identifier can do is lead users to services that support robust reference. A full-functioning ARK leads the user to the identified object and, with the "?info" inflection appended, returns a metadata record and a commitment statement that is both human- and machine-readable. Tools exist for minting, binding, and resolving ARKs. Responsibility for this Document The ARK Alliance Technical Working Group [ARKAtech] is responsible for the content of this Internet Draft. The group homepage lists monthly meeting notes and agendas starting from March 2019. Revisions of the spec are maintained on github at [ARKdrafts]. | ||||||||||||||||
| draft-kwon-yoon-kim-ipake-01.txt | |||||||||||||||||
| I-PAKE: Identity-Based Password Authenticated Key Exchange | |||||||||||||||||
|
Although password authentication is the most widespread user authentication method today, cryptographic protocols for mutual authentication and key agreement, i.e., password authenticated key exchange (PAKE), in particular authenticated key exchange (AKE) based on a password only, are not actively used in the real world. This document introduces a quite novel form of PAKE protocols that employ a particular concept of ID-based encryption (IBE). The resulting cryptographic protocol is the ID-based password authenticated key exchange (I-PAKE) protocol which is a secure and efficient PAKE protocol in both soft- and hard-augmented models. I-PAKE achieves the security goals of AKE, PAKE, and hard-augmented PAKE. I-PAKE also achieves the great efficiency by allowing the whole pre-computation of the ephemeral Diffie-Hellman public keys by both server and client. | ||||||||||||||||
| draft-laari-asdf-relations-01.txt | |||||||||||||||||
| Extended relation information for Semantic Definition Format (SDF) | |||||||||||||||||
|
The Semantic Definition Format (SDF) base specification defines set of basic information elements that can be used for describing a large share of the existing data models from different ecosystems. While these data models are typically very simple, such as basic sensors definitions, more complex models, and in particular bigger systems, benefit from ability to describe additional information on how different definitions relate to each other. This document specifies an extension to SDF for describing complex relationships and additional information about them. | ||||||||||||||||
| draft-lai-bmwg-istn-methodology-02.txt | |||||||||||||||||
| Problems and Requirements of Evaluation Methodology for Integrated Space and Terrestrial Networks | |||||||||||||||||
|
With the rapid evolution of the aerospace industry, many "NewSpace" upstarts are actively deploying their mega-constellations in low earth orbits (LEO) and building integrated space and terrestrial networks (ISTN), promising to provide pervasive, low-latency, and high-throughput Internet service globally. Due to the high manufacturing, launching, and updating cost of LEO mega- constellations, it is expected that ISTNs can be well designed and evaluated before the launch of satellites. However, the progress of designing, assessing, and understanding new network functionalities and protocols for futuristic ISTNs faces a substantial obstacle: lack of standardized evaluation methodology with acceptable realism (e.g. can involve the unique dynamic behaviors of ISTNs), flexibility, and cost. This memo first reviews the unique characteristics of LEO mega-constellations. Further, it analyzes the limitation of existing evaluation and analysis methodologies under ISTN environments. Finally, it outlines the key requirements of future evaluation methodology tailored for ISTNs. | ||||||||||||||||
| draft-lai-bmwg-sic-benchmarking-00.txt | |||||||||||||||||
| Considerations for Benchmarking Network Performance in Satellite Internet Constellations | |||||||||||||||||
|
Entering the "NewSpace" era, satellite Internet constellations (SIC) are scaling up at a fast pace. Emerging satellite networks constructed upon SICs enable great opportunities for ubiquitous and low-latency Internet services globally. It should be useful for satellite service providers to run various laboratory experiments to comprehensively and systematically benchmark the network performance of their new network techniques before launching them to the outer space. However, existing benchmarking methodologies for terrestrial networks either achieve fidelity but lack flexibility or achieve flexibility but lack fidelity. This draft describes our basic considerations as specifications to guide the network performance benchmark for SICs. A satellite network constructed upon emerging SICs in low earth orbit has many unique characteristics as compared to existing terrestrial networks. Specifically, our considerations include multiple networking models of emerging SICs, a data-driven benchmarking approach which may enable testers to build a laboratory benchmark environment with acceptable flexibility and fidelity to support various experiments, critical configuration parameters that might affect the SIC network performance, and several suggested test cases for network performance benchmarking. | ||||||||||||||||
| draft-lamparter-bier-manet-multicast-links-00.txt | |||||||||||||||||
| Use,problems and gap analysis for BIER link-layer multicast | |||||||||||||||||
|
Mesh networks present a particularly difficult base to provide a multicast service on top of. Not only do normal assumptions of transitive and reflexive connectivity not hold, but proper use of multicast capabilities on lower radio layers can be imperative. This document provides use case, problem statement and gap analysis for utilizing link-layer multicast features in a BIER domain. | ||||||||||||||||
| draft-lampin-lpwan-schc-considerations-00.txt | |||||||||||||||||
| SCHC design and implementation considerations | |||||||||||||||||
|
Taking the opportunity of a fresh implementation of SCHC by a newcomer to SCHC to reflect on the design principles and the implications on the implication of SCHC. Topics addressed: * The parser, as described in SCHC specification. * A discussion on parsing and interpretation. * Practical implications of the specification of the parser of SCHC. * the challenge and opportunity of a generic parser implementation able to handle any protocol stack and rules design to enable it. | ||||||||||||||||
| draft-lan-nvo3-qtp-17.txt | |||||||||||||||||
| QoS-level aware Transmission Protocol (QTP) for virtual networks | |||||||||||||||||
|
This document provides a QoS-level aware Transmission Protocol (QTP) for virtual networks. | ||||||||||||||||
| draft-lan-sfp-establishment-15.txt | |||||||||||||||||
| Service Function Path Establishment | |||||||||||||||||
|
Service Function Chain architecture leads to more adaptive network nodes. It allows splitting the network function into fine-grained build blocks --- service function, and combining the network functions into service function chain to formulate complicated services. Further, the service function chain should be instantiated by selecting the optimal instance from the candidates for each service function in it. This document discusses the required components during the instantiation of service function chain in the network. | ||||||||||||||||
| draft-langer-ntp-nts-for-ptp-05.txt | |||||||||||||||||
| NTS4PTP - Key Management System for the Precision Time Protocol Based on the Network Time Security Protocol | |||||||||||||||||
|
This document defines a key management service for automatic key management for the integrated security mechanism (prong A) of IEEE Std 1588™-2019 (PTPv2.1) described there in Annex P. It implements a key management for the immediate security processing approach and offers a security solution for all relevant PTP modes. The key management service for PTP is based on and extends the NTS Key Establishment protocol defined in IETF RFC 8915 for securing NTP, but works completely independent from NTP. | ||||||||||||||||
| draft-lanzhangwang-rtgwg-npmnrp-15.txt | |||||||||||||||||
| Node Potential Oriented Multi-NextHop Routing Protocol | |||||||||||||||||
|
The Node Potential Oriented Multi-Nexthop Routing Protocol (NP-MNRP) bases on the idea of "hop-by-hop routing forwarding, multi-backup next hop" and combines with the phenomena that water flows from higher place to lower. NP-MNRP defines a metric named as node potential, which is based on hop count and the actual link bandwidth, and calculates multiple next-hops through the potential difference between the nodes. | ||||||||||||||||
| draft-lapukhov-bgp-ecmp-considerations-10.txt | |||||||||||||||||
| Equal-Cost Multipath Considerations for BGP | |||||||||||||||||
|
BGP (Border Gateway Protocol) [RFC4271] employs tie-breaking logic to select a single best path among multiple paths available, known as BGP best path selection. At the same time, it has become a common practice to allow for "equal-cost multipath" (ECMP) selection and programming of multiple next-hops in routing tables. This document summarizes some common considerations for the ECMP logic when BGP is used as the routing protocol, with the intent of providing common reference for otherwise unstandardized set of features. | ||||||||||||||||
| draft-lassey-tigress-threat-model-00.txt | |||||||||||||||||
| TIGRESS Threat Model | |||||||||||||||||
|
TODO Abstract | ||||||||||||||||
| draft-latour-dns-and-digital-trust-00.txt | |||||||||||||||||
| Leveraging DNS in Digital Trust: Credential Exchanges and Trust Registries | |||||||||||||||||
|
This memo describes an architecture for digital credential verification and validation using Decentralized Identifiers (DIDs), distributed ledgers, trust registries, and the DNS. This architecture provides a verifier with a simple process by which to cryptographically verify the credential they are being presented with, verify and resolve the issuer of that credential to a domain, and verify that issuer's membership in a trust registry. | ||||||||||||||||
| draft-law-moq-catalog-00.txt | |||||||||||||||||
| Catalog Specification for MoQ compliant streaming formats | |||||||||||||||||
|
This document defines an interoperable Catalog specification for streaming formats implementing the MoQ Base Protocol. | ||||||||||||||||
| draft-lazanski-consolidation-05.txt | |||||||||||||||||
| Protocol and Engineering Effects of Consolidation | |||||||||||||||||
|
This document contributes to the continuing discussion on Internet consolidation. Over the last several years there have been many types of discussions around consolidation at a technical level, a economic or market level and also at an engineering level. This document aims to discuss recent areas of Internet consolidation and provide some suggestions for advancing the discussion. | ||||||||||||||||
| draft-lazanski-protocol-sec-design-model-t-06.txt | |||||||||||||||||
| Security Considerations for Protocol Designers | |||||||||||||||||
|
This document is a non-exhaustive set of considerations for protocol designers and implementers with regards to attack defence. This document follows on from the way forward outlined in draft-lazanski- users-threat-model-t-04. These considerations both supplement and support the work on threat models. They can be used as an aid to analyse protocol design choice and in turn to help combat threats and defend users of these protocols and systems against malicious attacks. First, we list well-known classes of attacks that pose threats, with relevant case studies and descriptions. Next, we give a list of defence measures against these attacks to be considered when designing and deploying protocols. Naturally, deployments of protocols vary greatly between use cases; therefore, some attacks and defensive measures outlined may require more consideration than others, dependent on use case. This RFC can be used by protocol designers to write the Security Considerations section in an RFC. The impact on attack defence of a protocol should be considered in multiple use cases across the multiple layers of the internet. Defence against malicious attacks can be improved and it can be weakened by design features of protocols. Designers should acknowledge the role of protocols in attack prevention, detection and mitigation; this document aims to be a useful guide in doing so. | ||||||||||||||||
| draft-lazanski-users-threat-model-t-06.txt | |||||||||||||||||
| A User-Focused Internet Threat Model | |||||||||||||||||
|
RFC 3552 introduces a threat model that does not include endpoint security. Yet increasingly protocol development is making assumptions about endpoint security capabilities which have not been defined. RFC 3552 is 17 years old and threat landscape has changed. Security issues and cyber attacks have increased and there are more devices, users, and applications on the endpoint than ever. This draft proposes a new approach to the Internet threat model which will include endpoint security, focus on users and provide an update to the threat model in RFC 3552. It brings together Security Considerations for Protocol Designers draft-lazanski-protocol-sec-design-model-t-05 which is a comprehensive document that lists threats, attack vectors, examples and considerations for designing protocols, as well as draft-taddei-smart- cless-introduction-03 which lays out security concerns, capabilities and limitations for endpoints in general and draft-mcfadden-smart- endpoint-taxonomy-for-cless-02 which outlines a clear taxonomy for endpoint security and identifies changes in technology, economic and protocol development that has impacted and changed endpoint security. Taken together these drafts reflect a comprehensive and clear set of security threats and design considerations for the Internet. | ||||||||||||||||
| draft-lcsr-alto-service-functions-02.txt | |||||||||||||||||
| ALTO extensions for handling Service Functions | |||||||||||||||||
|
This document proposes the usage of ALTO (and its extensions) to provide information about service functions to clients (e.g., external systems) that could consume such information for decisions requiring network information (service composition, traffic steering to service chains, etc). | ||||||||||||||||
| draft-lcurley-warp-04.txt | |||||||||||||||||
| Warp - Live Media Transport over QUIC | |||||||||||||||||
|
This document defines the core behavior for Warp, a live media transport protocol over QUIC. Media is split into objects based on the underlying media encoding and transmitted independently over QUIC streams. QUIC streams are prioritized based on the delivery order, allowing less important objects to be starved or dropped during congestion. | ||||||||||||||||
| draft-ldbc-cats-framework-01.txt | |||||||||||||||||
| A Framework for Computing-Aware Traffic Steering (CATS) | |||||||||||||||||
|
This document describes a framework for Computing-Aware Traffic Steering (CATS). Particularly, the document identifies a set of CATS components, describes their interactions, and exemplifies the workflow of the control and data planes. | ||||||||||||||||
| draft-lee-pce-pcep-ls-optical-13.txt | |||||||||||||||||
| PCEP Extension for Distribution of Link-State and TE Information for Optical Networks | |||||||||||||||||
|
In order to compute and provide optimal paths, Path Computation Elements (PCEs) require an accurate and timely Traffic Engineering Database (TED). Traditionally this Link State and TE information has been obtained from a link state routing protocol (supporting traffic engineering extensions). An existing experimental document extends the Path Computation Element Communication Protocol (PCEP) with Link-State and Traffic Engineering (TE) Information. This document provides further experimental extensions to collect Link-State and TE information for optical networks. | ||||||||||||||||
| draft-leggett-spkac-01.txt | |||||||||||||||||
| Signed Public Key and Challenge | |||||||||||||||||
|
This memo describes the Signed Public Key and Challenge (SPKAC), a syntax to provide Proof-of-Possession of a Private Key to support federated (client) certificate enrolment. | ||||||||||||||||
| draft-lehmann-idmefv2-01.txt | |||||||||||||||||
| The Incident Detection Message Exchange Format version 2 (IDMEFv2) | |||||||||||||||||
|
The Incident Detection Message Exchange Format version 2 (IDMEFv2) defines a date representation for security incidents detected on cyber and/or physical infrastructures. The format is agnostic so it can be used in standalone or combined cyber (SIEM), physical (PSIM) and availability (NMS) monitoring systems. IDMEFv2 can also be used to represent man made or natural hazards threats. IDMEFv2 improves situational awareness by facilitating correlation of multiple types of events using the same base format thus enabling efficient detection of complex and combined cyber and physical attacks and incidents. If approved this draft will obsolete RFC4765. | ||||||||||||||||
| draft-lehmann-idmefv2-https-transport-00.txt | |||||||||||||||||
| Transport of Incident Detection Message Exchange Format version 2 (IDMEFv2) Messages over HTTPS | |||||||||||||||||
|
The Incident Detection Message Exchange Format version 2 (IDMEFv2) defines a date representation for security incidents detected on cyber and/or physical infrastructures. The format is agnostic so it can be used in standalone or combined cyber (SIEM), physical (PSIM) and availability (NMS) monitoring systems. IDMEFv2 can also be used to represent man made or natural hazards threats. IDMEFv2 improves situational awareness by facilitating correlation of multiple types of events using the same base format thus enabling efficient detection of complex and combined cyber and physical attacks and incidents. This document defines a way to transport IDMEFv2 Alerts over HTTPs. If approved this document would obsolete RFC4767. | ||||||||||||||||
| draft-lemmons-composite-claims-00.txt | |||||||||||||||||
| Composite Token Claims | |||||||||||||||||
|
Composition claims are CBOR Web Token claims that define logical relationships between sets of claims and provide for private claim values via encryption. | ||||||||||||||||
| draft-lencse-v6ops-transition-scalability-04.txt | |||||||||||||||||
| Scalability of IPv6 Transition Technologies for IPv4aaS | |||||||||||||||||
|
Several IPv6 transition technologies have been developed to provide customers with IPv4-as-a-Service (IPv4aaS) for ISPs with an IPv6-only access and/or core network. All these technologies have their advantages and disadvantages, and depending on existing topology, skills, strategy and other preferences, one of these technologies may be the most appropriate solution for a network operator. This document examines the scalability of the five most prominent IPv4aaS technologies (464XLAT, Dual Stack Lite, Lightweight 4over6, MAP-E, MAP-T) considering two aspects: (1) how their performance scales up with the number of CPU cores, (2) how their performance degrades, when the number of concurrent sessions is increased until hardware limit is reached. | ||||||||||||||||
| draft-lenders-dns-cbor-02.txt | |||||||||||||||||
| A Concise Binary Object Representation (CBOR) of DNS Messages | |||||||||||||||||
|
This document specifies a compressed data format of DNS messages using the Concise Binary Object Representation [RFC8949]. The primary purpose is to keep DNS messages small in constrained networks. | ||||||||||||||||
| draft-lenders-dns-cns-00.txt | |||||||||||||||||
| Guidance on DNS Message Composition in Constrained Networks | |||||||||||||||||
|
This document provides guidance on the composition of DNS messages in constrained networks, where the link layer may restrict payload sizes significantly and batteries challenge power consumption. | ||||||||||||||||
| draft-lh-spring-srv6-sfc-csid-00.txt | |||||||||||||||||
| Compressed SID (C-SID) for SRv6 SFC | |||||||||||||||||
|
In SRv6, an SRv6 SID is a 128-bit value. When too many 128-bit SRv6 SIDs are included in an SRH, the introduced overhead will affect the transmission efficiency of payload. In order to address this problem, Compressed SID(C-SID) is proposed. This document defines new behaviors for service segments with REPLACE-C-SID and NEXT-C-SID flavors to enable compressed SRv6 service programming. | ||||||||||||||||
| draft-lhan-problems-requirements-satellite-net-04.txt | |||||||||||||||||
| Problems and Requirements of Satellite Constellation for Internet | |||||||||||||||||
|
This document presents the detailed analysis about the problems and requirements of satellite constellation used for Internet. It starts from the satellite orbit basics, coverage calculation, then it estimates the time constraints for the communications between satellite and ground-station, also between satellites. How to use satellite constellation for Internet is discussed in detail including the satellite relay and satellite networking. The problems and requirements of using traditional network technology for satellite network integrating with Internet are finally outlined. | ||||||||||||||||
| draft-lhan-satellite-instructive-routing-02.txt | |||||||||||||||||
| Semantic Address Based Instructive Routing for Satellite Network | |||||||||||||||||
|
This document presents a method to do IP routing over satellite network that consists of LEO (Low Earth Orbit) satellites and ground- stations. The method uses the source routing mechanism. The whole routing info is obtained by path calculation. The routing path information is converted to be a list of instructions and embedded into user packet's IPv6 extension header. At each hop or each satellite, the routing process engine will forward the packet based on the specified instruction for the satellite. Until the packet reaches the edge of satellite network, or the last satellite, the packet will be sent to a ground station. | ||||||||||||||||
| draft-lhan-satellite-semantic-addressing-03.txt | |||||||||||||||||
| Satellite Semantic Addressing for Satellite Constellation | |||||||||||||||||
|
This document presents a semantic addressing method for satellites in satellite constellation connecting with Internet. The satellite semantic address can indicate the relative position of satellites in a constellation. The address can be used with traditional IP address or MAC address or used independently for IP routing and switching. | ||||||||||||||||
| draft-li-6lo-pasa-reliability-01.txt | |||||||||||||||||
| Reliability Considerations of Path-Aware Semantic Addressing | |||||||||||||||||
|
Path-Aware Semantic Address (PASA) [I-D.li-6lo-path-aware-semantic-addressing]), proposes to algorithmically assign addresses to nodes in a 6lo environment so to achieve stateless forwarding, hence, allowing to avoid using a routing protocol. PASA is more suitable for stable and static wireline connectivity, in order to avoid renumbering due to topology changes. Even in such kind of scenarios, reliability remains a concern. This memo tackles specifically reliability in PASA deployments, analyzing possible broad solution categories to solve the issue. | ||||||||||||||||
| draft-li-apn-framework-07.txt | |||||||||||||||||
| Application-aware Networking (APN) Framework | |||||||||||||||||
|
A multitude of applications are carried over the network, which have varying needs for network bandwidth, latency, jitter, and packet loss, etc. Some new emerging applications have very demanding performance requirements. However, in current networks, the network and applications are decoupled, that is, the network is not aware of the applications' requirements in a fine granularity. Therefore, it is difficult to provide truly fine-granularity traffic operations for the applications and guarantee their SLA requirements. This document proposes a new framework, named Application-aware Networking (APN), where application-aware information (i.e. APN attribute) including APN identification (ID) and/or APN parameters (e.g. network performance requirements) is encapsulated at network edge devices and carried in packets traversing an APN domain in order to facilitate service provisioning, perform fine-granularity traffic steering and network resource adjustment. | ||||||||||||||||
| draft-li-apn-header-04.txt | |||||||||||||||||
| Application-aware Networking (APN) Header | |||||||||||||||||
|
This document defines the application-aware networking (APN) header which can be used in a variety of data planes. | ||||||||||||||||
| draft-li-apn-ipv6-encap-06.txt | |||||||||||||||||
| Application-aware IPv6 Networking (APN6) Encapsulation | |||||||||||||||||
|
Application-aware IPv6 Networking (APN6) makes use of IPv6 encapsulation to convey the APN Attribute along with data packets and make the network aware of data flow requirements at different granularity levels. The APN attribute can be encapsulated in the APN header. This document defines the encapsulation of the APN header in the IPv6 data plane. | ||||||||||||||||
| draft-li-apn-problem-statement-usecases-08.txt | |||||||||||||||||
| Problem Statement and Use Cases of Application-aware Networking (APN) | |||||||||||||||||
|
Network operators are facing the challenge of providing better network services for users. As the ever-developing 5G and industrial verticals evolve, more and more services that have diverse network requirements such as ultra-low latency and high reliability are emerging, and therefore differentiated service treatment is desired by users. On the other hand, as network technologies such as Hierarchical QoS (H-QoS), SR Policy, and Network Slicing keep evolving, the network has the capability to provide more fine- granularity differentiated services. However, network operators are typically unaware of the applications that are traversing their network infrastructure, which means that not very effective differentiated service treatment can be provided to the traffic flows. As network technologies evolve including deployments of IPv6, SRv6, Segment Routing over MPLS dataplane, the programmability provided by IPv6 and Segment Routing can be augmented by conveying application related information into the network satisfying the fine- granularity requirements. This document analyzes the existing problems caused by lack of service awareness, and outlines various use cases that could benefit from an Application-aware Networking (APN) framework. | ||||||||||||||||
| draft-li-coinrg-distributed-learning-architecture-01.txt | |||||||||||||||||
| Distributed Learning Architecture based on Edge-cloud Collaboration | |||||||||||||||||
|
This document describes the distributed learning architecture based on edge-cloud collaboration. | ||||||||||||||||
| draft-li-dots-knowledge-trans-04.txt | |||||||||||||||||
| Knowledge Transmission Using Distributed Denial-of-Service Open Threat Signaling (DOTS) Data Channel | |||||||||||||||||
|
The document specifies new DOTS data channel configuration parameters that customize the DDoS knowledge transmission configuration between distributed knowledge bases. These options enable assist the distributed knowledge base to share attack knowledge in different fields and actively adapt to dynamically changing DDoS attacks. | ||||||||||||||||
| draft-li-dyncast-architecture-08.txt | |||||||||||||||||
| Dynamic-Anycast Architecture | |||||||||||||||||
|
This document describes an architecture for the Dynamic-Anycast (Dyncast). It includes an architecture overview, main components, and the workflow of control plane and dataplane. | ||||||||||||||||
| draft-li-idr-bgpls-sr-policy-composite-path-04.txt | |||||||||||||||||
| Signaling Composite Candidate Path of SR Policy using BGP-LS | |||||||||||||||||
|
Segment Routing is a source routing paradigm that explicitly indicates the forwarding path for packets at the ingress node. An SR Policy is associated with one or more candidate paths, and each candidate path is either dynamic, explicit or composite. This document specifies the extensions to BGP Link State (BGP-LS) to carry composite candidate path information in the advertisement of an SR policy. | ||||||||||||||||
| draft-li-idr-inter-protocol-anti-loop-00.txt | |||||||||||||||||
| Loop prevention for route import between protocols | |||||||||||||||||
|
BGP and IGP are commonly used network protocols during network construction. At the beginning of BGP protocol design, EBGP and IBGP loop prevention are considered. Similarly, the IGP protocol has a loop prevention mechanism. In actual deployment, some or even all routes of the two protocols are imported to each other. Route import causes the loss of the anti-loop attribute of the protocol. As a result, the anti-loop fails. This document provides a feasible solution to the above problems. Attribute information is added when routes are imported between protocols. The added attribute information can be advertised to neighboring neighbors through BGP peers or IGP peers. How the new attributes are advertised using IGP peers is beyond the scope of this article. | ||||||||||||||||
| draft-li-idr-sr-policy-composite-path-04.txt | |||||||||||||||||
| BGP Extensions of SR Policy for Composite Candidate Path | |||||||||||||||||
|
Segment Routing is a source routing paradigm that explicitly indicates the forwarding path for packets at the ingress node. An SR Policy is associated with one or more candidate paths. A candidate path is either dynamic, explicit or composite. This document defines extensions to BGP to distribute SR policies carrying composite candidate path information. So that composite candidate paths can be installed when the SR policy is applied. | ||||||||||||||||
| draft-li-ippm-ioam-path-protection-02.txt | |||||||||||||||||
| IOAM Linkage Solution for the Protection Cases of 5G Bearer Network | |||||||||||||||||
|
In-band operation and maintenance management (IOAM, In-band OAM), as a network performance monitoring technology, is based on the principle of path-associated detection to perform specific field marking/coloring and identification on actual service flows, and perform packet loss and delay measurement. It can quickly perceive network performance-related faults, and accurately delimit boundaries and do troubleshooting. However, the current IOAM solution has shortcomings too. For example, after the service traffic path switching, the IOAM cannot continue working. This paper proposes a scheme to achieve automatic performance monitoring through service path switching and linkage with IOAM, which enhances the feasibility of the IOAM scheme in large-scale deployment and the completeness of IOAM technology. | ||||||||||||||||
| draft-li-istn-addressing-requirement-02.txt | |||||||||||||||||
| Problems and Requirements of Addressing in Integrated Space-Terrestrial Network | |||||||||||||||||
|
This document presents a detailed analysis of the problems and requirements of network addressing in "Internet in space" for terrestrial users. It introduces the basics of satellite mega- constellations, terrestrial terminals/ground stations, and their inter-networking. Then it explicitly analyzes how space-terrestrial mobility yeilds challenges for the logical topology, addressing, and their impact on routing. The requirements of addressing in the space-terrestrial network are discussed in detail, including uniqueness, stability, locality, scalability, efficiency and backward compatibility with terrestrial Internet. The problems and requirements of network addressing in space-terrestrial networks are finally outlined. | ||||||||||||||||
| draft-li-lsr-isis-te-metric-lan-extensions-01.txt | |||||||||||||||||
| IS-IS Traffic Engineering (TE) Metric LAN Extensions | |||||||||||||||||
|
In certain networks, network-performance criteria (e.g., latency) are becoming as critical to data-path selection as other metrics. This document describes extensions to IS-IS Traffic Engineering (TE) Metric Extensions (RFC 8570) for LAN subnetworks. These extensions provide a way to distribute and collect network-performance information in LAN subnetworks. | ||||||||||||||||
| draft-li-mpls-mna-entropy-00.txt | |||||||||||||||||
| MPLS Network Action for Entropy | |||||||||||||||||
|
Load balancing is a powerful tool for engineering traffic across a network and has been successfully used in MPLS as described in "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 [I-D.jags-mpls-mna-hdr]. | ||||||||||||||||
| draft-li-mpls-mna-fas-00.txt | |||||||||||||||||
| MPLS Network Actions for Flow-Aggregate Selector | |||||||||||||||||
|
An IETF Network Slice service provides connectivity coupled with a set of network resource commitments and is expressed in terms of one or more connectivity constructs. A Slice-Flow Aggregate refers to the set of traffic streams from one or more connectivity constructs belonging to one or more IETF Network Slices that are mapped to a set of network resources and provided the same forwarding treatment. The packets associated with a Slice-Flow Aggregate may carry a marking in the packet's network layer header to identify this association and this marking is referred to as Flow-Aggregate Selector (FAS). The FAS is used to map the packet to the associated set of network resources and provide the corresponding forwarding treatment to the packet. MPLS Network Actions (MNA) technologies are used to indicate actions for Label Switched Paths (LSPs) and/or MPLS packets and to transfer data needed for these actions. This document discusses options for using MPLS Network Actions (MNAs) to carry the FAS in MPLS packets. | ||||||||||||||||
| draft-li-mpls-mna-nffrr-01.txt | |||||||||||||||||
| MPLS Network Actions for No Further Fast Reroute | |||||||||||||||||
|
Protection switching for MPLS traffic was first introduced in "Fast Reroute Extensions to RSVP-TE for LSP Tunnels". Since then, Fast Reroute (FRR) has been successfully used in many MPLS networks to help ensure high availability in the face of failures. If there are multiple failures in a network, there are circumstances where FRR, if applied multiple times, can result in sub-optimal behavior, such as forwarding loops. Thus, it is useful to indicate in the forwarding plane that the attached traffic should not be subjected to further FRR redirection. This document describes a network action for identifying such traffic to be used in conjunction with "MPLS Network Action (MNA) Header Encodings". | ||||||||||||||||
| draft-li-pce-controlled-id-space-14.txt | |||||||||||||||||
| Path Computation Element Communication Protocol (PCEP) extension to advertise the PCE Controlled Identifier Space | |||||||||||||||||
|
The Path Computation Element Communication Protocol (PCEP) provides a mechanisms for the Path Computation Elements (PCEs) to perform path computations in response to Path Computation Clients (PCCs) requests. The Stateful PCE extensions allow stateful control of Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Label Switched Paths (LSPs) using PCEP. Furthermore, PCE can be used for computing paths in the SR networks. Stateful PCE provide active control of MPLS-TE LSPs via PCEP, for a model where the PCC delegates control over one or more locally configured LSPs to the PCE. Further, stateful PCE could also create and remove PCE-initiated LSPs by itself. A PCE-based Central Controller (PCECC) simplify the processing of a distributed control plane by integrating with elements of Software-Defined Networking (SDN). In some use cases, such as PCECC or Binding Segment Identifier (SID) for Segment Routing (SR), there are requirements for a stateful PCE to make allocation of labels, SIDs, etc. These use cases require PCE aware of various identifier spaces from where to make allocations on behalf of a PCC. This document describes a generic mechanism for a PCC to inform the PCE of the an identifier space set aside for the PCE control via PCEP. The identifier could be an MPLS label, a SID or any other to-be-defined identifier that can be allocated and managed by the PCE. | ||||||||||||||||
| draft-li-quic-optimizing-ack-in-wlan-05.txt | |||||||||||||||||
| Optimizing ACK mechanism for QUIC | |||||||||||||||||
|
The dependence on frequent acknowledgments (ACKs) is an artifact of current transport protocol designs rather than a fundamental requirement. This document analyzes the problems caused by contentions and collisions on wireless medium between data packets and ACKs in WLAN and it proposes an ACK mechanism that minimizes the intensity of ACK Frame in QUIC, improving the performance of transport layer connection. | ||||||||||||||||
| draft-li-rtgwg-enhanced-ti-lfa-07.txt | |||||||||||||||||
| Enhanced Topology Independent Loop-free Alternate Fast Re-route | |||||||||||||||||
|
Topology Independent Loop-free Alternate Fast Re-route (TI-LFA) aims at providing protection of node and adjacency segments within the Segment Routing (SR) framework. A key aspect of TI-LFA is the FRR path selection approach establishing protection over the expected post-convergence paths from the point of local repair. However, the TI-LFA FRR path may skip the node even if it is specified in the SID list to be traveled. This document defines Enhanced TI-LFA(TI-LFA+) by adding a No-bypass indicator for segments to ensure that the FRR route will not bypass the specific node, such as firewall. Also, this document defines No- bypass flag and No-FRR flag in SRH to indicate not to bypass nodes and not to perform FRR on all the nodes along the SRv6 path, respectively. | ||||||||||||||||
| draft-li-rtgwg-generalized-ipv6-tunnel-03.txt | |||||||||||||||||
| Generalized IPv6 Tunnel (GIP6) | |||||||||||||||||
|
This document defines the generalized IPv6 tunnel based on the analysis of challenges of the existing problems of IP tunnels. | ||||||||||||||||
| draft-li-rtgwg-gip6-for-mpls-00.txt | |||||||||||||||||
| Genralized IPv6 Tunnel for MPLS | |||||||||||||||||
|
With the development of new services, MPLS faces many problems and technical challenges. This document defines the method to implement MPLS through the GIP6 tunnel. | ||||||||||||||||
| draft-li-rtgwg-gip6-for-quic-00.txt | |||||||||||||||||
| Generalized IPv6 Tunnel (GIP6) for QUIC | |||||||||||||||||
|
This document defines a new encapsulation method for QUIC packet transmission based on IPv6 extension headers. This method enables QUIC packet transmission to easily inherit the extended functions of IPv6. | ||||||||||||||||
| draft-li-rtgwg-gip6-protocol-ext-requirements-01.txt | |||||||||||||||||
| Protocol Extension Requirements of Generalized IPv6 Tunnel | |||||||||||||||||
|
IPv6 provides extension header mechanism for additional functions. There are emerging features based on the extension headers, such as SRv6, Slicing, Alternate Marking, IOAM, DetNet, APN. However network devices have different capabilities of IPv6 extension header processing which has much effect on the deployment of these features. This document analyses the issues found during the deployment of the above new features using IPv6 extension headers and the protocol extension requirements for IPv6 capability advertisement are defined. | ||||||||||||||||
| draft-li-rtgwg-protocol-assisted-protocol-05.txt | |||||||||||||||||
| Protocol Assisted Protocol (PASP) | |||||||||||||||||
|
For routing protocol troubleshooting, different approaches exibit merits w.r.t. different situations. They can be generally divided into two categories, the distributive way and the centralized way. A very commonly used distributive approach is to log in possiblly all related devices one by one to check massive data via CLI. Such approach provides very detailed device information, however it requires operators with high NOC (Network Operation Center) experience and suffers from low troubleshooting efficiency and high cost. The centralized approach is realized by collecting data from devices via approaches, like the streaming Telemetry or BMP( BGP Monitoring Protocol), for the centralized server to analyze all gathered data. Such approach allows a comprehensive view fo the whole network and facilitates automated troubleshooting, but is limited by the data collection boundary set by different management domains, as well as high network bandwidth and CPU computation costs. This document proposes a semi-distributive and semi-centralized approach for fast routing protocol troubleshooting, localizing the target device and possibly the root cause, more precisely. It defines a new protocol, called the PASP (Protocol assisted Protocol), for devices to exchange protocol related information between each other in both active and on-demand manners. It allow devices to request specific information from other devices and receive replies to the requested data. It also allows actively transmission of information without request to inform other devices to better react w.r.t. network issues. | ||||||||||||||||
| draft-li-rtgwg-tte-00.txt | |||||||||||||||||
| Tactical Traffic Engineering (TTE) | |||||||||||||||||
|
Conventional traffic engineering approaches for resource management used by RSVP-TE and SR-TE often leverage estimates of the ingress traffic demands, during path placement. Unforeseen and/or dynamic events, can skew these estimates by significant enough margins to result in unexpected network congestion. Recomputed paths that address the new demands may take a considerable amount of time, leaving the network in a sub-optimal state for far too long. This document proposes one mechanism that can avert congestion on a real-time basis. | ||||||||||||||||
| draft-li-savnet-dataplane-performance-00.txt | |||||||||||||||||
| Analysis of Source Address Validation Data Plane Performance | |||||||||||||||||
|
Source address validation (SAV) is one important way to mitigate source address spoofing attacks. However, there may be concern about whether the source address check action of the data plane would cause a great performance loss and even affect SAV deployment. This document provides an analysis of data plane implementation of SAV mechanisms, including the existing mechanisms and a new mechanism using independent SAV table. The data plane performances of different mechanisms are tested respectively. | ||||||||||||||||
| draft-li-savnet-intra-domain-architecture-01.txt | |||||||||||||||||
| Intra-domain Source Address Validation (SAVNET) Architecture | |||||||||||||||||
|
Intra-domain source address validation (SAV) plays an important role in defending against source address spoofing attacks in intra-domain networks. This document proposes an intra-domain source address validation (intra-domain SAVNET) architecture. Under the architecture, a router can automatically generate accurate SAV rules based on the SAV-related information from multiple information sources. This document does not specify protocols or protocol extensions, instead focusing on architectural components and their functionalities in an intra-domain SAVNET deployment. | ||||||||||||||||
| draft-li-savnet-intra-domain-problem-statement-07.txt | |||||||||||||||||
| Source Address Validation in Intra-domain Networks Gap Analysis,Problem Statement,and Requirements | |||||||||||||||||
|
This document provides the gap analysis of existing intra-domain source address validation mechanisms, describes the fundamental problems, and defines the requirements for technical improvements. | ||||||||||||||||
| draft-li-spring-sr-e2e-ietf-network-slicing-06.txt | |||||||||||||||||
| Segment Routing for End-to-End IETF Network Slicing | |||||||||||||||||
|
IETF network slices can be used to meet the connectivity and performance requirements of different services or customers in a shared network. An IETF network slice can be realized by mapping a set of connectivity constructs to a network resource partition (NRP). In some network scenarios, an end-to-end IETF network slice may span multiple network domains. Within each domain, traffic of the end-to- end network slice service is mapped to an intra-domain NRP. When segment routing (SR) is used to provide multi-domain IETF network slices, information of the intra-domain NRP can be specified using special SR binding segments which are called NRP binding segments (NRP BSID). Then a multi-domain IETF network slice can be specified using a list of NRP BSIDs in the packet, each of which is used by the corresponding domain edge nodes to steer the traffic of the end-to-end IETF network slice into the specific intra-domain NRP. This document describes the functionality of the NRP binding segment and its instantiation in SR-MPLS and SRv6 data planes. | ||||||||||||||||
| draft-li-spring-sr-sfc-control-plane-framework-08.txt | |||||||||||||||||
| A Framework for Constructing Service Function Chaining Systems Based on Segment Routing | |||||||||||||||||
|
Segment Routing (SR) allows for a flexible definition of end-to-end paths by encoding paths as sequences of topological sub-paths, called "segments". Segment routing architecture can be implemented over an MPLS data plane as well as an IPv6 data plane. Service Function Chaining (SFC) provides support for the creation of composite services that consist of an ordered set of Service Functions (SF) that are to be applied to packets and/or frames selected as a result of classification. SFC can be implemented based on several technologies, such as Network Service Header (NSH) and SR. This document describes a framework for constructing SFC based on Segment Routing. The document reviews the control plane solutions for route distribution of service function instance and service function path, and steering packets into a service function chain. | ||||||||||||||||
| draft-li-spring-srh-tlv-processing-programming-04.txt | |||||||||||||||||
| SRH TLV Processing Programming | |||||||||||||||||
|
This document proposes a mechanism to program the processing rules of Segment Routig Header (SRH) optional TLVs explicitly on the ingress node. In this mechanism, there is no need to configure local configuration at the node to support SRH TLV processing. A network operator can program to process specific TLVs on specific segment endpoint nodes for specific packets on the ingress node, which is more efficient for SRH TLV processing. | ||||||||||||||||
| draft-li-spring-srv6-security-consideration-10.txt | |||||||||||||||||
| Security Considerations for SRv6 Networks | |||||||||||||||||
|
SRv6 inherits potential security vulnerabilities from Source Routing in general, and also from IPv6. This document describes various threats and security concerns related to SRv6 networks and existing approaches to solve these threats. | ||||||||||||||||
| draft-li-teas-composite-network-slices-00.txt | |||||||||||||||||
| Realization of Composite IETF Network Slices | |||||||||||||||||
|
Network slicing can be used to meet the connectivity and performance requirement of different applications or customers in a shared network. An IETF network slice may be used for 5G or other network scenarios. In the context of 5G, a 5G end-to-end network slice consists of three different types of network technology segments: Radio Access Network (RAN), Transport Network (TN) and Core Network (CN). The transport segments of the 5G end-to-end network slice can be provided using IETF network slices. In some scenarios, IETF network slices may span multiple network domains, and IETF network slices may be composed hierarchically, which means a network slice may itself be further sliced. This document first describes the possible use cases of composite IETF network slices, then it provides considerations about the realization of composite IETF network slices. For the interaction between IETF network slices with 5G network slices, the identifiers of the 5G network slice may be introduced into IETF networks. For the multi-domain IETF network slices, the Inter-Domain Network Resource Partition Identifier (Inter-domain NRP ID) is defined. For the hierarchical IETF network slices, the structure of the NRP ID is discussed. These network slice-related identifiers may be used in the data plane, control plane and management plane of the network for the instantiation and management of composite IETF network slices. This document also describes the management considerations of composite network slices. | ||||||||||||||||
| draft-li-teas-hierarchy-ip-controllers-10.txt | |||||||||||||||||
| Hierarchy of IP Controllers (HIC) | |||||||||||||||||
|
This document describes the interactions between various IP controllers in a hierarchical fashion to provide various IP services. It describes how the Abstraction and Control of Traffic Engineered Networks (ACTN) framework is applied to the Hierarchy of IP controllers (HIC) as well as document the interactions with other protocols like BGP, Path Computation Element Communication Protocol (PCEP), and other YANG-based protocols to provide end to end dynamic services spanning multiple domains and controllers (e.g. Layer 3 Virtual Private Network (L3VPN), Seamless MPLS etc). | ||||||||||||||||
| draft-liang-lsr-isis-flowspec-extensions-00.txt | |||||||||||||||||
| IS-IS Extensions for Flow Specification | |||||||||||||||||
|
Dissemination of the Traffic flow information was first introduced in the BGP protocol [RFC5575]. FlowSpec rules are used to distribute traffic filtering rules that are used to filter Denial-of-Service (DoS) attacks. For the networks that only deploy IS-IS or IS-IS variant, it is required that IS-IS is extended to distribute Flow Specification or FlowSpec rules. This document discusses the use cases for distributing flow specification (FlowSpec) routes using IS-IS. Furthermore, this document defines a new IS-IS FlowSpec Reachability TLV encoding format that can be used to distribute FlowSpec rules, its validation procedures for imposing the filtering information on the routers, and a capability to indicate the support of FlowSpec functionality. | ||||||||||||||||
| draft-liang-lsr-ospf-flowspec-extensions-00.txt | |||||||||||||||||
| OSPF Extensions for Flow Specification | |||||||||||||||||
|
Dissemination of the Traffic flow information was first introduced in the BGP protocol [RFC5575]. FlowSpec routes are used to distribute traffic filtering rules that are used to filter Denial-of-Service (DoS) attacks. For the networks that only deploy an IGP (Interior Gateway Protocol) (e.g., OSPF), it is required that the IGP is extended to distribute Flow Specification or FlowSpec routes. This document discusses the use cases for distributing flow specification (FlowSpec) routes using OSPF. Furthermore, this document defines a OSPF FlowSpec Opaque Link State Advertisement (LSA) encoding format that can be used to distribute FlowSpec routes, its validation procedures for imposing the filtering information on the routers, and a capability to indicate the support of FlowSpec functionality. | ||||||||||||||||
| draft-lihawi-ancp-protocol-access-extension-10.txt | |||||||||||||||||
| Access Extensions for ANCP | |||||||||||||||||
|
The purpose of this document is to specify extensions to ANCP (Access Node Control Protocol) (RFC6320) to support PON as described in RFC6934 and some other DSL Technologies including G.fast. This document updates RFC6320 by modifications to terminologies, flows and specifying new TLV types. This document updates RFC6320 by modifications to terminologies, flows and specifying new TLV types. | ||||||||||||||||
| draft-lin-idr-bgp-nof-nlri-02.txt | |||||||||||||||||
| Distribution of Device Discovery Information in NVMe Over RoCEv2 Storage Network Using BGP | |||||||||||||||||
|
This document proposes a method of distributing device discovery information in NVMe over RoCEv2 storage network using the BGP routing protocol. A new BGP Network Layer Reachability Information (NLRI) encoding format, named NoF NLRI, is defined. | ||||||||||||||||
| draft-lin-idr-bgpls-te-policy-pm-00.txt | |||||||||||||||||
| BGP-LS Advertisement of TE Policy Performance Metric | |||||||||||||||||
|
This document describes a way to advertise the performance metrics for Traffic Engineering (TE) Policy using BGP Link State (BGP-LS). | ||||||||||||||||
| draft-lin-idr-sr-epe-over-l2bundle-01.txt | |||||||||||||||||
| Segment Routing BGP Egress Peer Engineering over Layer 2 Bundle | |||||||||||||||||
|
There are deployments where the Layer 3 interface on which a BGP peer session is established is a Layer 2 interface bundle. In order to allow BGP-EPE to control traffic flows on individual member links of the underlying Layer 2 bundle, BGP Peering SIDs need to be allocated to individual bundle member links, and advertisement of such BGP Peering SIDs in BGP-LS is also required. This document describes how to support Segment Routing BGP Egress Peer Engineering over Layer 2 bundle. | ||||||||||||||||
| draft-lin-idr-sr-policy-headend-behavior-01.txt | |||||||||||||||||
| BGP Extensions of SR Policy for Headend Behavior | |||||||||||||||||
|
This document defines extensions to Border Gateway Protocol (BGP) to distribute SR policies carrying headend behavior. | ||||||||||||||||
| draft-lin-idr-sr-policy-seglist-id-03.txt | |||||||||||||||||
| BGP SR Policy Extensions for Segment List Identifier | |||||||||||||||||
|
Segment Routing is a source routing paradigm that explicitly indicates the forwarding path for packets at the ingress node. An SR Policy is a set of candidate paths, each consisting of one or more segment lists. This document defines extensions to BGP SR Policy to specify the identifier of segment list. | ||||||||||||||||
| draft-lin-lsr-flex-algo-metric-02.txt | |||||||||||||||||
| Advertisement of Dedicated Metric for Flexible Algorithm in IGP | |||||||||||||||||
|
This document proposes a method to advertise dedicated metric for Flex-Algorithm in IGP. | ||||||||||||||||
| draft-lin-lsr-srv6-service-sid-01.txt | |||||||||||||||||
| IS-IS and OSPFv3 Extensions to Advertise SRv6 Service SID | |||||||||||||||||
|
The IPv6 backbone networks only deploying IGP may be required to interconnect IPv4 islands. SRv6 Service SIDs like End.DT4 may be used to realize such requirements. This document extends IS-IS and OSPFv3 to advertise SRv6 Service SIDs. | ||||||||||||||||
| draft-lin-savnet-intra-domain-bgp-spf-extensions-00.txt | |||||||||||||||||
| BGP SPF Extensions for Intra-domain SAVNET | |||||||||||||||||
|
This document describes the BGP SPF protocol extension that is required for Source Address Validation in Intra-domain. By extending BGP SPF and adding the BGP SPF protocol calculation procedure, the SAV information can be accurately calculated to realize the source address verification. | ||||||||||||||||
| draft-lin-savnet-lsr-intra-domain-method-01.txt | |||||||||||||||||
| Intra-domain SAVNET method | |||||||||||||||||
|
This document proposes a method of Source Address Validation in Intra-domain, which can be applied to OSPF and IS-IS protocols. By extending IGP and adding the protocol calculation procedure, the SAV rule can be accurately calculated to realize the source address verification. | ||||||||||||||||
| draft-lin-sbfd-path-consistency-over-srv6-03.txt | |||||||||||||||||
| S-BFD Path Consistency over SRv6 | |||||||||||||||||
|
Bidirectional Forwarding Detection (BFD) can be used to monitor paths between nodes. Seamless BFD (S-BFD) provides a simplified mechanism which is suitable for monitoring of paths that are setup dynamically and on a large scale network. In SRv6, when a headend use S-BFD to monitor the segment list/CPath of SRv6 Policy, the forward path of control packet is indicated by segment list, the reverse path of response control packet is via the shortest path from the reflector back to the initiator (headend) as determined by routing. The forward path and reverse path of control packet are likely inconsistent going through different intermediate nodes or links. This document describes a method to keep the forward path and reverse path of S-BFD consistent when detecting SRv6 Policy. | ||||||||||||||||
| draft-lin-spring-srv6-across-untrusted-domain-00.txt | |||||||||||||||||
| Considerations for SRv6 across Untrusted Domain | |||||||||||||||||
|
Segment Routing operates within a trusted domain. There are some scenarios in which the whole SRv6 domain is separated by untrusted domain and SRv6 packets need to traverse it. This document describes some use cases of SRv6 across untrusted domain, and proposes a solution using IPSec technology. | ||||||||||||||||
| draft-lingga-i2nsf-analytics-interface-dm-01.txt | |||||||||||||||||
| I2NSF Analytics Interface YANG Data Model | |||||||||||||||||
|
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 system in a Network Functions Virtualization (NFV) environment. The YANG data model described in this document is based on the I2NSF NSF- Facing Interface and the I2NSF Monitoring Interface for enabling the delivery of analytics information based on monitoring data received from a Network Security Function (NSF). | ||||||||||||||||
| draft-linkova-v6ops-ipmaclimi-00.txt | |||||||||||||||||
| Minimizing Damage of Limiting Number of IPv6 Addresses per Host | |||||||||||||||||
|
This document provides recommendations to network infrastructure vendors on how to deal with multiple IPv6 addresses per host. | ||||||||||||||||
| draft-lior-radius-prepaid-extensions-22.txt | |||||||||||||||||
| Prepaid Extensions to Remote Authentication Dial-In User Service (RADIUS) | |||||||||||||||||
|
This document specifies an extension to the Remote Authentication Dial-In User Service (RADIUS) protocol that enables service providers to charge for prepaid services. The supported charging models supported are volume-based, duration-based, and based on one-time events. | ||||||||||||||||
| draft-liu-6man-icmp-verification-02.txt | |||||||||||||||||
| Extending ICMP for IP-related Information Validation | |||||||||||||||||
|
This document introduces the mechanism to verify the data plane against the control plane in IPv6/SRv6 networks by extending ICMP messages. | ||||||||||||||||
| draft-liu-bess-multihome-srv6-service-sid-flag-00.txt | |||||||||||||||||
| SRv6 Service SID Flag Extension for Multi-homed SRv6 BGP Services | |||||||||||||||||
|
In some multi-homed SRv6 L3VPN and EVPN scenarios, there are requirements for the egress PE to advertise multiple SRv6 Service SIDs for the same service, such as anycast Service SID and bypass Service SID. This document defines anycast flag and bypass flag for SRv6 Service SIDs carried in BGP messages. | ||||||||||||||||
| draft-liu-can-gap-reqs-00.txt | |||||||||||||||||
| Computing-Aware Networking (CAN) Gap Analysis and Requirements | |||||||||||||||||
|
This document provides gap analysis and requirements for the problems and use cases that champion the joint optimization of both network and computing resources as outlined in[I-D.liu-can-ps-usecases]. It also identifies the key engineering investigation areas which require adequate architectures and protocols to achieve balanced computing and networking resource utilization among facilities providing the services. | ||||||||||||||||
| draft-liu-can-ps-usecases-00.txt | |||||||||||||||||
| Computing-Aware Networking (CAN) Problem Statement and Use Cases | |||||||||||||||||
|
Many service providers have been exploring distributed computing techniques to achieve better service response time and optimized energy consumption. Such techniques rely upon the distribution of computing services and capabilities over many locations in the network, such as its edge, the metro region, virtualized central office, and other locations. In such a distributed computing environment, providing services by utilizing computing resources hosted in various computing facilities (e.g., edges) is being considered, e.g., for computationally intensive and delay sensitive services. Ideally, services should be computationally balanced using service-specific metrics instead of simply dispatching the service requests in a static way or optimizing solely connectivity metrics. For example, systematically directing end user-originated service requests to the geographically closest edge or some small computing units may lead to an unbalanced usage of computing resources, which may then degrade both the user experience and the overall service performance. We have named this kind of network with dynamic sharing of edge compute resources "Computing-Aware Networking" (CAN). This document provides the problem statement and the typical scenarios of CAN, which is to show the necessity of considering more factors when steering the traffic to the appropriate service instance based on the basic edge computing deployment to provide the service equivalency. | ||||||||||||||||
| draft-liu-ccamp-optical2cloud-problem-statement-04.txt | |||||||||||||||||
| Problem Statement and Gap Analysis for Connecting to Cloud DCs via Optical Networks | |||||||||||||||||
|
Many applications, including optical leased line, cloud VR and computing cloud, benefit from the network scenario where the data traffic to cloud data centers (DCs) is carried end-to-end over an optical network. This document describes the problem statement and requirements for connecting to cloud DCs over optical networks, and presents a gap analysis for existing control plane protocols for supporting this network scenario. | ||||||||||||||||
| draft-liu-han-zhang-lakaiot-00.txt | |||||||||||||||||
| Requirement of Lightweight Authentication and Key Agreement Protocols for IoT | |||||||||||||||||
|
This document specifies the requirement of lightweight authentication and key agreement protocols for Internet of Things (LAKAPIoT). The authentication and key agreement protocols are very crucial for IoT since it can prevent unauthorized or malicious IoT devices from accessing the network. However, most IoT devices have limited storage, computing and communication capacity. Moreover, the network archi- tecture of IoT is very different from the traditional network. Therefore, designing authentication and key agreement protocols for IoT is an essential step to ensure its security. In this draft, the requirement of lightweight authentication and key agreement protocols for IoT is proposed. | ||||||||||||||||
| draft-liu-idr-bgp-network-slicing-02.txt | |||||||||||||||||
| BGP Extensions to Support Packet Network Slicing in SR Policy | |||||||||||||||||
|
This document defines extensions to BGP in order to advertise Network Resource Partition (NRP) in SR policy. | ||||||||||||||||
| draft-liu-idr-bgpls-extention-for-srv6-endxu-01.txt | |||||||||||||||||
| BGP Link State Extensions for SRv6 End.XU Function | |||||||||||||||||
|
The SRv6 END.XU function points to an underlying interface, which can represent an underly link (or path) between two routers. This document extends BGP-LS to advertise the link attributes of underlay link and the END.XU SID information. | ||||||||||||||||
| draft-liu-idr-bgpls-sr-p2mp-policy-distribution-00.txt | |||||||||||||||||
| Distribution of SR P2MP Policies and State using BGP-LS | |||||||||||||||||
|
This document specifies the extensions to BGP Link State (BGP-LS) to distribute SR P2MP Policies and state. This allows operators to establish a consistent view of the underlying multicast network state, providing an efficient mechanism for the advertisement and synchronization of SR P2MP policies. | ||||||||||||||||
| draft-liu-iot-arch-01.txt | |||||||||||||||||
| The Architecture for Internet of Things Network | |||||||||||||||||
|
In this document, it identifies gateways for field-bus networks, data storages for archiving and developing data sharing platform, and application units to be important system components for developing digital communities: i.e., building-scale and city-wide ubiquitous facility networking infrastructure. The standard defines a data exchange protocol that generalizes and interconnects these components (gateways, storages, application units) over the IPv6-based networks. This enables integration of multiple facilities, data storages, application services such as central management, energy saving, environmental monitoring and alarm notification systems. | ||||||||||||||||
| draft-liu-ipsecme-ikev2-mtu-dect-06.txt | |||||||||||||||||
| IKEv2 Link Maximum Atomic Packet and Packet Too Big Notification Extension | |||||||||||||||||
|
This document defines the IKEv2 Link Maximum Atomic Packet Notification and Packet Too Big Extension. This extension enables an egress security gateway to notify its ingress counter part that fragmentation is happening or a packet too big is received (and cannot be decrypted). In both cases, the egress node provides MTU information that enable the ingress node can configure appropriately its Tunnel Maximum Transmission Unit or MTU or simply put Tunnel MTU (TMTU) to prevent fragmentation or too big packets to be transmitted. This extension does not intent to replace ICMP. It provides information ICMP does not provide and even when that information could be provided by ICMP, this extension provides a reliable authenticated channel that ensures the ingress node receive this information even when ICMP messages cannot be received by the ingress node. | ||||||||||||||||
| draft-liu-ipsecme-ikev2-rekey-redundant-sas-02.txt | |||||||||||||||||
| IKEv2 Count Based SA Extension | |||||||||||||||||
|
This document describes an IKEv2 extension that enables a more rational use of count based SA. This includes preventing the creation of redundant SAs resulting from simultaneous rekeys. | ||||||||||||||||
| draft-liu-lsr-mpls-inspection-msd-00.txt | |||||||||||||||||
| Signaling Base MPLS Inspection MSD | |||||||||||||||||
|
This document defines a new type of MSD, Base MPLS Inspection MSD, and the mechanism to signal this MSD using IGP and BGP-LS. | ||||||||||||||||
| draft-liu-mboned-amt-yang-02.txt | |||||||||||||||||
| YANG Data Model for Automatic Multicast Tunneling | |||||||||||||||||
|
This document defines YANG data models for the configuration and management of Automatic Multicast Tunneling (AMT) protocol operations. | ||||||||||||||||
| draft-liu-mpls-lsp-ping-nrp-01.txt | |||||||||||||||||
| LSP Ping/Traceroute for SR-MPLS NRP SIDs | |||||||||||||||||
|
[RFC8287] defines the extensions to MPLS LSP ping and traceroute for Segment Routing IGP-Prefix and IGP-Adjacency SIDs with an MPLS data plane. To correctly identify and validate an SR NRP SID, the validating device also requires NRP-ID to be supplied in the FEC Stack sub-TLV. This document introduces new Target FEC Stack sub- TLVs to perform MPLS LSP ping and traceroute for NRP SIDs. | ||||||||||||||||
| draft-liu-msr6-problem-statement-01.txt | |||||||||||||||||
| Problem Satement of IPv6 Multicast Source Routing (MSR6) | |||||||||||||||||
|
This document analyses the gaps of the existing IPv6 multicast solutions under discussion in IETF based on the requirements. | ||||||||||||||||
| draft-liu-protocol-interactive-media-transmission-00.txt | |||||||||||||||||
| Protocol for interactive low-latency media transmission system | |||||||||||||||||
|
This document introduces a protocol used for interactive low-latency media transmission network. | ||||||||||||||||
| draft-liu-rtgwg-sr-protection-considerations-00.txt | |||||||||||||||||
| Considerations for Protection of SR Networks | |||||||||||||||||
|
This document describes the considerations for protection of Segment Routing (SR) networks. | ||||||||||||||||
| draft-liu-sidrops-rtr-yang-01.txt | |||||||||||||||||
| YANG Data Model for RPKI to Router Protocol and BGP Origin AS Validation | |||||||||||||||||
|
This document defines YANG data models for configuring and managing Resource Public Key Infrastructure (RPKI) to Router Protocol and BGP Origin AS Validation. | ||||||||||||||||
| draft-liu-sm-for-openpgp-00.txt | |||||||||||||||||
| Abstract | |||||||||||||||||
|
This document introduces the Shang Mi(SM) cryptographic algorithm for openpgp protocol. | ||||||||||||||||
| draft-liu-spring-bfd-srv6-policy-encap-00.txt | |||||||||||||||||
| Encapsulation of BFD for SRv6 Policy | |||||||||||||||||
|
Bidirectional Forwarding Detection (BFD) mechanisms can be used for fast detection of failures in the forwarding path of SR Policy. This document describes the encapsulation of BFD for SRv6 Policy, which can be applied for both S-BFD and U-BFD. The BFD packets may be encapsulated in transport mode or tunnel mode. | ||||||||||||||||
| draft-liu-spring-nrp-id-in-srv6-segment-02.txt | |||||||||||||||||
| NRP ID in SRv6 segment | |||||||||||||||||
|
This document proposes a method to carry the NRP-ID with the packet in the SRv6 segment. | ||||||||||||||||
| draft-liu-spring-sr-policy-flexible-path-selection-01.txt | |||||||||||||||||
| Flexible Candidate Path Selection of SR Policy | |||||||||||||||||
|
This document proposes a flexible SR policy candidate path selection method. Based on the real-time resource usage and forwarding quality of candidate paths, the head node can perform dynamic path switching among multiple candidate paths in the SR policy. | ||||||||||||||||
| draft-liu-teas-transport-network-slice-yang-06.txt | |||||||||||||||||
| IETF Network Slice Topology YANG Data Model | |||||||||||||||||
|
An IETF network slice may use an abstract topology to describe intended underlay for connectivities between slice endpoints. Abstract topologies help the customer to request network slices with shared resources amongst connections, and connections can be activated within the slice as needed. This document describes a YANG data model for managing and controlling abstract topologies for IETF network slices defined in RFC YYYY. [RFC EDITOR NOTE: Please replace RFC YYYY with the RFC number of draft-ietf-teas-ietf-network-slices once it has been published. | ||||||||||||||||
| draft-liu-zhang-han-lakapiot-01.txt | |||||||||||||||||
| Requirement of Lightweight Authentication and Key Agreement Protocols for IoT | |||||||||||||||||
|
This document specifies the requirement of lightweight authentication and key agreement protocols for Internet of Things (LAKAPIoT). The authentication and key agreement protocols are very crucial for IoT since it can prevent unauthorized or malicious IoT devices from accessing the network. However, most IoT devices have limited storage, computing and communication capacity. Moreover, the network archi- tecture of IoT is very different from the traditional network. Therefore, designing authentication and key agreement protocols for IoT is an essential step to ensure its security. In this draft, the requirement of lightweight authentication and key agreement protocols for IoT is proposed. | ||||||||||||||||
| draft-livingood-low-latency-deployment-01.txt | |||||||||||||||||
| Comcast ISP Low Latency Deployment Design Recommendations | |||||||||||||||||
|
The IETF's Transport Area Working Group (TSVWG) has finalized experimental RFCs for Low Latency, Low Loss, Scalable Throughput (L4S) and new Non-Queue-Building (NQB) per hop behavior. These documents do a good job of describing a new architecture and protocol for deploying low latency networking. But as is normal for many such standards, especially those in experimental status, certain design decisions are ultimately left to implementers. This document explores the potential implications of key deployment design decisions and makes recommendations for those decisions that may help drive adoption. | ||||||||||||||||
| draft-looker-oauth-client-discovery-01.txt | |||||||||||||||||
| OAuth 2.0 Client Discovery | |||||||||||||||||
|
This specification defines a mechanism for an authorization server to obtain the metadata of a client, including its endpoint locations and capabilities without the need for a registration process. 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/mattrglobal/draft-looker-oauth-client-discovery. | ||||||||||||||||
| draft-lozano-icann-registry-interfaces-19.txt | |||||||||||||||||
| ICANN Registry Interfaces | |||||||||||||||||
|
This document describes the technical details of the interfaces provided by the Internet Corporation for Assigned Names and Numbers (ICANN) to its contracted parties to fulfill reporting requirements. The interfaces provided by ICANN to Data Escrow Agents and Registry Operators to fulfill the requirements of Specifications 2 and 3 of the gTLD Base Registry Agreement are described in this document. Additionally, interfaces for retrieving the IP addresses of the probe nodes used in the SLA Monitoring System (SLAM) and interfaces for supporting maintenance window objects are described in this document. | ||||||||||||||||
| draft-lp-idr-bgp-ls-sr-policy-supplement-00.txt | |||||||||||||||||
| Supplement of BGP-LS Distribution for SR Policies and State | |||||||||||||||||
|
This document supplements some additional information of the segment list in the BGP-LS advertisement for SR Policy state information . | ||||||||||||||||
| draft-lp-idr-sr-path-protection-04.txt | |||||||||||||||||
| BGP Extensions of SR Policy for Segment List Identification and Protection | |||||||||||||||||
|
This document proposes extensions of BGP in order to provide identification and protection information of segment lists when delivering SR policy via BGP. | ||||||||||||||||
| draft-ls-6man-ipcomp-exclude-transport-layer-00.txt | |||||||||||||||||
| IP Payload Compression excluding transport layer | |||||||||||||||||
|
IP Payload Compression Protocol (IPComp) is used for compressing the IP payload in transmission to increase the communication performance. The IPComp is applied to payload of the IP datagram, starting with the first octet immediately after the IP header in IPv4, and starting with the first octet after the excluded IPv6 Extension headers. However, Transport layer information such as source port and destination port are useful in many network functions in transmission. This document defines extensions of IP payload compression protocol (IPComp) to support compressing the payload excluding the transport layer information, to enable network functions using transport layer information (e.g., ECMP) working together with the payload compression. This document also defines an extension of IPComp to indicate the payload is not compressed to solve the out-of-order problems between the compressed and uncompressed packets. | ||||||||||||||||
| draft-ls-idr-bgp-ls-service-metadata-01.txt | |||||||||||||||||
| Distribution of Service Metadata in BGP-LS | |||||||||||||||||
|
In edge computing, a service may be deployed on multiple instances within one or more sites, called edge service. The edge service is associated with an ANYCAST address in IP layer, and the route of it with potential service metatdata will be distributed to the network. The Edge Service Metadata can be used by ingress routers to make path selections not only based on the routing cost but also the running environment of the edge services. The service route with metadata can be collected by a PCE(Path Compute Element) or an analyzer for calculating the best path to the best site/instance. This draft describes a mechanism to collect the information of the service routes and related service metadata in BGP-LS. | ||||||||||||||||
| draft-lucente-grow-bmp-rel-00.txt | |||||||||||||||||
| Logging of routing events in BGP Monitoring Protocol (BMP) | |||||||||||||||||
|
The BGP Monitoring Protocol (BMP) does provision for BGP session event logging (Peer Up, Peer Down), state synchronization (Route Monitoring), debugging (Route Mirroring) and Statistics messages, among the others. This document defines a new Route Event Logging (REL) message type for BMP with the aim of covering use-cases with affinity to alerting, reporting and on-change analysis. | ||||||||||||||||
| draft-lukianets-open-ethics-transparency-protocol-02.txt | |||||||||||||||||
| Open Ethics Transparency Protocol | |||||||||||||||||
|
The Open Ethics Transparency Protocol (OETP) is an application-level protocol for publishing and accessing ethical Disclosures of IT Products and their Components. The Protocol is based on HTTP exchange of information about the ethical "postures", provided in an open and standardized format. The scope of the Protocol covers Disclosures for systems such as Software as a Service (SaaS) Applications, Software Applications, Software Components, Application Programming Interfaces (API), Automated Decision-Making (ADM) systems, and systems using Artificial Intelligence (AI). OETP aims to bring more transparent, predictable, and safe environments for the end-users. The OETP Disclosure Format is an extensible JSON-based format. | ||||||||||||||||
| draft-lx-msr6-rgb-segment-04.txt | |||||||||||||||||
| RGB (Replication through Global Bitstring) Segment for Multicast Source Routing over IPv6 | |||||||||||||||||
|
This document introduces the RGB (Replication through Global Bitstring) Segment for Multicast Source Routing over IPv6. | ||||||||||||||||
| draft-lz-bess-srv6-service-capability-04.txt | |||||||||||||||||
| SRv6-based BGP Service Capability | |||||||||||||||||
|
This draft describes the problems that may be encountered during the deployment of SRv6-based BGP services in the co-existence scenario where the network supports both SRv6 and MPLS in a given domain, and the possible solutions. | ||||||||||||||||
| draft-ma-identifier-access-http-06.txt | |||||||||||||||||
| HTTP Usage in the Industrial Internet Identifier Data Access Protocol (IIIDAP) | |||||||||||||||||
|
This document describes an Extensible Provisioning Protocol (EPP) for the provisioning and management of enterprises and identifiers between the server which is called Business Management System (BMS) and is entitled to manage the identifier top-level node and the client which is also referred to as Second Node Management System (SNMS). Specified in XML, the mapping defines EPP command syntax and semantics as applied to enterprise and identifier management. | ||||||||||||||||
| draft-ma-intarea-encapsulation-of-san-header-00.txt | |||||||||||||||||
| Encapsulation of SAN Header | |||||||||||||||||
|
This document proposes the encapsulation of the SAN header in the IPv6 data plane to carry the SAN related information, which could be used to associate the networking and computing resources indexed by SAN ID and route and forward the service traffic accordingly. | ||||||||||||||||
| draft-ma-intarea-identification-header-of-san-00.txt | |||||||||||||||||
| Service Identification Header of Service Aware Network | |||||||||||||||||
|
As the cloud and computing migrates to edges further away from the traditional centered cloud, the services residing at the distributed cloud start to be delivered in such a ubiquitous and dynamic way. That it is challenging to the ongoing routing and interconnecting scheme under which host address is the global networking identification. This draft proposes a service identification which is designed to be treated both as a service routable ID and an interface to the service requirements as well as service-associated cloud resources. Service Aware Network header is illustrated and specified. | ||||||||||||||||
| draft-ma-moq-relay-for-deadline-00.txt | |||||||||||||||||
| MoQ relay for support of deadline-aware media transport | |||||||||||||||||
|
This draft specifies the behavior of MoQ relays for delivering media before the deadline to decrease end-to-end latency and save transport costs in media transmission. To achieve this, the draft introduces deadline-aware actions prioritizing media streams with earlier deadlines, ensuring timely transmission while minimizing costs. | ||||||||||||||||
| draft-ma-netmod-immutable-flag-06.txt | |||||||||||||||||
| YANG Extension and Metadata Annotation for Immutable Flag | |||||||||||||||||
|
This document defines a way to formally document as a YANG extension or YANG metadata an existing model handling behavior: modification restrictions on data declared as configuration. This document defines a YANG extension named "immutable" to indicate that specific "config true" data nodes are not allowed to be created/deleted/updated. To indicate that specific entries of a list/leaf-list node or instances inside list entries cannot be updated/deleted after initialization, a metadata annotation with the same name is also defined. Any data node or instance marked as immutable is read-only to the clients of YANG-driven management protocols, such as NETCONF, RESTCONF and other management operations (e.g., SNMP and CLI requests). | ||||||||||||||||
| draft-ma-opsawg-ucl-acl-02.txt | |||||||||||||||||
| A Policy-based Network Access Control | |||||||||||||||||
|
This document defines a YANG module for policy-based network access control, which provides consistent and efficient enforcement of network access control policies based on group identity. Moreover, this document defines a mechanism to ease the maintenance of the mapping between a user-group identifier and a set of IP/MAC addresses to enforce policy-based network access control. Also, the document defines a common schedule YANG module which is designed to be applicable for policy activation based on date and time conditions. In addition, the document defines a RADIUS attribute that is used to communicate the user group identifier as part of identification and authorization information. | ||||||||||||||||
| draft-ma-quic-mpqoe-01.txt | |||||||||||||||||
| An Advanced Scheduling Option for Multipath QUIC | |||||||||||||||||
|
This document specifies an advanced scheduling option for multipath QUIC protocol. The goal is to enable the use of multipath QUIC for applications that have tight latency constraints. For general purpose multipath packet scheduling, please refer to [I-D.bonaventure-iccrg-schedulers]. 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/yfmascgy/draft-ma-quic-advance-scheduling. | ||||||||||||||||
| draft-mackenzie-bess-evpn-l3mh-proto-02.txt | |||||||||||||||||
| EVPN multi-homing support for L3 services | |||||||||||||||||
|
This document introduces the utilization of EVPN Multi-Chassis Link Aggregation Group (MC-LAG) technology to enhance network availability and load balancing for various L3 services in EVPN. | ||||||||||||||||
| draft-madeleine-explicit-domains-relations-00.txt | |||||||||||||||||
| Explicit bilateral relationship between domains | |||||||||||||||||
|
Good practices of domain handling are often overseen, making it difficult for users to know if a domain is legitimate, this proposal aims to create an easy, accessible way to verify relations between domains and by extension entities. | ||||||||||||||||
| draft-madi-sidrops-rush-07.txt | |||||||||||||||||
| RPKI validated cache Update in SLURM over HTTPs (RUSH) | |||||||||||||||||
|
This document defines a method for transferring RPKI validated cache update information in JSON object format over HTTPs. | ||||||||||||||||
| draft-mahesh-bess-srv6-mup-yang-02.txt | |||||||||||||||||
| A YANG Data Model for SRv6 Mobile User Plane | |||||||||||||||||
|
This document defines a YANG data model for configuration and management of Mobile User Plane (MUP) in a SRv6 network. | ||||||||||||||||
| draft-mahy-mimi-content-02.txt | |||||||||||||||||
| More Instant Messaging Interoperability (MIMI) message content | |||||||||||||||||
|
This document describes content semantics common in Instant Messaging (IM) systems and describes an example profile suitable for instant messaging interoperability of messages end-to-end encrypted inside the MLS (Message Layer Security) Protocol. | ||||||||||||||||
| draft-mahy-mimi-identity-01.txt | |||||||||||||||||
| More Instant Messaging Interoperability (MIMI) Identity Concepts | |||||||||||||||||
|
This document discusses concepts in instant messaging identity interoperability when using end-to-end encryption, for example with the MLS (Message Layer Security) Protocol. The goal is to explore the problem space in preparation for framework and requirements documents. | ||||||||||||||||
| draft-mahy-mimi-problem-outline-02.txt | |||||||||||||||||
| More Instant Messaging Interoperability (MIMI) problem outline | |||||||||||||||||
|
Instant Messaging interoperability requirements have changed dramatically since the last IETF activity in the space. This document presents an outline of problems that need to be addressed to make possible interoperability of modern Instant Messaging systems. The goal of this problem outline is to point at more detailed drafts which spawn discussion and eventually spur the IETF standards process. | ||||||||||||||||
| draft-mahy-mls-content-adv-00.txt | |||||||||||||||||
| Content Type Advertisement for Message Layer Security (MLS) | |||||||||||||||||
|
This document describes a default mechanism for the advertisement of content types and content type capabilities inside the Message Layer Security (MLS). It defines two new extensions and a minimal framing format. | ||||||||||||||||
| draft-mahy-mls-group-anchors-00.txt | |||||||||||||||||
| Per-group Credential Anchors for Message Layer Security (MLS) | |||||||||||||||||
|
This document describes a Message Layer Security (MLS) GroupContext extension to restrict the set of trust anchors used for identity validation in MLS groups. It is useful in federated or interoperability environments to allow a specific federated domain to assert identities for its own identifiers but not for the identifiers of other domains. | ||||||||||||||||
| draft-mandyam-rats-proxlocclaim-00.txt | |||||||||||||||||
| The Proximate Location Claim | |||||||||||||||||
|
The Entity Attestation Token (EAT) is an extensible attestation version of a CBOR Web Token (CWT). EAT defines a location claim, but does not define a proximate location claim. This document proposes a claim in which an attester can relay detected relative location of a target. | ||||||||||||||||
| draft-marin-yang-edhoc-oscore-00.txt | |||||||||||||||||
| A YANG data model for SDN-based key management with EDHOC and OSCORE | |||||||||||||||||
|
This document defines YANG data models which allow a Software-Defined Networking (SDN) Controller (Controller) using NETCONF, RESTCONF or CORECONF to provide configuration and monitoring Internet-of-Things devices (Things) that support Ephemeral Diffie-Hellman Over COSE (EDHOC) and/or OSCORE. In particular, a YANG data model defines the required configuration parameters to perform EDHOC between two Things (EDHOC case). Another YANG data model is to configure the OSCORE contexts directly into the Thing (OSCORE case). The service described in this document allows the configuration and monitoring of Things that supports EDHOC and OSCORE or only OSCORE by allowing a protected Thing-to-Thing communication based on CoAP. This document focuses on providing YANG data models for configuring EDHOC or OSCORE. This allows OSCORE establishment with minimal intervention by the network administrator. | ||||||||||||||||
| draft-martin-http-carbon-emissions-scope-2-00.txt | |||||||||||||||||
| HTTP Response Header Field: Carbon-Emissions-Scope-2 | |||||||||||||||||
|
This document defines the "Carbon-Emissions-Scope-2" HTTP response header field for reporting the amount of carbon emissions associated with processing a given HTTP request, as calculated according to the Scope 2 protocol outlined in ISO 14064-1:2006. | ||||||||||||||||
| draft-marx-quic-qlog-datagram-00.txt | |||||||||||||||||
| QUIC and HTTP/3 Datagram event definitions for qlog | |||||||||||||||||
|
This document describes qlog data type definitions for both the QUIC Datagram Frame defined in [RFC9221] and the HTTP/3 Datagram Frame defined in [RFC9297]. These data types are intended for use within event definitions defined in [QLOG-QUIC] and [QLOG-HTTP3]. | ||||||||||||||||
| draft-mathis-tsvwg-safecc-02.txt | |||||||||||||||||
| Safe Congestion Control | |||||||||||||||||
|
We present criteria for evaluating Congestion Control Algorithms (CCAs) for behaviors that have the potential to cause harm to Internet applications or users. Although our primary focus is the safety of transport layer congestion control, many of these criteria should be applied to all protocol layers: entire stacks, libraries and applications themselves. | ||||||||||||||||
| draft-matsuhira-m46a-14.txt | |||||||||||||||||
| Multiple IPv4 - IPv6 mapped IPv6 address (M46A) | |||||||||||||||||
|
This document specifies Multiple IPv4 - IPv6 mapped IPv6 address(M46A) spefification. M46A is IPv4 mapped IPv6 address with plane ID. Unique allocation of plane id value enable IPv4 private address unique in IPv6 address space. This address may use IPv4 over IPv6 encapsulation and IPv4 - IPv6 translation. | ||||||||||||||||
| draft-matsuhira-m46e-fp-14.txt | |||||||||||||||||
| Multiple IPv4 - IPv6 address mapping encapsulation - fixed prefix (M46E-FP) | |||||||||||||||||
|
This document specifies Multiple IPv4 - IPv6 address mapping encapsulation - fixed prefix (M46E-FP) specification. M46E-FP makes backbone network to IPv6 only. And also, M46E-FP can stack many IPv4 networks, i.e. the networks using same IPv4 (private) addresses, without interdependence. | ||||||||||||||||
| draft-matsuhira-m46e-pr-14.txt | |||||||||||||||||
| Multiple IPv4 - IPv6 address mapping encapsulation - prefix resolution (M46E-PR) | |||||||||||||||||
|
This document specifies M46E Prefix Resolution (M46E-PR) specification. M46E-PR connect IPv4 stub networks between IPv6 backbone network. And also, M46E-PR can stack many IPv4 networks, i.e. the nwtworks using same IPv4 private addresses without interdependence. | ||||||||||||||||
| draft-matsuhira-m46e-pt-14.txt | |||||||||||||||||
| Multiple IPv4 - IPv6 address mapping encapsulation - prefix translator (M46E-PT) | |||||||||||||||||
|
This document specifies Multiple IPv4 - IPv6 mapping encapsulation - Prefix Translator (M46E-PT) specification. M46E-PT expand IPv4 network plane by connecting M46E-FP domain and M46E-PR domain. M46E- PT translate prefix part of M46E-FP address and M46E-PR address both are IPv6 address. M46E-PT does not translate IPv4 packet which is encapsulated, so transparency of IPv4 packet is not broken. | ||||||||||||||||
| draft-matsuhira-m46t-14.txt | |||||||||||||||||
| Multiple IPv4 - IPv6 address mapping translator (M46T) | |||||||||||||||||
|
This document specifies Multiple IPv4 - IPv6 address mapping Translator (M46T) specification. M46T enable access to IPv4 only host from IPv6 host. IPv4 host is identified as M46 address in IPv6 address space. The address assigned to IPv4 host may be global IPv4 address or private IPv4 address. M46T does not support access to IPv6 host from IPv4 only host. | ||||||||||||||||
| draft-matsuhira-m4p6e-14.txt | |||||||||||||||||
| Multiple IPv4 address and port number - IPv6 address mapping encapsulation (M4P6E) | |||||||||||||||||
|
This document specifies Multiple IPv4 address and port number - IPv6 address mapping encapulation (M4P6E) specification. | ||||||||||||||||
| draft-matsuhira-me6a-14.txt | |||||||||||||||||
| Multiple Ethernet - IPv6 mapped IPv6 address (ME6A) | |||||||||||||||||
|
This document specifies Multiple Ethernet - IPv6 mapped IPv6 address(ME6A) spefification. ME6A is Ethernet mapped IPv6 address with plane ID. Unique allocation of plane id value enable duplicated MAC address unique in IPv6 address space. This address may use Ethernet over IPv6 encapsulation. | ||||||||||||||||
| draft-matsuhira-me6e-fp-15.txt | |||||||||||||||||
| Multiple Ethernet - IPv6 address mapping encapsulation - fixed prefix | |||||||||||||||||
|
This document specifies Multiple Ethernet - IPv6 address mapping encapsulation - fixed prefix (ME6E-FP) base specification. ME6E-FP makes expantion ethernet network over IPv6 backbone network with encapsuation technoogy. And also, E6ME-FP can stack multiple Ethernet networks. ME6E-FP work on own routing domain. | ||||||||||||||||
| draft-matsuhira-me6e-pr-15.txt | |||||||||||||||||
| Multiple Ethernet - IPv6 address mapping encapsulation - prefix resolution | |||||||||||||||||
|
This document specifies Multiple Ethernet - IPv6 address mapping encapsulation - Prefix Resolution (ME6E-PR) specification. ME6E-PR makes expantion ethernet network over IPv6 backbone network with encapsuation technoogy. And also, E6ME-PR can stack multiple Ethernet networks. ME6E-PR work on non own routing domain. | ||||||||||||||||
| draft-matsuhira-mslb-14.txt | |||||||||||||||||
| Multi-Stage Transparent Server Load Balancing | |||||||||||||||||
|
This document specifies Multi-Stage Transparent Server Load Balancing (MSLB) specification. MSLB make server load balancing over Layer3 network without packet header change at client and server. MSLB make server load balancing with any protocol and protocol with encription such as IPsec ESP, SSL/TLS. | ||||||||||||||||
| draft-mattsson-tls-compact-ecc-04.txt | |||||||||||||||||
| Compact ECDHE and ECDSA Encodings for TLS 1.3 | |||||||||||||||||
|
The encodings used in the ECDHE groups secp256r1, secp384r1, and secp521r1 and the ECDSA signature algorithms ecdsa_secp256r1_sha256, ecdsa_secp384r1_sha384, and ecdsa_secp521r1_sha512 have significant overhead and the ECDSA encoding produces variable-length signatures. This document defines new optimal fixed-length encodings and registers new ECDHE groups and ECDSA signature algorithms using these new encodings. The new encodings reduce the size of the ECDHE groups with 33, 49, and 67 bytes and the ECDSA algorithms with an average of 7 bytes. These new encodings also work in DTLS 1.3 and are especially useful in cTLS. | ||||||||||||||||
| draft-mattsson-tls-psk-ke-dont-dont-dont-05.txt | |||||||||||||||||
| NULL Encryption and Key Exchange Without Forward Secrecy are Discouraged | |||||||||||||||||
|
Massive pervasive monitoring attacks using key exfiltration and made possible by key exchange without forward secrecy have been reported. If key exchange without Diffie-Hellman is used, static exfiltration of the long-term authentication keys enables passive attackers to compromise all past and future connections. Malicious actors can get access to long-term keys in different ways: physical attacks, hacking, social engineering attacks, espionage, or by simply demanding access to keying material with or without a court order. Exfiltration attacks are a major cybersecurity threat. If NULL encryption is used an on-path attacker can read all application data. The use of psk_ke and NULL encryption are not following zero trust principles of minimizing the impact of breach and governments have already made deadlines for their deprecation. This document evaluates TLS pre-shared key exchange modes, (EC)DHE groups, signature algorithms, and cipher suites and downgrades many entries to "N" and "D" where "D" indicates that the entries are "Discouraged". | ||||||||||||||||
| draft-mb-mpls-ioam-dex-04.txt | |||||||||||||||||
| Supporting In-Situ OAM Direct Export Using MPLS Network Actions | |||||||||||||||||
|
In-Situ Operations, Administration, and Maintenance (IOAM), defined in RFC 9197, is an on-path telemetry method to collect and transport the operational state and telemetry information that can be used to calculate various performance metrics. IOAM Direct Export (IOAM-DEX) is one of the IOAM Option types, in which the operational state and telemetry information are collected according to the specified profile and exported in a manner and format defined by a local policy. MPLS Network Actions (MNA) techniques are meant to indicate actions to be performed on any combination of Label Switched Paths (LSPs), MPLS packets, and the node itself, and also to transfer data needed for these actions. This document explores the on-path operational state, and telemetry information can be collected using IOAM-DEX Option in combination with MNA. | ||||||||||||||||
| draft-mcbride-mboned-lessons-learned-02.txt | |||||||||||||||||
| Multicast Lessons Learned from Decades of Deployment Experience | |||||||||||||||||
|
This document gives a historical perspective about the design and deployment of multicast routing protocols. The document describes the technical challenges discovered from building these protocols. Even though multicast has enjoyed success of deployment in special use-cases, we discuss what were, and are, the obstacles for mass deployment across the Internet. Individuals who are working on new multicast related protocols will benefit by knowing why we aren't using certain older protocols today. | ||||||||||||||||
| draft-mcbride-rtgwg-bgp-blockchain-02.txt | |||||||||||||||||
| BGP Blockchain | |||||||||||||||||
|
A variety of mechanisms have been developed and deployed over the years to secure BGP including the more recent RPKI/ROA mechanisms. Is it also possible to use a distributed ledger such as Blockchain to secure BGP? BGP provides decentralized connectivity across the Internet. Blockchain provides decentralized secure transactions in a append-only, tamper-resistant ledger. This document reviews possible opportunities of using Blockchain to secure BGP policies within a domain and across the global Internet. We propose that BGP data could be placed in a blockchain and smart contracts can control how the data is managed. This could create a single source of truth, something for which blockchains are particularly well suited. | ||||||||||||||||
| draft-mcd-identifier-access-authority-06.txt | |||||||||||||||||
| Finding the Authoritative Registration Data (IIIDAP) Service | |||||||||||||||||
|
This document specifies a method to find which Industrial Internet Identifier Data Access Protocol (IIIDAP) server is authoritative to answer queries for a request of identifier data. | ||||||||||||||||
| draft-mcd-identifier-access-query-06.txt | |||||||||||||||||
| Industrial Internet Identifier Data Access Protocol (IIIDAP) Query Format | |||||||||||||||||
|
This document describes uniform patterns to construct HTTP URLs that may be used to retrieve identifier information from Second-Level Nodes (SLN) using "RESTful" web access patterns. These uniform patterns define the query syntax for the Industrial Internet Identifier Data Access Protocol (IIIDAP). | ||||||||||||||||
| draft-mcd-identifier-access-responce-06.txt | |||||||||||||||||
| JSON Responses for the Industrial Internet Identifier Data Access Protocol (IIIDAP) | |||||||||||||||||
|
This document describes JSON data structures representing identifier information maintained by Second-Level Nodes (SLN). These data structures are used to form Industrial Internet Identifier Data Access Protocol (IIIDAP) query responses. | ||||||||||||||||
| draft-mcd-identifier-access-security-06.txt | |||||||||||||||||
| Security Services for the Industrial Internet Identifier Data Access Protocol (IIIDAP) | |||||||||||||||||
|
The Industrial Internet Identifier Data Access Protocol (IIIDAP) provides "RESTful" web services to retrieve identifier metadata from Second-Level Node (SLN). This document describes information security services, including access control, authentication, authorization, availability, data confidentiality, and data integrity for IIIDAP. | ||||||||||||||||
| draft-mcd-rtgwg-extension-tn-aware-mobility-05.txt | |||||||||||||||||
| Extension of Transport Aware Mobility in Data Network | |||||||||||||||||
|
The existing Transport Network Aware Mobility for 5G [TN-AWARE- MOBILITY] draft specifies a framework for mapping the 5G mobile systems Slice and Service Types (SSTs) to corresponding underlying network paths in IP and Layer 2 Transport networks.The focus of that work is limited to the 3GPP domain (i.e., eNB <-> UPFs) and doesn't go beyond the UPF to the IP Data Network. To maintain the end-to-end transport network characteristics between UEs and their application servers, the framework needs to be extended to the data centers where the services are hosted. This document describes a framework for extending the mobility aware transport network characteristics from the UPF through the IP Data Networks. | ||||||||||||||||
| draft-mcfadden-cnsldtn-effects-00.txt | |||||||||||||||||
| On the Effects of Internet Consolidation | |||||||||||||||||
|
This document contributes to the continuing discussion on Internet consolidation. Over the last several years there have been many types of discussions around consolidation at a technical level, an economic or market level and also at an engineering level. This document aims to discuss recent areas of Internet consolidation and provide some suggestions for advancing the discussion. | ||||||||||||||||
| draft-mcfadden-consolidation-taxonomy-01.txt | |||||||||||||||||
| A Taxonomy of Internet Consolidation | |||||||||||||||||
|
This document contributes to the ongoing discussion surrounding Internet consolidation. At recent IETF meetings discussions about Internet consolidation revealed that different perspectives gave completely different views of what consolidation means. While we use the term consolidation to refer to the process of increasing control over Internet infrastructure and services by a small set of organizations, it is clear that that control is expressed through economic, network traffic and protocol concerns. As a contribution to the discussion surrounding consolidation, this document attempts to provide a taxonomy of Internet consolidation with the goal of adding clarity to a complex discussion. | ||||||||||||||||
| draft-mcfadden-threat-model-00.txt | |||||||||||||||||
| Internet Threat Model - A Reconsideration | |||||||||||||||||
|
RFC3552/BCP72 describes an Internet Threat model that has been used in Internet protocol design. More than twenty years have passed since RFC3552 was written and the structure and topology of the Internet have changed dramatically. With those changes comes a question: has the Internet Threat Model changed? Or, is the model described in RFC3552 still mostly accurate? This draft attempts to describe a non-exhaustive list of the most likely updates and changes in the current threat environment. This paper has the goal of suggesting a way forward for describing the contemporary threat model and how it might inform security aspects of protocol design. | ||||||||||||||||
| draft-mclaggan-wccp-v2rev1-00.txt | |||||||||||||||||
| Web Cache Communication Protocol V2,Revision 1 | |||||||||||||||||
|
This document describes version 2 of the Web Cache Communication Protocol (WCCP). The WCCP V2 protocol specifies interactions between one or more routers and one or more web-caches. The interaction may take place within an IPv4 or IPv6 network. The purpose of the interaction is to establish and maintain the transparent redirection of selected types of traffic flowing through a group of routers (or similar devices). The selected traffic is redirected to a group of web-caches (or other traffic optimisation devices) with the aim of optimising resource usage and lowering response times. The protocol does not specify any interaction between the web-caches within a group or between a web-cache and a web-server. | ||||||||||||||||
| draft-mcmillion-key-transparency-00.txt | |||||||||||||||||
| Key Transparency | |||||||||||||||||
|
While there are several established protocols for end-to-end encryption, relatively little attention has been given to securely distributing the end-user public keys for such encryption. As a result, these protocols are often still vulnerable to eavesdropping by active attackers. Key Transparency is a protocol for distributing sensitive cryptographic information, such as public keys, in a way that reliably either prevents interference or detects that it occurred in a timely manner. In addition to distributing public keys, it can also be applied to ensure that a group of users agree on a shared value or to keep tamper-evident logs of security-critical events. | ||||||||||||||||
| draft-mcnally-deterministic-cbor-00.txt | |||||||||||||||||
| dCBOR: Deterministic CBOR Implementation Practices | |||||||||||||||||
|
CBOR has many advantages over other data serialization formats. One of its strengths is specifications and guidelines for serializing data deterministically, such that multiple agents serializing the same data automatically achieve consensus on the exact byte-level form of that serialized data. Nonetheless, determinism is an opt-in feature of the specification, and most existing CBOR codecs put the primary burden of correct deterministic serialization and validation of deterministic encoding during deserialization on the engineer. This document specifies a set of norms and practices for CBOR codec implementors intended to support deterministic CBOR ("dCBOR") at the codec API level. | ||||||||||||||||
| draft-mcnally-envelope-01.txt | |||||||||||||||||
| The Envelope Structured Data Format | |||||||||||||||||
|
The envelope protocol specifies a structured format for hierarchical binary data focused on the ability to transmit it in a privacy- focused way. Envelopes are designed to facilitate "smart documents" and have a number of unique features including: easy representation of a variety of semantic structures, a built-in Merkle-like digest tree, deterministic representation using CBOR, and the ability for the holder of a document to selectively encrypt or elide specific parts of a document without invalidating the document structure including the digest tree, or any cryptographic signatures that rely on it. | ||||||||||||||||
| draft-mcquistin-augmented-ascii-diagrams-12.txt | |||||||||||||||||
| Describing Protocol Data Units with Augmented Packet Header Diagrams | |||||||||||||||||
|
This document describes a machine-readable format for specifying the syntax of protocol data units within a protocol specification. This format is comprised of a consistently formatted packet header diagram, followed by structured explanatory text. It is designed to maintain human readability while enabling support for automated parser generation from the specification document. This document is itself an example of how the format can be used. | ||||||||||||||||
| draft-melnikov-iana-reg-cd-encapsulated-00.txt | |||||||||||||||||
| IANA Registration of Content-Disposition Header Field value 'encapsulated' | |||||||||||||||||
|
This document defines a new Content-Disposition header field value "encapsulated" to be used with "message/rfc822" and "message/global" media types. Content-Disposition "encapsulated" signals that enclosed message should be presented inline, instead of being presented as a forwarded message. One use case for this is for S/ MIME header protection. | ||||||||||||||||
| draft-melnikov-sasl2-00.txt | |||||||||||||||||
| Extensible Simple Authentication and Security Layer (SASL) | |||||||||||||||||
|
The Simple Authentication and Security Layer (SASL) is a framework for providing authentication and data security services in connection-oriented protocols via replaceable mechanisms. It provides a structured interface between protocols and mechanisms. The resulting framework allows new protocols to reuse existing mechanisms and allows old protocols to make use of new mechanisms. The framework also provides a protocol for securing subsequent protocol exchanges within a data security layer. This document describes how a SASL mechanism is structured, describes how protocols include support for SASL, and defines the protocol for carrying a data security layer over a connection. This document also defines how servers can request fulfillment of extra authentication related tasks, such as two factor authentication and/or password change. | ||||||||||||||||
| draft-melnikov-scram-bis-02.txt | |||||||||||||||||
| Salted Challenge Response Authentication Mechanism (SCRAM) SASL and GSS-API Mechanisms | |||||||||||||||||
|
This document updates requirements on implementations of various Salted Challenge Response Authentication Mechanism (SCRAM) Simple Authentication and Security Layer (SASL) mechanisms based on more modern security practices. | ||||||||||||||||
| draft-melnikov-scram-sha-512-03.txt | |||||||||||||||||
| SCRAM-SHA-512 and SCRAM-SHA-512-PLUS Simple Authentication and Security Layer (SASL) Mechanisms | |||||||||||||||||
|
This document registers the Simple Authentication and Security Layer (SASL) mechanisms SCRAM-SHA-512 and SCRAM-SHA-512-PLUS. | ||||||||||||||||
| draft-melnikov-smime-msa-to-mda-04.txt | |||||||||||||||||
| Domain-based signing and encryption using S/MIME | |||||||||||||||||
|
The S/MIME protocols Message Specification (RFC 5751), Cryptographic Message Syntax (RFC 5652), S/MIME Certificate Handling (RFC 5750) and Enhanced Security Services for S/MIME (RFC 2634) specify a consistent way to securely send and receive MIME messages providing end to end integrity, authentication, non-repudiation and confidentiality. This document identifies a number of interoperability, technical, procedural and policy related issues that may result in end-to-end security services not being achievable. To resolve such issues, this document profiles domain-based signing and encryption using S/MIME, such as specifying how S/MIME signing and encryption can be applied between a Message Submission Agent (MSA) and a Message Delivery Agent (MDA) or between 2 Message Transfer Agents (MTA). This document is also registering 2 URI scheme: "smtp" and "submit" which are used for designating SMTP/SMTP Submission servers (respectively), as well as SMTP/Submission client accounts. | ||||||||||||||||
| draft-meng-tsvwg-service-agnostic-dscp-00.txt | |||||||||||||||||
| A Service-Agnostic Semantics for Differentiated Services Code Point (DSCP) | |||||||||||||||||
|
This memo proposes a service-agnostic semantics for Differentiated Services Code Point (DSCP). It disassociates DSCP from classification of service classes. Instead, individual packets are marked dynamically in a Quality-of-Experience (QoE)-aware manner. Such a more flexible use of Differentiated Services (DiffServ) involves interactions with transport protocols on application hosts. Meanwhile, the semantics adds no complexity to traffic conditioning and Per-Hop-Behavior (PHB) enforcement within DiffServ network domain. | ||||||||||||||||
| draft-menon-svr-03.txt | |||||||||||||||||
| Secure Vector Routing (SVR) | |||||||||||||||||
|
This document describes Secure Vector Routing (SVR). SVR is an overlay inter-networking protocol that operates at the session layer. SVR provides end-to-end communication of network requirements not possible or practical using network header layers. SVR uses application layer cookies that eliminate the need to create and maintain non-overlapping address spaces necessary to manage network routing requirements. SVR is an overlay networking protocol that works through middleboxes and address translators including those existing between private networks, the IPv4 public internet, and the IPv6 public internet. SVR enables SD-WAN and multi-cloud use cases and improves security at the networking routing plane. SVR eliminates the need for encapsulation and decapsulation often used to create non-overlapping address spaces. | ||||||||||||||||
| draft-meuric-ccamp-tsvmode-signaling-03.txt | |||||||||||||||||
| Conveying Transceiver-Related Information within RSVP-TE Signaling | |||||||||||||||||
|
The ReSource Reservation Protocol with Traffic Engineering extensions (RSVP-TE) allows to carry optical information so as to set up channels over Wavelength Division Multiplexing (WDM) networks between a pair of transceivers. Nowadays, there are many transceivers that not only support tunable lasers, but also multiple modulation formats. This memo leverages the Generalized Multiprotocol Label Switching protocol extensions to support the signaling of the associated information as a "mode" parameter within a "transceiver type" context. | ||||||||||||||||
| draft-mglt-ipsecme-multiple-child-sa-01.txt | |||||||||||||||||
| Negotiation of multiple Child Security Association with the Internet Key Exchange Protocol Version 2 (IKEv2) | |||||||||||||||||
|
IPsec packet processing with one Security Association (SA) per core is more efficient than having a SA shared by the multiple cores. This document optimizes the negotiation of multiple unidirectional SAs so that each peer can assign one unidirectional SA per core. | ||||||||||||||||
| draft-mglt-ipsecme-ts-dscp-02.txt | |||||||||||||||||
| Traffic Selector for Internet Key Exchange version 2 to add support Differentiated Services Field Codepoints (DSCP) | |||||||||||||||||
|
This document defines a new Traffic Selector for Internet Key Exchange version 2 to add support Differentiated Services Field Codepoints (DSCP) as a traffic selector of the Security Policy Database (SPD). The new Traffic Selector type TS_DSCP consists of DSCP values associated to the negotiated SA. | ||||||||||||||||
| draft-mhkk-dmm-srv6mup-architecture-05.txt | |||||||||||||||||
| Mobile User Plane Architecture using Segment Routing for Distributed Mobility Management | |||||||||||||||||
|
This document defines the Mobile User Plane (MUP) architecture using Segment Routing (SR) for Distributed Mobility Management. The requirements for Distributed Mobility Management described in [RFC7333] can be satisfied by routing fashion. Mobile services are deployed over several parts of IP networks. An SR network can accommodate a part of those networks, or all those networks. IPv6 dataplane option (SRv6) is suitable for both cases especially for the latter case thanks to the large address space, so this document illustrates the MUP deployment cases with IPv6 dataplane. MUP Architecture can incorporate existing session based mobile networks. By leveraging Segment Routing, mobile user plane can be integrated into the dataplane. In that routing paradigm, session information between the entities of the mobile user plane is turned to routing information. | ||||||||||||||||
| draft-miao-tsv-hpcc-01.txt | |||||||||||||||||
| HPCC++: Enhanced High Precision Congestion Control | |||||||||||||||||
|
Congestion control (CC) is the key to achieving ultra-low latency, high bandwidth and network stability in high-speed networks. However, the existing high-speed CC schemes have inherent limitations for reaching these goals. In this document, we describe HPCC++ (High Precision Congestion Control), a new high-speed CC mechanism which achieves the three goals simultaneously. HPCC++ leverages inband telemetry to obtain precise link load information and controls traffic precisely. By addressing challenges such as delayed signaling during congestion and overreaction to the congestion signaling using inband and granular telemetry, HPCC++ can quickly converge to utilize all the available bandwidth while avoiding congestion, and can maintain near-zero in- network queues for ultra-low latency. HPCC++ is also fair and easy to deploy in hardware, implementable with commodity NICs and switches. | ||||||||||||||||
| draft-miao-tsv-hpcc-info-01.txt | |||||||||||||||||
| Inband Telemetry for HPCC++ | |||||||||||||||||
|
Congestion control (CC) is the key to achieving ultra-low latency, high bandwidth and network stability in high-speed networks. However, the existing high-speed CC schemes have inherent limitations for reaching these goals. In this document, we describe HPCC++ (High Precision Congestion Control), a new high-speed CC mechanism which achieves the three goals simultaneously. HPCC++ leverages inband telemetry to obtain precise link load information and controls traffic precisely. By addressing challenges such as delayed signaling during congestion and overreaction to the congestion signaling using inband and granular telemetry, HPCC++ can quickly converge to utilize all the available bandwidth while avoiding congestion, and can maintain near-zero in- network queues for ultra-low latency. HPCC++ is also fair and easy to deploy in hardware, implementable with commodity NICs and switches. | ||||||||||||||||
| draft-michel-quic-fec-00.txt | |||||||||||||||||
| Forward Erasure Correction for QUIC loss recovery | |||||||||||||||||
|
This documents lays down the QUIC protocol design considerations needed for QUIC to apply Forward Erasure Correction on the data sent through the network. | ||||||||||||||||
| draft-mirsky-bfd-mpls-demand-13.txt | |||||||||||||||||
| BFD in Demand Mode over a Point-to-Point MPLS LSP | |||||||||||||||||
|
This document describes procedures for using Bidirectional Forwarding Detection (BFD) in Demand mode to detect data plane failures in Multiprotocol Label Switching (MPLS) point-to-point Label Switched Paths. | ||||||||||||||||
| draft-mirsky-ippm-hybrid-two-step-14.txt | |||||||||||||||||
| Hybrid Two-Step Performance Measurement Method | |||||||||||||||||
|
Development of, and advancements in, automation of network operations brought new requirements for measurement methodology. Among them is the ability to collect instant network state as the packet being processed by the networking elements along its path through the domain. This document introduces a new hybrid measurement method, referred to as hybrid two-step, as it separates the act of measuring and/or calculating the performance metric from the act of collecting and transporting network state. | ||||||||||||||||
| draft-mirsky-mpls-bfd-bootstrap-clarify-03.txt | |||||||||||||||||
| Clarifying Use of LSP Ping to Bootstrap BFD over MPLS LSP | |||||||||||||||||
|
This document, if approved, updates RFC 5884 by clarifying procedures for using MPLS LSP ping to bootstrap Bidirectional Forwarding Detection (BFD) over MPLS Label Switch Path. | ||||||||||||||||
| draft-mirsky-mpls-stamp-05.txt | |||||||||||||||||
| Simple Two-way Active Measurement Protocol (STAMP) for MPLS Label Switched Paths (LSPs) | |||||||||||||||||
|
Simple Two-way Active Measurement Protocol (STAMP), defined in RFC 8762 and RFC 8972, is expected to be able to monitor the performance of paths between systems that use a wide variety of encapsulations. This document defines encapsulation and bootstrapping of a STAMP test session over an MPLS Label Switched Path. | ||||||||||||||||
| draft-misell-acme-onion-01.txt | |||||||||||||||||
| Automated Certificate Management Environment (ACME) Extensions for ".onion" Domain Names | |||||||||||||||||
|
The documents defines extensions to the Automated Certificate Management Environment (ACME) to allow for the automatic issuance of certificates to Tor hidden services (".onion" domains). Discussion This note is to be removed before publishing as an RFC. Source for this draft and an issue tracker can be found at https://github.com/AS207960/acme-onion. The project website and a reference implementation can be found at https://acmeforonions.org. | ||||||||||||||||
| draft-mishra-6man-variable-slaac-07.txt | |||||||||||||||||
| SLAAC with prefixes of arbitrary length in PIO (Variable SLAAC) | |||||||||||||||||
|
This draft proposes the use of arbitrary length prefixes in PIO for SLAAC. A prefix of length 63 in PIO, for example, would be permitted to form an address whose interface identifier length is 65, which allows several benefits. A prefix of length 65 would be allowed too, but it SHOULD NOT be used on a large scale, like at a large ISP; this is to avoid a race to the bottom. The implementation uses a parameter in the Host; this option is off by default. In that case, the Host respects the 64bit boundary. When the parameter is set to on the Host accepts prefixes of lengths different than 64 and forms 128bit addresses. In the past, various IPv6 addressing models have been proposed based on a subnet hierarchy embedding a 64-bit prefix. The last remnant of IPv6 classful addressing is a inflexible interface identifier boundary at /64. This document proposes flexibility to the fixed position of that boundary for interface addressing. | ||||||||||||||||
| draft-mishra-bess-ipv4-only-pe-design-all-safi-03.txt | |||||||||||||||||
| IPv4-Only PE Design All SAFI | |||||||||||||||||
|
As Enterprises and Service Providers try to decide whether or not to upgrade their brown field or green field MPLS/SR core to an IPv6 transport, Multiprotocol BGP (MP-BGP)now plays an important role in the transition of their Provider (P) core network as well as Provider Edge (PE) Edge network from IPv4 to IPv6. Operators must be able to continue to support IPv4 customers when both the Core and Edge networks are IPv4-Only. This specification details an important External BGP (eBGP) PE-CE Edge IPv4-Only peering design that leverages the MP-BGP capability exchange by using IPv4 peering as pure transport, allowing both IPv4 Network Layer Reachability Information (NLRI) and IPv6 Network Layer Reachability Information (NLRI)to be carried over the same (Border Gateway Protocol) BGP TCP session. The design change provides the same Dual Stacking functionality that exists today with separate IPv4 and IPv6 BGP sessions as we have today. With this design change from a control plane perspective a single IPv4 is required for both IPv4 and IPv6 routing updates and from a data plane forwarindg perspective an IPv4 address need only be configured on the PE and CE interface for both IPv4 and IPv6 packet forwarding. This specification provides a IPv4-Only PE design solution for use cases where operators are not yet ready to migrate to IPv6 or SRv6 core and would like to stay on IPv4-Only Core short to long term and maybe even indefinitely. With this design, operators can now remain with an IPv4-Only Core and do not have to migrate to an IPv6-Only Core. From a technical standpoint the underlay can remain IPv4 and still transport IPv6 NLRI to support IPv6 customers, and so does not need to be migrated to IPv6-Only underlay. With this IPv4-Only PE Design solution , IPv4 addressing only needs to be provisioned for the IPv4-Only PE-CE eBGP Edge peering design, thereby eliminating IPv6 provisioning at the Edge. This core and edge IPv4-Only peering design can apply to any eBGP peering, public internet or private, which can be either Core networks, Data Center networks, Access networks or can be any eBGP peering scenario. This document provides a IPv4-Only PE design solution for use cases where operators are not yet ready to migrate to IPv6 or SRv6 core and would like to stay on IPv4-Only Core short to long term and maybe even indefinitely. With this design, operators can now remain with an IPv4-Only Core and do not have to migrate to an IPv6-Only Core. From a technical standpoint the underlay can remain IPv4 and still transport IPv6 NLRI to support IPv6 customers, and so does not need to be migrated to IPv6-Only underlay. With this IPv4-Only PE Design solution , IPv4 addressing only needs to be provisioned for the IPv4-Only PE-CE eBGP Edge peering design, thereby eliminating IPv6 provisioning at the Edge. This core and edge IPv4-Only peering design can apply to any eBGP peering, public internet or private, which can be either Core networks, Data Center networks, Access networks or can be any eBGP peering scenario. This document provides vendor specific test cases for the IPv4-Only peering design as well as test results for the five major vendors stakeholders in the routing and switching indusrty, Cisco, Juniper, Arista, Nokia and Huawei. With the test results provided for the IPv4-Only Edge peering design, the goal is that all other vendors around the world that have not been tested will begin to adopt and implement this new Best Current Practice for eBGP IPv4-Only Edge peering. This Best Current Practice IPv4-only eBGP peering design specification will help in use cases where operators are not yet ready to migrate to IPv6 or SRv6 core or for very lage operator core with thousdands of nodes where it maybe impractical to change the underlay infrastructure to IPv6, and can now keep the existing IPv4 data plane IP, MPLS or SR-MPLS underlay intact indefinitely. This document also defines a new IPv4 next hop encoding for IPv6 NLRI over IPv4 Next Hop to uses 4 byte IPv4 address for the next hop and not a IPv4 mapped IPv6 address. This encoding has been adopted by the industry but has not been standardized until now with this document. This document details an important External BGP (eBGP) PE-PE Inter-AS IPv6-Only peering design that leverages the MP-BGP capability exchange by using IPv6 peering as pure transport, allowing all and any IPv4 Network Layer Reachability Information (NLRI) and IPv6 Network Layer Reachability Information (NLRI)to be carried over the same (Border Gateway Protocol) BGP TCP session for all Address Family Identifiers (AFI) and Subsequent Address Family Identifiers(SAFI). The design change provides the same Dual Stacking functionality that exists today with separate IPv4 and IPv6 BGP sessions as we have today. With this IPv4-Only PE Design, IPv6 address MUST not be configured on the the Provider Edge (PE) - Customer Edge (CE), or Inter-AS ASBR (Autonomous System Boundary Router) to ASBR (Autonomous System Boundary Router) PE-PE Provider Edge (PE) - Provider Edge (PE). From a control plane perspective a single IPv4-Only peer is required for both IPv4 and IPv6 routing updates and from a data plane forwarindg perspective an IPv4 address need only be configured on the PE to PE Inter-AS peering interface for both IPv4 and IPv6 packet forwarding. This document defines the IPv4-Only PE Design as a new PE-CE Edge and ASBR-ASBR PE-PE Inter-AS BGP peering Standard defined in this specification which is now extended to support to all AFI/ SAFI ubiquitously. As service providers migrate to Segment Routing architecture SR-MPLS and SRv6, VPN overlay exsits as well, and thus Inter-AS options Option-A, Option-B, Option-AB and Option-C are still applicable and thus this extension of IPv4-Only peering architecure extension to Inter-AS peering is very relevant to Segment Routing as well. | ||||||||||||||||
| draft-mishra-idr-v4-islands-v6-core-4pe-04.txt | |||||||||||||||||
| Connecting IPv4 Islands over IPv6 Core using IPv4 Provider Edge Routers (4PE) | |||||||||||||||||
|
As operators migrate from an IPv4 core to an IPv6 core for global table internet routing, the need arises to be able provide routing connectivity for customers IPv4 only networks. This document provides a solution called 4Provider Edge, "4PE" that connects IPv4 islands over an IPv6-Only Core Underlay Network. | ||||||||||||||||
| draft-mishra-v6ops-variable-slaac-problem-stmt-05.txt | |||||||||||||||||
| SLAAC with prefixes of arbitrary length in PIO (Variable SLAAC) - A Problem Statement | |||||||||||||||||
|
In the past, various IPv6 addressing models have been proposed based on a subnet hierarchy embedding a 64-bit prefix. The last remnant of IPv6 classful addressing is a inflexible interface identifier boundary at /64. This document details the 64-bit boundary problem statement. | ||||||||||||||||
| draft-mlichvar-ntp-ntpv5-07.txt | |||||||||||||||||
| Network Time Protocol Version 5 | |||||||||||||||||
|
This document describes the version 5 of the Network Time Protocol (NTP). | ||||||||||||||||
| draft-mlichvar-ntp-over-ptp-03.txt | |||||||||||||||||
| NTP Over PTP | |||||||||||||||||
|
This document specifies a transport for the Network Time Protocol (NTP) client-server mode using the Precision Time Protocol (PTP) to enable hardware timestamping on hardware that can timestamp PTP messages but not NTP messages. | ||||||||||||||||
| draft-mmm-rtgwg-integrated-oam-02.txt | |||||||||||||||||
| Integrated Operation,Administration,and Maintenance | |||||||||||||||||
|
This document describes the Integrated Operation, Administration, and Maintenance (IntOAM) protocol. IntOAM is based on the lightweight capabilities of Bidirectional Forwarding Detection defined in RFC 5880 Bidirectional Forwarding Detection, and the RFC 6374 Packet Loss and Delay Measurement for MPLS Networks to measure performance metrics like packet loss and packet delay. Also, a method to perform lightweight on-demand authentication is defined in this specification. | ||||||||||||||||
| draft-mohanty-idr-rtc-hierarchical-rr-00.txt | |||||||||||||||||
| A solution to the Hierarchical Route Reflector issue in RT Constraints | |||||||||||||||||
|
Route Target Constraints (RTC) is used to build a VPN route distribution graph such that routers only receive VPN routes corresponding to specified route-targets (RT) that they are interested in. This is done by exchanging the route-targets as routes in the RTC address-family and a corresponding "RT filter" is installed that influences the VPN route advertisement. In networks employing hierarchical Route Reflectors (RR) the use of RTC can lead to incorrect VPN route distribution and loss in connectivity as detailed in an earlier draft . Two solutions were provided to overcome the problem. This draft presents a method with suggested modifications to the RTC RFC in order to solve the hierarchical RR RTC problem in an efficient manner. | ||||||||||||||||
| draft-momoka-httpbis-settings-enable-websockets-02.txt | |||||||||||||||||
| SETTINGS_ENABLE_WEBSOCKETS settings parameter for HTTP/2 and HTTP/3 | |||||||||||||||||
|
This document proposes a new HTTP settings parameter, SETTINGS_ENABLE_WEBSOCKETS. This parameter indicates whether the server supports bootstrapping WebSockets over the established connection. | ||||||||||||||||
| draft-momoka-v6ops-ipv6-only-resolver-01.txt | |||||||||||||||||
| IPv6 only capable resolver utilising NAT64 | |||||||||||||||||
|
By performing IPv4 to IPv6 translation, IPv6-only iterative resolvers can operate in an IPv6-only environment. When a specific DNS zone is only served by an IPv4-only authoritative server, the iterative resolver will translate the IPv4 address to IPv6 to access the authoritative server's IPv4 address via stateful NAT64. This mechanism allows IPv6-only iterative resolvers to initiate communications to IPv4-only authoritative servers. | ||||||||||||||||
| draft-moran-iot-nets-02.txt | |||||||||||||||||
| A summary of security-enabling technologies for IoT devices | |||||||||||||||||
|
The IETF has developed security technologies that help to secure the Internet of Things even over constrained networks and when targetting constrained nodes. These technologies can be used independenly or can be composed into larger systems to mitigate a variety of threats. This documents illustrates an overview over these technologies and highlights their relationships. Ultimately, a threat model is presented as a basis to derive requirements that interconnect existing and emerging solution technologies. | ||||||||||||||||
| draft-morand-http-digest-2g-aka-05.txt | |||||||||||||||||
| Hypertext Transfer Protocol (HTTP) Digest Authentication Using GSM 2G Authentication and Key Agreement (AKA) | |||||||||||||||||
|
This document specifies a one-time password generation mechanism for Hypertext Transfer Protocol (HTTP) Digest access authentication based on Global System for Mobile Communications (GSM) authentication and key generation functions A3 and A8, also known as GSM AKA or 2G AKA. The HTTP Authentication Framework includes two authentication schemes: Basic and Digest. Both schemes employ a shared secret based mechanism for access authentication. The GSM AKA mechanism performs user authentication and session key distribution in GSM and Universal Mobile Telecommunications System (UMTS) networks. GSM AKA is a challenge-response based mechanism that uses symmetric cryptography. | ||||||||||||||||
| draft-moriarty-yangsecuritytext-02.txt | |||||||||||||||||
| Security Considerations Template for YANG Module Documents | |||||||||||||||||
|
This document includes the template text agreed upon by the Operations Area and Security Area for inclusion in YANG documents. The best practices are updated as needed and will result in updates to this template for use to provide a consistent set of security considerations for authors, developers, and implementors. | ||||||||||||||||
| draft-moskowitz-drip-a2x-adhoc-session-01.txt | |||||||||||||||||
| Aircraft to Anything AdHoc Broadcasts and Session | |||||||||||||||||
|
Aircraft-to-anything (A2X) communications are often single broadcast messages that need to be signed with expensive (in cpu and payload size) asymmetric cryptography. There are also frequent cases of extended exchanges between two devices where a lower cost symmetric key protect flow can be used. This document shows both how to secure A2X broadcast messages with DRIP DET and Endorsement objects and to leverage these to create an AdHoc session key for just such a communication flow. | ||||||||||||||||
| draft-moskowitz-drip-crowd-sourced-rid-09.txt | |||||||||||||||||
| Crowd Sourced Remote ID | |||||||||||||||||
|
This document describes using the ASTM Broadcast Remote ID (B-RID) specification in a "crowd sourced" smart phone or fixed receiver asset environment to provide much of the ASTM and FAA envisioned Network Remote ID (Net-RID) functionality. This crowd sourced B-RID (CS-RID) data will use multilateration to add a level of reliability in the location data on the Unmanned Aircraft (UA). The crowd sourced environment will also provide a monitoring coverage map to authorized observers. | ||||||||||||||||
| draft-moskowitz-drip-efficient-a2g-comm-00.txt | |||||||||||||||||
| Efficient Air-Ground Communications | |||||||||||||||||
|
This document defines protocols to provide efficient air-ground communications without associated need for aircraft to maintain stateful connection to ground-tower infrastructure. Instead, a secure source-routed ground infrastructure will not only provide the needed routing intelligence, but also reliable packet delivery through inclusion of Automatic Repeat reQuest (ARQ) and Forward Error Correction (FEC) to address both reliable wireless packet delivery, and assured terrestrial packet delivery. | ||||||||||||||||
| draft-moskowitz-drip-operator-privacy-11.txt | |||||||||||||||||
| UAS Operator Privacy for RemoteID Messages | |||||||||||||||||
|
This document describes a method of providing privacy for UAS Operator/Pilot information specified in the ASTM UAS Remote ID and Tracking messages. This is achieved by encrypting, in place, those fields containing Operator sensitive data using a hybrid ECIES. | ||||||||||||||||
| draft-moskowitz-drip-secure-nrid-c2-12.txt | |||||||||||||||||
| Secure UAS Network RID and C2 Transport | |||||||||||||||||
|
This document defines a transport mechanism for Unmanned Aircraft System (UAS) Network Remote ID (Net-RID). Either the Broadcast Remote ID (B-RID) messages, or alternatively, appropriate MAVLink Messages can be sent directly over UDP or via a more functional protocol using CoAP/CBOR for the Net-RID messaging. This is secured via either HIP/ESP or DTLS. HIP/ESP or DTLS secure messaging Command-and-Control (C2) for is also described. | ||||||||||||||||
| draft-moskowitz-hip-fast-mobility-05.txt | |||||||||||||||||
| Fast HIP Host Mobility | |||||||||||||||||
|
This document describes mobility scenarios and how to aggressively support them in HIP. The goal is minimum lag in the mobility event. | ||||||||||||||||
| draft-mpmz-bess-mup-safi-02.txt | |||||||||||||||||
| BGP Extensions for the Mobile User Plane (MUP) SAFI | |||||||||||||||||
|
This document defines a new SAFI known as a BGP Mobile User Plane (BGP-MUP) SAFI to support MUP Extensions and a extended community for BGP. This document also provides BGP signaling and procedures for the new SAFI to convert mobile session information into appropriate IP forwarding information. These extensions can be used by operators between a PE, and a Controller for integrating mobile user plane into BGP MUP network using the IP based routing. | ||||||||||||||||
| draft-mrossberg-ipsecme-multiple-sequence-counters-00.txt | |||||||||||||||||
| Problem statements and uses cases for lightweight Child Security Associations | |||||||||||||||||
|
IKE SAs may have one or more child SAs that are used for traffic protection. This document collects arguments for (and against) having more fine-grained sub-child-SAs. They can be used to separate data streams for various technical reasons but share the same security properties and traffic selectors. This shall allow for a more flexible use of IPsec in multiple scenarios. | ||||||||||||||||
| draft-multiformats-multibase-07.txt | |||||||||||||||||
| The Multibase Data Format | |||||||||||||||||
|
Raw binary data is often encoded using a mechanism that enables the data to be included in human-readable text-based formats. This mechanism is often referred to as "base-encoding the data". Base- encoding is often used when expressing binary data in hyperlinks, cryptographic keys in web pages, or security tokens in application software. There are a variety of base-encodings, such as base32, base58, and base64. It is not always possible to differentiate one base-encoding from another. The purpose of this specification is to provide a mechanism to be able to deterministically identify the base-encoding for a particular string of data. | ||||||||||||||||
| draft-multiformats-multihash-06.txt | |||||||||||||||||
| The Multihash Data Format | |||||||||||||||||
|
Cryptographic hash functions often have multiple output sizes and encodings. This variability makes it difficult for applications to examine a series of bytes and determine which hash function produced them. Multihash is a universal data format for encoding outputs from hash functions. It is useful to write applications that can simultaneously support different hash function outputs as well as upgrade their use of hashes over time; Multihash is intended to address these needs. | ||||||||||||||||
| draft-multiple-layer-resource-optimization-08.txt | |||||||||||||||||
| Multiple Layer Resource Optimization for Optical as a Service | |||||||||||||||||
|
We have established a neural network model optimized by adaptive artificial fish swarm algorithm. Then we propose a novel multi-path pre-reserved resource allocation strategy to increase resource utilization. The results prove the effectiveness of our method. | ||||||||||||||||
| draft-murchison-imap-esearch-return-opt-registry-00.txt | |||||||||||||||||
| IANA Registry for IMAP Extended SEARCH Return Options and Data Tags | |||||||||||||||||
|
This document creates a registry of IMAP Extended Search Return Options and Data Tags (RFC 4466) in order to help developers and IMAP extension writers track interactions between different extensions. Open Issues * Is Expert Review the correct registration policy? * Should we also add a registry of SEARCH criteria? | ||||||||||||||||
| draft-murchison-imap-list-metadata-01.txt | |||||||||||||||||
| IMAP4 Extension for Returning Mailbox METADATA in Extended LIST | |||||||||||||||||
|
This document defines an extension to the to IMAP LIST command that allows the client to request mailbox annotations (metadata), along with other information typically returned by the LIST command. | ||||||||||||||||
| draft-murchison-rfc8536bis-07.txt | |||||||||||||||||
| The Time Zone Information Format (TZif) | |||||||||||||||||
|
This document specifies the Time Zone Information Format (TZif) for representing and exchanging time zone information, independent of any particular service or protocol. Two media types for this format are also defined. This document replaces and obsoletes RFC 8536. | ||||||||||||||||
| draft-murillo-whep-02.txt | |||||||||||||||||
| WebRTC-HTTP Egress Protocol (WHEP) | |||||||||||||||||
|
This document describes a simple HTTP-based protocol that will allow WebRTC-based viewers to watch content from streaming services and/or Content Delivery Networks (CDNs) or WebRTC Transmission Network (WTNs). | ||||||||||||||||
| draft-mvmd-opsawg-ipfix-fwd-exceptions-07.txt | |||||||||||||||||
| IP Flow Information Export (IPFIX) Information Elements Extension for Forwarding Exceptions | |||||||||||||||||
|
This draft proposes couple of new Forwarding exceptions related Information Elements (IEs) and Templates for the IP Flow Information Export (IPFIX) protocol. These new Information Elements and Exception Template can be used to export information about any forwarding errors in a network. This essential information is adequate to correlate packet drops to any control plane entity and map it to an impacted service. Once exceptions are correlated to a particular entity, an action can be assigned to mitigate such problems essentially enabling self-driving networks. | ||||||||||||||||
| draft-mzanaty-moq-loc-00.txt | |||||||||||||||||
| Low Overhead Media Container | |||||||||||||||||
|
This specification describes a media container format for encoded and encrypted audio and video media data to be used for interactive media usecases, with the goal of it being a low overhead format. | ||||||||||||||||
| draft-mzbc-ippm-transit-measurement-option-01.txt | |||||||||||||||||
| The Transit Measurement Option | |||||||||||||||||
|
This document specifies an IPv6 option that contains a compact set of fields which can be used for transit delay measurement and congestion detection. This option can be incorporated into data packets and updated by transit nodes along the path, enabling lightweight measurement and monitoring using constant-length data that does not depend on the number of hops in the network. | ||||||||||||||||
| draft-mzhang-nfsv4-sequence-id-calibration-02.txt | |||||||||||||||||
| Sequence ID calibration for mis-ordered requests | |||||||||||||||||
|
This document updates RFC8881, Network File System (NFS) version 4 minor version 1, by adding two operations to prevent the client from destroying session when getting the reply of a mis-ordered request with NFS4ERR_SEQ_MISORDERED. In NFSv4 minor version 1, sequence ID is used to ensure that the size of the needed reply cache is tightly bounded. If the server gets a mis-ordered request, the client will often break the session and establish a new session with the server. This approach results in a significant burden on the client and the server. During the process of session rebuilding, IO performance will be affected. This is especially troublesome when network latency is substantial, as, for example when client and server are in different locations. This document will propose extensions to NFSv4 that would allow client reconnection to be dispensed with. | ||||||||||||||||
| draft-nagaraj-bess-evpn-redundant-mcast-src-update-00.txt | |||||||||||||||||
| Enhancements to Multicast Source Redundancy in EVPN Networks | |||||||||||||||||
|
draft-ietf-bess-evpn-redundant-mcast-source specifies Warm Standby (WS) and Hot Standby (HS) procedures for handling redundant multicast traffic into an EVPN tenant domain. With the Hot Standby procedure, multiple ingress PEs may inject traffic and an egress PE will decide from which ingress PE traffic will be accepted and forwarded. The decision is based on certain signaling messages and/or BFD status of provider tunnels from the ingress PEs, and the traffic is associated with ingress PEs based on Ethernet Segment Identifier (ESI) labels. As a result, the procedures in that document only apply to MPLS data plane. This document extends the Hot Standby procedures to non-MPLS data planes and EVPN Data Center Interconnect scenarios. | ||||||||||||||||
| draft-nainar-mpls-lsp-ping-yang-04.txt | |||||||||||||||||
| YANG Data Model for MPLS LSP Ping | |||||||||||||||||
|
This document describes the YANG data model for Multi-Protocol Label Switching (MPLS) LSP Ping. The model is based on YANG 1.1 as defined in RFC 7950 and conforms to the Network Management Datastore Architecture (NMDA) as described in RFC 8342. | ||||||||||||||||
| draft-nakano-rocca-s-03.txt | |||||||||||||||||
| Encryption algorithm Rocca-S | |||||||||||||||||
|
This document defines Rocca-S encryption scheme, which is an Authenticated Encryption with Associated Data (AEAD), using a 256-bit key and can be efficiently implemented utilizing the AES New Instruction set (AES-NI). | ||||||||||||||||
| draft-nandakumar-mimi-transport-00.txt | |||||||||||||||||
| Cached and Async meSsage Transport (CAST) | |||||||||||||||||
|
This specification defines message transport, called CAST, based on publish/subscribe semantics for interoperable inter-server messaging that is rooted in modern, cloud friendly and scalable architectural underpinnings. | ||||||||||||||||
| draft-nandakumar-moq-arch-00.txt | |||||||||||||||||
| Media Over QUIC Media and Security Architecture | |||||||||||||||||
|
This document defines the media and security architecture for Media Over QUIC, a protocol suite intended to run in browsers and other non-browser endpoints and support unified architecture and protocol for data delivery that enables a wide range of media applications with different resiliency and latency needs without compromising the scalability and cost effectiveness associated with content delivery networks. Note to readers: This document as it stands might not reflect accurately all decisions that are in active discussions in the WG, but it lays out a foundation for expected architectural requirements. The specification will be updated based on the decision made in the WG. | ||||||||||||||||
| draft-nandakumar-moq-scenarios-00.txt | |||||||||||||||||
| Exploration of MoQ scenarios and Data Model | |||||||||||||||||
|
This document delineates a set of key scenarios and details the requirements that they place on the MoQ data model. | ||||||||||||||||
| draft-nandakumar-moq-transport-00.txt | |||||||||||||||||
| MoQ Transport (moqt) - Unified Media Delivery Protocol over QUIC | |||||||||||||||||
|
This specification defined MoqTransport (moqt), an unified media delivery protocol over QUIC. It aims at supporting multiple application classes with varying latency requirements including ultra low latency applications such as interactive communication and gaming. It is based on a publish/subscribe metaphor where entities publish and subscribe to data that is sent through, and received from, relays in the cloud. The data is delivered in the strict priority order. The information subscribed to is named such that this forms an overlay information centric network. The relays allow for efficient large scale deployments. | ||||||||||||||||
| draft-nandy-pim-static-mcast-distribution-trees-00.txt | |||||||||||||||||
| Static Multicast Distribution Trees | |||||||||||||||||
|
This document specifies the Static Provision of Multicast route as an alternate to Layer 3 Multicast protocols like PIM-SM (Protocol Independent Multicast - Sparse Mode), PIM SSM (Source-Specific Multicast), or PIM BIDI (Bidirectional). It works like a standalone Multicast Route provisioning feature that can interoperate with other dynamic Multicast protocols like PIM-SM or with L2 protocols like IGMP (Internet Group Management Protocol) and MLD (Multicast Listener Discovery). This feature can function with/without the use of Unicast Routing Protocols to build the Multicast tree. | ||||||||||||||||
| draft-nichols-iotops-defined-trust-transport-01.txt | |||||||||||||||||
| Defined-Trust Transport (DeftT) Protocol for Limited Domains | |||||||||||||||||
|
This document describes a broadcast-friendly, many-to-many Defined- trust Transport (DeftT) that makes it simple to express and enforce application and deployment specific integrity, authentication, access control and behavior constraints directly in the protocol stack. DeftT is part of a Defined-trust Communications framework with an example codebase, not a protocol specification. Combined with IPv6 multicast and modern hardware-based methods for securing keys and code, it provides an easy to use foundation for secure and efficient communications in Limited Domains (RFC8799), in particular for Operational Technology (OT) networks. | ||||||||||||||||
| draft-nir-ipsecme-big-payload-01.txt | |||||||||||||||||
| A Larger Internet Key Exchange version 2 (IKEv2) Payload | |||||||||||||||||
|
The messages of the Internet Key Exchange version 2 (IKEv2) protocol are made up of payloads. The current protocol limits each of these payloads to 64KB by having a 2-byte length field. While this is usually enough, several of the payloads may need to be larger. This document defines an extension to IKEv2 that allows larger payloads. | ||||||||||||||||
| draft-nishida-tcpm-agg-syn-ext-03.txt | |||||||||||||||||
| Aggregated Option for SYN Option Space Extension | |||||||||||||||||
|
TCP option space is scarce resource as its maximum length is limited to 40 bytes. This limitation becomes more significant in SYN segments as all options used in a connection should be exchanged during SYN negotiations. This document proposes a new SYN option negotiation scheme that can aggregate multiple TCP options in SYN segments into a single option so that more options can be negotiate during 3-way handshake. With its simple design, the approach does not require fundamental changes in TCP. | ||||||||||||||||
| draft-nishida-tcpm-standard-cc-analysis-01.txt | |||||||||||||||||
| Analysis for the Differences Between Standard Congestion Control Schemes | |||||||||||||||||
|
Reno-based congestion control has been referred as the standard document from IETF for long time that describes congestion control principle of the Internet. In the meantime, IETF recently has published two new congestion control standards that use slightly different schemes from the previous one. This document provides analysis for the differences between these standards in order to provide helpful information when an unified congestion control principles for the Internet is standardized in the future. | ||||||||||||||||
| draft-nottingham-avoiding-internet-centralization-09.txt | |||||||||||||||||
| Internet Centralization: What Can Standards Do? | |||||||||||||||||
|
Despite the Internet being designed and operated as a decentralized network-of-networks, forces often (and increasingly) encourage consolidation of power over its functions into few hands. This document discusses centralization in Internet protocols and relates it to consolidation of power, explains why both are undesirable, identifies forces that contribute to them, catalogues limitations of common approaches to decentralization, and explores what Internet standards efforts can do. | ||||||||||||||||
| draft-nottingham-http-availability-hints-00.txt | |||||||||||||||||
| HTTP Availability Hints | |||||||||||||||||
|
This specification defines availability hints, a new class of HTTP responses headers that augment the information in the Vary header field. | ||||||||||||||||
| draft-nottingham-iesg-review-workload-00.txt | |||||||||||||||||
| IESG Document Review Expectations: Impact on AD Workload | |||||||||||||||||
|
Arguably, IETF Area Directors are overloaded with document review duties. This document surveys the relevant background, discusses the implications, and makes a proposal for improvements. | ||||||||||||||||
| draft-ogondio-lsr-isis-topology-00.txt | |||||||||||||||||
| A YANG Data Model for Intermediate System to intermediate System (ISIS) Topology | |||||||||||||||||
|
This document defines a YANG data model for representing an abstract view of the provider network topology that contains Intermediate System to intermediate System (ISIS) information. This document augments the 'ietf-network' data model by adding ISIS concepts. The YANG data model defined in this document conforms to the Network Management Datastore Architecture (NMDA). | ||||||||||||||||
| draft-olden-ippm-qoo-00.txt | |||||||||||||||||
| Quality of Outcome | |||||||||||||||||
|
This document describes a new network quality framework named Quality of Outcome (QoO). The QoO framework is unique among network quality frameworks in satisfying all the requirements layed out in "Requirements for a Network Quality Framework Useful for Applications, Users and Operators". The framework proposes a way of sampling network quality, setting network quality requirements and a formula for calculating the probability for the sampled network to satisfy network requirements. | ||||||||||||||||
| draft-oran-icnrg-flowbalance-08.txt | |||||||||||||||||
| Maintaining CCNx or NDN flow balance with highly variable data object sizes | |||||||||||||||||
|
Deeply embedded in some ICN architectures, especially Named Data Networking (NDN) and Content-Centric Networking (CCNx) is the notion of flow balance. This captures the idea that there is a one-to-one correspondence between requests for data, carried in Interest messages, and the responses with the requested data object, carried in Data messages. This has a number of highly beneficial properties for flow and congestion control in networks, as well as some desirable security properties. For example, neither legitimate users nor attackers are able to inject large amounts of un-requested data into the network. Existing congestion control approaches however have a difficult time dealing effectively with a widely varying MTU of ICN data messages, because the protocols allow a dynamic range of 1-64K bytes. Since Interest messages are used to allocate the reverse link bandwidth for returning Data, there is large uncertainty in how to allocate that bandwidth. Unfortunately, most current congestion control schemes in CCNx and NDN only count Interest messages and have no idea how much data is involved that could congest the inverse link. This document proposes a method to maintain flow balance by accommodating the wide dynamic range in Data message size. | ||||||||||||||||
| draft-oran-icnrg-reflexive-forwarding-05.txt | |||||||||||||||||
| Reflexive Forwarding for CCNx and NDN Protocols | |||||||||||||||||
|
Current Information-Centric Networking protocols such as CCNx and NDN have a wide range of useful applications in content retrieval and other scenarios that depend only on a robust two-way exchange in the form of a request and response (represented by an _Interest-Data exchange_ in the case of the two protocols noted above). A number of important applications however, require placing large amounts of data in the Interest message, and/or more than one two-way handshake. While these can be accomplished using independent Interest-Data exchanges by reversing the roles of consumer and producer, such approaches can be both clumsy for applications and problematic from a state management, congestion control, or security standpoint. This specification proposes a _Reflexive Forwarding_ extension to the CCNx and NDN protocol architectures that eliminates the problems inherent in using independent Interest-Data exchanges for such applications. It updates RFC8569 and RFC8609. | ||||||||||||||||
| draft-orr-wlan-security-architectures-00.txt | |||||||||||||||||
| Cryptographic Security Characteristics of 802.11 Wireless LAN Access Systems | |||||||||||||||||
|
This note identifies all of the places that cryptography is used in Wireless Local Area Network (WLAN) architectures, to simplify the task of selecting the protocols, algorithms, and key sizes needed to achieve a consistent security level across the entire architecture. | ||||||||||||||||
| draft-ounsworth-cfrg-kem-combiners-03.txt | |||||||||||||||||
| Combiner function for hybrid key encapsulation mechanisms (Hybrid KEMs) | |||||||||||||||||
|
The migration to post-quantum cryptography often calls for performing multiple key encapsulations in parallel and then combining their outputs to derive a single shared secret. This document defines a comprehensible and easy to implement Keccak- based KEM combiner to join an arbitrary number of key shares, that is compatible with NIST SP 800-56Cr2 [SP800-56C] when viewed as a key derivation function. The combiners defined here are practical multi- PRFs and are CCA-secure as long as at least one of the ingredient KEMs is. | ||||||||||||||||
| draft-ounsworth-pkix-key-attestation-02.txt | |||||||||||||||||
| PKIX Key Attestation Format | |||||||||||||||||
|
This document describes syntax for conveying key origin attestation information to a Certification Authority (CA) or other entity, so that they may decide how much trust to place in the management of the private key. For example, a reliant party may use this information to support a decision about whether to issue a certificate. In contrast to other key attestation formats, the one defined in this document requires only ASN.1 and the standard PKIX modules. | ||||||||||||||||
| draft-ounsworth-pq-composite-kem-01.txt | |||||||||||||||||
| Composite KEM For Use In Internet PKI | |||||||||||||||||
|
The migration to post-quantum cryptography is unique in the history of modern digital cryptography in that neither the old outgoing nor the new incoming algorithms are fully trusted to protect data for the required data lifetimes. The outgoing algorithms, such as RSA and elliptic curve, may fall to quantum cryptalanysis, while the incoming post-quantum algorithms face uncertainty about both the underlying mathematics as well as hardware and software implementations that have not had sufficient maturing time to rule out classical cryptanalytic attacks and implementation bugs. Cautious implementers may wish to layer cryptographic algorithms such that an attacker would need to break all of them in order to compromise the data being protected using either a Post-Quantum / Traditional Hybrid, Post-Quantum / Post-Quantum Hybrid, or combinations thereof. This document, and its companions, defines a specific instantiation of hybrid paradigm called "composite" where multiple cryptographic algorithms are combined to form a single key, signature, or key encapsulation mechanism (KEM) such that they can be treated as a single atomic object at the protocol level. This document defines the structure CompositeCiphertextValue which is a sequence of the respective ciphertexts for each component algorithm. Explicit pairings of algorithms are defined which should meet most Internet needs. The generic composite key type is also defined which allows arbitrary combinations of key types to be placed in the CompositePublicKey and CompositePrivateKey structures without needing the combination to be pre-registered or pre-agreed. For the purpose of combining KEMs, the combiner function from [I-D.ounsworth-cfrg-kem-combiners] is used. This document is intended to be coupled with the composite keys structure define in [I-D.ounsworth-pq-composite-keys] and the CMS KEMRecipientInfo mechanism in [I-D.housley-lamps-cms-kemri]. | ||||||||||||||||
| draft-ounsworth-pq-composite-keys-04.txt | |||||||||||||||||
| Composite Public and Private Keys For Use In Internet PKI | |||||||||||||||||
|
The migration to post-quantum cryptography is unique in the history of modern digital cryptography in that neither the old outgoing nor the new incoming algorithms are fully trusted to protect data for the required data lifetimes. The outgoing algorithms, such as RSA and elliptic curve, may fall to quantum cryptalanysis, while the incoming post-quantum algorithms face uncertainty about both the underlying mathematics as well as hardware and software implementations that have not had sufficient maturing time to rule out classical cryptanalytic attacks and implementation bugs. Cautious implementers may wish to layer cryptographic algorithms such that an attacker would need to break all of them in order to compromise the data being protected using either a Post-Quantum / Traditional Hybrid, Post-Quantum / Post-Quantum Hybrid, or combinations thereof. This document, and its companions, defines a specific instantiation of hybrid paradigm called "composite" where multiple cryptographic algorithms are combined to form a single key, signature, or key encapsulation mechanism (KEM) such that they can be treated as a single atomic object at the protocol level. This document defines the structures CompositePublicKey and CompositePrivateKey, which are sequences of the respective structure for each component algorithm. Explicit pairings of algorithms are defined which should meet most Internet needs. The generic composite key type is also defined which allows arbitrary combinations of key types to be placed in the CompositePublicKey and CompositePrivateKey structures without needing the combination to be pre-registered or pre-agreed. This document is intended to be coupled with corresponding documents that define the structure and semantics of composite signatures and encryption, such as [I-D.ounsworth-pq-composite-sigs] and [I-D.ounsworth-pq-composite-kem]. | ||||||||||||||||
| draft-ounsworth-pq-composite-sigs-08.txt | |||||||||||||||||
| Composite Signatures For Use In Internet PKI | |||||||||||||||||
|
The migration to post-quantum cryptography is unique in the history of modern digital cryptography in that neither the old outgoing nor the new incoming algorithms are fully trusted to protect data for the required data lifetimes. The outgoing algorithms, such as RSA and elliptic curve, may fall to quantum cryptanalysis, while the incoming post-quantum algorithms face uncertainty about both the underlying mathematics as well as hardware and software implementations that have not had sufficient maturing time to rule out classical cryptanalytic attacks and implementation bugs. Cautious implementers may wish to layer cryptographic algorithms such that an attacker would need to break all of them in order to compromise the data being protected using either a Post-Quantum / Traditional Hybrid, Post-Quantum / Post-Quantum Hybrid, or combinations thereof. This document, and its companions, defines a specific instantiation of hybrid paradigm called "composite" where multiple cryptographic algorithms are combined to form a single key, signature, or key encapsulation mechanism (KEM) such that they can be treated as a single atomic object at the protocol level. This document defines the structures CompositeSignatureValue, and CompositeSignatureParams, which are sequences of the respective structure for each component algorithm. The explicit variant is defined which allows for a set of signature algorithm identifier OIDs to be registered together as an explicit composite signature algorithm and assigned an OID. The generic composite variant is also defined which allows arbitrary combinations of signature algorithms to be used in the CompositeSignatureValue and CompositeSignatureParams structures without needing the combination to be pre-registered or pre-agreed. This document is intended to be coupled with corresponding documents that define the structure and semantics of composite public and private keys and encryption [I-D.ounsworth-pq-composite-keys], however may also be used with non-composite keys, such as when a protocol combines multiple certificates into a single cryptographic operation. | ||||||||||||||||
| draft-ozdemir-gnap-spc-extension-00.txt | |||||||||||||||||
| GNAP Secure Payment Confirmation Extension | |||||||||||||||||
|
GNAP Secure Payment Confirmation (SPC) Extension is a Grant Negotiation and Authorization Protocol ([GNAP]) extension that defines a method for authentication of the end user during a payment transaction. This extension helps leverage hardware and software authenticators such as biometric scanners while authenticating the end user. | ||||||||||||||||
| draft-paillisse-nmrg-performance-digital-twin-01.txt | |||||||||||||||||
| Performance-Oriented Digital Twins for Packet and Optical Networks | |||||||||||||||||
|
This draft introduces the concept of a Network Digital Twin (NDT) for performance evaluation, a so-called Performance-Oriented Digital Twin (PODT). Two types of PODTs are described. The first, referred to as a Network Performance Digital Twin (NPDT), produces performance estimates (delay, jitter, loss) for a packet network with a specified topology, traffic demand, and routing and scheduling configuration. The second, referred to as an Optical Performance Digital Twin (OPDT), produces transmission performance estimates of an optical network with specified optical service topologies and network equipment types, topology and status. This draft also discusses interfaces to these digital twins, how these digital twins relate to existing control plane elements, and describes use cases for these digital twins, as well as possible implementation options. | ||||||||||||||||
| draft-pala-klaussner-composite-kofn-00.txt | |||||||||||||||||
| K-threshold Composite Signatures for the Internet PKI | |||||||||||||||||
|
With the need to evolve the cryptography used in today applications, devices, and networks, there might be many scenarios where the use of a single-key certificate is not sufficient. For example, there might be the need for migrating between two existing algorithms (e.g., from classic to post-quantum) or there might be the need to test the capabilities of devices via test drivers and/or non-standard algorithms. Differently from the situation where algorithms are not yet (or no more) trusted to be used by themselves, this document addresses the use of multiple keys and signatures that can be individually trusted to implement a generic 1-threshold and K-threshold signature validation procedures. This document provides the definition of a new type of multi- algorithm public key and relies on the definition of CompositePrivateKey, and CompositeSignature which are sequences of the respective structure for each component algorithm as defined in [I-D.ounsworth-pq-composite-sigs] and [I-D.ounsworth-pq-composite-sigs]. | ||||||||||||||||
| draft-palanivelan-bfd-v2-gr-13.txt | |||||||||||||||||
| A Record of Discussions of Graceful Restart Extensions for Bidirectional Forwarding Detection (BFD) | |||||||||||||||||
|
This document is a historical record of discussions about extending the Bidirectional Forwarding Detection (BFD) protocol to provide additional capabilities to handle Graceful Restart. These discussions took place in the context of the IETF's BFD working group, and the consensus in that group was that these extensions should not be made. This document presents a summary of the challenges to BFD in surviving a graceful restart, and outlines a potential protocol solution that was discussed and rejected within the BFD working group. The purpose of this document is to provide a record of the work done so that future effort will not be wasted. This document does not propose or document any extensions to BFD, and there is no intention that it should be implemented in its current form. | ||||||||||||||||
| draft-palmero-opsawg-dmlmo-09.txt | |||||||||||||||||
| Data Model for Lifecycle Management and Operations | |||||||||||||||||
|
This document motivates and specifies a data model for lifecycle management and operations. It describes the motivation and requirements to collect asset-centric metrics including but not limited to asset adoption and usability, licensing, supported features and capabilities, enabled features and capabilities, etc.; with the primary objective to measure and improve the overall user experience along the lifecycle journey, from technical requirements and technology selection through advocacy and renewal, including the end of life of an asset. | ||||||||||||||||
| draft-pan-intarea-lisp-leo-00.txt | |||||||||||||||||
| Location/Identity Separation-based Mobility Management for LEO Satellite Networks | |||||||||||||||||
|
In space-terrestrial integrated networks, the motion of LEO satellites relative to ground terminals is inevitable and can trigger the reassignment of terminal IP addresses, disrupting ongoing TCP connections. The traditional Mobile IP protocol solves this problem using a home agent and tunneling mechanism. However, for space- terrestrial integrated networks, Mobile IP is inefficient due to increased latency when registering with the remote home agent, high packet loss caused by large registration latency, and triangular routing to the remote home agent. To address these issues, this draft proposes LISP-LEO, a location/identity separation-based mobility management protocol for LEO satellite networks. Specifically, LISP-LEO divides the Earth's surface into partitions and maintains a partition-satellite mapping table in real-time based on the regularity of satellite motion. LISP-LEO always routes traffic to the satellite above the destined terminal by querying the partition-satellite mapping table, eliminating triangular routing and related performance overheads. Additionally, LISP-LEO proposes a last-hop relay to handle the corner case when multiple satellites occur above the destined terminal. | ||||||||||||||||
| draft-pantos-hls-rfc8216bis-12.txt | |||||||||||||||||
| HTTP Live Streaming 2nd Edition | |||||||||||||||||
|
This document obsoletes RFC 8216. It describes a protocol for transferring unbounded streams of multimedia data. It specifies the data format of the files and the actions to be taken by the server (sender) and the clients (receivers) of the streams. It describes version 10 of this protocol. | ||||||||||||||||
| draft-pardue-http-identity-digest-01.txt | |||||||||||||||||
| HTTP Identity Digest | |||||||||||||||||
|
The Repr-Digest and Content-Digest integrity fields are subject to HTTP content coding considerations. There are some use cases that benefit from the unambiguous exchange of integrity digests of unencoded representation. The Identity-Digest and Want-Identity- Digest fields complement existing integrity fields for this purpose. | ||||||||||||||||
| draft-pardue-httpbis-preconnect-hint-svc-param-00.txt | |||||||||||||||||
| A Preconnect Hint for SVCB/HTTPS RR | |||||||||||||||||
|
HTTP resources from one origin often have relationships to resources on other origins. This document outlines how a "preconnectHint" SvcParamKey for SVCB, could be used to provide an early indication of origins that are related to the current origin. Clients could use this information to opportunistically prepare and open connections, with the expectation that they will be used to fetch related resources. This mechanism provides information from a source that is not the authenticated origin, which could cause the client to perform actions that no other party would ask them to do; privacy considerations due to this are visited. | ||||||||||||||||
| draft-pardue-httpbis-priority-order-00.txt | |||||||||||||||||
| HTTP priority order extension | |||||||||||||||||
|
The send-order parameter for the HTTP extensible prioritization scheme allows explicit ordering indication independent of request order. This can be used to as an additional input signal to scheduling decisions, to support alternative sending behaviors. | ||||||||||||||||
| draft-parecki-oauth-authorization-server-discovery-00.txt | |||||||||||||||||
| OAuth 2.0 Authorization Server Discovery | |||||||||||||||||
|
This specification provides a mechanism for an access-controlled HTTP resource to indicate which OAuth authorization server it is protected by. This allows the use of OAuth 2.0 authorization by clients that do not have prior knowledge about the resource server's configuration. | ||||||||||||||||
| draft-pauly-masque-quic-proxy-06.txt | |||||||||||||||||
| QUIC-Aware Proxying Using HTTP | |||||||||||||||||
|
This document defines an extension to UDP Proxying over HTTP that adds specific optimizations for proxied QUIC connections. This extension allows a proxy to reuse UDP 4-tuples for multiple connections. It also defines a mode of proxying in which QUIC short header packets can be forwarded using an HTTP/3 proxy rather than being re-encapsulated and re-encrypted. | ||||||||||||||||
| draft-peltan-edns-presentation-format-00.txt | |||||||||||||||||
| EDNS Presentation and JSON Format | |||||||||||||||||
|
This document describes textual and JSON representation format of EDNS option. It also modifies the escaping rules of JSON representation of DNS messages, previously defined in RFC8427. | ||||||||||||||||
| draft-peng-6man-tracing-option-03.txt | |||||||||||||||||
| Tracing process in IPv6 VPN Tunneling Networks | |||||||||||||||||
|
This document specifies the tracing process in IPv6 VPN tunneling networks for diagnostic purposes. An IPv6 Tracing Option is specified to collect and carry the required key information in an effective manner to correctly construct ICMP(v4) and ICMPv6 Time Exceeded messages at the corresponding nodes, i.e. PE and P nodes, respectively. | ||||||||||||||||
| draft-peng-apn-bgp-flowspec-02.txt | |||||||||||||||||
| Dissemination of BGP Flow Specification Rules for APN | |||||||||||||||||
|
A BGP Flow Specification is an n-tuple consisting of several matching criteria that can be applied to IP traffic. Application-aware Networking (APN) is a framework, where APN data packets convey APN attribute including APN ID and/or APN Parameters. The dynamic Flow Spec mechanism for APN is designed for the new applications of traffic filtering in an APN domain as well as the traffic control and actions at the policy enforcement points in this domain. These applications require coordination among the ASes within a service provider. This document specifies a new BGP Flow Spec Component Type in order to support APN traffic filtering. The match field is the APN ID. It also specifies traffic filtering actions to enable the creation of the APN ID in the outer tunnel encapsulation when matched to the corresponding Flow Spec rules. | ||||||||||||||||
| draft-peng-apn-scope-gap-analysis-06.txt | |||||||||||||||||
| APN Scope and Gap Analysis | |||||||||||||||||
|
The APN work in IETF is focused on developing a framework and set of mechanisms to derive, convey and use an attribute allowing the implementation of fine-grain user group-level and application group- level requirements in the network layer. APN aims to apply various policies in different nodes along a network path onto a traffic flow altogether, for example, at the headend to steer into corresponding path, at the midpoint to collect corresponding performance measurement data, and at the service function to execute particular policies. Currently there is still no way to efficiently realize this composite network service provisioning along the path. This document further clarifies the scope of the APN work and describes the solution gap analysis. | ||||||||||||||||
| draft-peng-apn-yang-02.txt | |||||||||||||||||
| A YANG Model for Application-aware Networking (APN) | |||||||||||||||||
|
Application-aware Networking (APN) is a framework, where APN data packets convey APN attribute (incl. APN ID and/or APN Parameters) to enable fine grained service provisioning. This document defines a YANG module for APN. The YANG modules in this document conform to the Network Management Datastore Architecture (NMDA). | ||||||||||||||||
| draft-peng-detnet-deadline-based-forwarding-05.txt | |||||||||||||||||
| Deadline Based Deterministic Forwarding | |||||||||||||||||
|
This document describes a deterministic forwarding mechanism based on deadline. The mechanism enhances strict priority scheduling algorithm with dynamically adjusting the priority of the queue according to its deadline attribute. | ||||||||||||||||
| draft-peng-detnet-packet-timeslot-mechanism-01.txt | |||||||||||||||||
| Generic Packet Timeslot Scheduling Mechanism | |||||||||||||||||
|
IP/MPLS networks use packet switching (with the feature store-and- forward) and are based on statistical multiplexing. S tatistical multiplexing is essentially a variant of time division multiplexing, which refers to the asynchronous and dynamic allocation of link timeslot resources. In this case, the service flow does not occupy a fixed timeslot, and the length of the timeslot is not fixed, but depends on the size of the packet. Statistical multiplexing has certain challenges and complexity in meeting deterministic QoS, and its delay performance is closely related to the used queueing mechanism. This document further describes a generic time division multiplexing scheme in IP/MPLS networks, which we call packet timeslot scheme. It aims to make the control plane easier to calculate the delay performance and more flexible to allocate deterministic resources, and make the data plane create more flexible timeslot mapping. | ||||||||||||||||
| draft-peng-detnet-traffic-shaping-solutions-02.txt | |||||||||||||||||
| Traffic Shaping Solutions for Bounded Latency in Large-scale Networks | |||||||||||||||||
|
This document presents a traffic shaping solution for DetNet service with bounded latency in large-scale networks. The traffic shaping solution includes the edge access control, enqueue cycle mapping and jitter compression mechanisms. These mechanisms support appropriate resource reservation algorithms, reasonably calculate the end-to-end delay in DetNet IP network in advance, and adjust, manage and control the resources after real-time detection. Using the traffic shaping solution, it is possible for an implementer, user, or standards development organization to realize bounded delay based on the existing TSN/DetNet queuing models. | ||||||||||||||||
| draft-peng-idr-segment-routing-te-policy-attr-04.txt | |||||||||||||||||
| Advertising SID Algorithm Information in BGP | |||||||||||||||||
|
This document proposes extensions of BGP and defines new Segment Types to provide algorithm information for SR-MPLS Adjacency-SIDs when delivering SR Policy via BGP. | ||||||||||||||||
| draft-peng-pce-entropy-label-position-09.txt | |||||||||||||||||
| Path Computation Element 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 SHOULD be inserted in the SR-MPLS label stack. This document proposes a set of extensions for Path Computation Element Protocol (PCEP) to configure the entropy label positions for SR-MPLS networks. | ||||||||||||||||
| draft-peng-spring-pmtu-sr-policy-01.txt | |||||||||||||||||
| Path MTU (PMTU) for Segment Routing Policy | |||||||||||||||||
|
This document defines the Path MTU (PMTU) for SR Policy (called SR- PMTU) and it applies to both SRv6 and SR-MPLS. The framework of SR- PMTU for SR Policy is specified, including link MTU collection, SR- PMTU Computation, SR-PMTU Enforcement, and Handling behaviors on the headend. | ||||||||||||||||
| draft-peng-v6ops-eh-deployment-considerations-00.txt | |||||||||||||||||
| Deployment considerations of IPv6 packets with options | |||||||||||||||||
|
As more and more new services using IPv6 options have been proposed and start being deployed in a large-scale network environment, issues also start showing up in deployments. This document describes and analyzes the issues encountered, and aims to provide deployment guidance when the IPv6 options are used. | ||||||||||||||||
| draft-pep-email-02.txt | |||||||||||||||||
| pretty Easy privacy (pEp): Email Formats and Protocols | |||||||||||||||||
|
The proposed pretty Easy privacy (pEp) protocols for email are based upon already existing email and encryption formats (such as PGP/MIME) and designed to allow for easily implementable and interoperable opportunistic encryption. The protocols range from key distribution, secret key synchronization between own devices, to mechanisms of metadata and content protection. The metadata and content protection is achieved by moving the whole message (not only the body part) into the PGP/MIME encrypted part. The proposed pEp Email Formats not only achieve simple forms of metadata protection (like subject encryption), but also allow for sending email messages through a mixnet. Such enhanced forms of metadata protection are explicitly discussed within the scope of this document. The purpose of pEp for email is to simplify and automate operations in order to make usage of email encryption viable for a wider range of Internet users, with the goal of achieving widespread implementation of data confidentiality and privacy practices in the real world. The proposed operations and formats are targeted towards Opportunistic Security scenarios and are already implemented in several applications of pretty Easy privacy (pEp). | ||||||||||||||||
| draft-pep-general-02.txt | |||||||||||||||||
| pretty Easy privacy (pEp): Privacy by Default | |||||||||||||||||
|
The pretty Easy privacy (pEp) model and protocols describe a set of conventions for the automation of operations traditionally seen as barriers to the use and deployment of secure, privacy-preserving end- to-end messaging. These include, but are not limited to, key management, key discovery, and private key handling (including peer- to-peer synchronization of private keys and other user data across devices). Human Rights-enabling principles like data minimization, end-to-end and interoperability are explicit design goals. For the goal of usable privacy, pEp introduces means to verify communication between peers and proposes a trust-rating system to denote secure types of communications and signal the privacy level available on a per-user and per-message level. Significantly, the pEp protocols build on already available security formats and message transports (e.g., PGP/MIME with email), and are written with the intent to be interoperable with already widely-deployed systems in order to ease adoption and implementation. This document outlines the general design choices and principles of pEp. | ||||||||||||||||
| draft-pep-handshake-00.txt | |||||||||||||||||
| pretty Easy privacy (pEp): Contact and Channel Authentication through Handshake | |||||||||||||||||
|
In interpersonal messaging, end-to-end encryption means for public key distribution and verification of its authenticity are needed; the latter to prevent man-in-the-middle (MITM) attacks. This document proposes a new method to easily verify a public key is authentic by a Handshake process that allows users to easily authenticate their communication channel. The new method is targeted to Opportunistic Security scenarios and is already implemented in several applications of pretty Easy privacy (pEp). | ||||||||||||||||
| draft-pep-keyreset-00.txt | |||||||||||||||||
| pretty Easy privacy (pEp): Key Reset | |||||||||||||||||
|
The pretty Easy privacy (pEp) model and protocols describe a set of conventions for the automation of operations traditionally seen as barriers to the use and deployment of secure, privacy-preserving end- to-end messaging. These include, but are not limited to, key management, key discovery, and private key handling (including peer- to-peer synchronization of private keys and other user data across devices). This document specifies the pEp KeyReset protocol that allows applications to provide simple high-level functionality to users needing to perform some of the aforementioned functions while still ensuring that the appropriate low-level changes in keyrings and trust management are handled consistently, and that communication of these changes to active partners (where necessary) happens seamlessly, without explicit action on the part of the user. | ||||||||||||||||
| draft-pep-rating-00.txt | |||||||||||||||||
| pretty Easy privacy (pEp): Mapping of Privacy Rating | |||||||||||||||||
|
In many Opportunistic Security scenarios end-to-end encryption is automatized for Internet users. In addition, it is often required to provide the users with easy means to carry out authentication. Depending on several factors, each communication channel to different peers may have a different Privacy Status, e.g., unencrypted, encrypted and encrypted as well as authenticated. Also each message from/to a single peer may have a different Privacy Status. To display the actual Privacy Status to the user, this document defines a Privacy Rating scheme and its mapping to a traffic-light semantics. A Privacy Status is defined on a per-message basis as well as on a per-identity basis. The traffic-light semantics (as color and symbol rating) allows for a clear and easily understandable presentation to the user in order to optimize User Experience. This rating system is most beneficial to Opportunistic Security scenarios and is already implemented in several applications of pretty Easy privacy (pEp). | ||||||||||||||||
| draft-pep-trustwords-01.txt | |||||||||||||||||
| IANA Registration of Trustword Lists: Guide,Template and IANA Considerations | |||||||||||||||||
|
This document specifies the IANA Registration Guidelines for Trustwords, describes corresponding registration procedures, and provides a guideline for creating Trustword list specifications. Trustwords are common words in a natural language (e.g., English), which byte strings are mapped to. Such a mapping makes verification processes like fingerprint comparisons more practical, and less prone to misunderstandings. | ||||||||||||||||
| draft-peterson-stir-ocsp-staple-00.txt | |||||||||||||||||
| OCSP Stapling for Secure Telephone Identity | |||||||||||||||||
|
In order to facilitate the use of the Online Certificate Status Protocol (OCSP) with Secure Telephone Identity Revisited (STIR), this specification defines a mechanism for incorporating an OCSP staple into a Personal Assertion Token (PASSporT). | ||||||||||||||||
| draft-petithuguenin-computerate-specification-00.txt | |||||||||||||||||
| Computerate Specification | |||||||||||||||||
|
This document specifies computerate specifications, which are the combination of a formal and an informal specification such as parts of the informal specification are generated from the formal specification. | ||||||||||||||||
| draft-petithuguenin-rfc-ontology-02.txt | |||||||||||||||||
| An Ontology for RFCs | |||||||||||||||||
|
This document defines an ontology that describes the specifications published by the RFC Editor, together with ancillary documents. | ||||||||||||||||
| draft-petithuguenin-xml2rfc-asciidoc-01.txt | |||||||||||||||||
| Mappings Between XML2RFC v3 and AsciiDoc | |||||||||||||||||
|
This document specifies a mapping between XML2RFC v3 and AsciiDoc. The goal of this mapping and its associated tooling is to make writing an Internet-Draft as simple as possible, by converting any AsciiDoc formatted document into a valid Internet-Draft, ready to be submitted to the IETF. This is still work in progress and for the time being this mapping only ensures that any valid XML2RFC element can be generated from AsciiDoc. | ||||||||||||||||
| draft-petrie-vcon-01.txt | |||||||||||||||||
| The JSON format for vCon - Conversation Data Container | |||||||||||||||||
|
A vCon is the container for data and information relating to a real- time, human conversation. It is analogous to a [vCard] which enables the definition, interchange and storage of an individual's various points of contact. The data contained in a vCon may be derived from any multimedia session, traditional phone call, video conference, SMS or MMS message exchange, webchat or email thread. The data in the container relating to the conversation may include Call Detail Records (CDR), call meta data, participant identity information (e.g. STIR PASSporT), the actual conversational data exchanged (e.g. audio, video, text), realtime or post conversational analysis and attachments of files exchanged during the conversation. A standardized conversation container enables many applications, establishes a common method of storage and interchange, and supports identity, privacy and security efforts (see [vCon-white-paper]) | ||||||||||||||||
| draft-piraux-tcpls-03.txt | |||||||||||||||||
| TCPLS: Modern Transport Services with TCP and TLS | |||||||||||||||||
|
This document specifies a protocol leveraging TCP and TLS to provide modern transport services such as multiplexing, connection migration and multipath in a secure manner. 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/mpiraux/draft-piraux-tcpls. | ||||||||||||||||
| draft-pismenny-tls-dtls-plaintext-sequence-number-01.txt | |||||||||||||||||
| Plaintext Sequence Numbers for Datagram Transport Security Layer 1.3 | |||||||||||||||||
|
This document specifies a TLS 1.3 extension that enables DTLS 1.3 to negotiate the use of plaintext sequence numbers instead of protected sequence numbers. Plaintext sequence numbers are advantageous in closed networks where the benefits of lower latency outweigh the risk of ossification and reduced privacy. | ||||||||||||||||
| draft-pkaneria-lsr-multi-tlv-02.txt | |||||||||||||||||
| Multi-part TLVs in IS-IS | |||||||||||||||||
|
New technologies are adding new information into IS-IS while deployment scales are simultaneously increasing, causing the contents of many critical TLVs to exceed the currently supported limit of 255 octets. Extensions exist that require significant IS-IS changes that could help address the problem, but a less drastic solution would be beneficial. This document codifies the common mechanism of extending the TLV content space through multiple TLVs. | ||||||||||||||||
| draft-poidt-ccamp-actn-poi-pluggable-00.txt | |||||||||||||||||
| Applicability of Abstraction and Control of Traffic Engineered Networks (ACTN) to Packet Optical Integration (POI) extensions to support Router Optical interfaces | |||||||||||||||||
|
This document extends the draft-ietf-teas-actn-poi-applicability to the use case where the DWDM optical coherent interface is equipped on the Packet device. It identifies the YANG data models being defined by the IETF to support this deployment architecture and specific scenarios relevant for Service Providers. Existing IETF protocols and data models are identified for each multi-layer (packet over optical) scenario with a specific focus on the MPI (Multi-Domain Service Coordinator to Provisioning Network Controllers Interface)in the ACTN architecture. | ||||||||||||||||
| draft-poidt-teas-actn-poi-assurance-00.txt | |||||||||||||||||
| Applicability of Abstraction and Control of Traffic Engineered Networks (ACTN) for Packet Optical Integration (POI) service assurance | |||||||||||||||||
|
This document extends the analysis of the applicability of Abstraction and Control of TE Networks (ACTN) architecture to Packet Optical Integration (POI), provided in RFC YYYY, to cover multi-layer service assurance scenarios, for end-to-end customer L2VPN or L3VPN connectivity services setup over underlying transport optical paths, with specific Service Level Agreement (SLA) requirements. EDITORS NOTE: Replace RFC YYYY with the RFC number of draft-ietf- teas-actn-poi-applicability once it has been published. Existing IETF protocols and data models are identified for each multi-layer (packet over optical) service assurance scenario with a specific focus on the MPI (Multi-Domain Service Coordinator to Provisioning Network Controllers Interface) in the ACTN architecture. | ||||||||||||||||
| draft-polli-restapi-ld-keywords-01.txt | |||||||||||||||||
| REST API Linked Data Keywords | |||||||||||||||||
|
This document defines two keywords to provide semantic information in OpenAPI Specification and JSON Schema documents, and support contract-first semantic schema design. | ||||||||||||||||
| draft-ponchon-ipsecme-anti-replay-subspaces-01.txt | |||||||||||||||||
| IPsec and IKE anti-replay sequence number subspaces for traffic-engineered paths and multi-core processing | |||||||||||||||||
|
This document discusses the challenges of running IPsec with anti- replay in multi-core environments where packets may be re-ordered (e.g., when sent over multiple IP paths, traffic-engineered paths and/or using different QoS classes). A new solution based on splitting the anti-replay sequence number space into multiple different sequencing subspaces is proposed. Since this solution requires support on both parties, an IKE extension is proposed in order to negotiate the use of the anti-replay sequence number subspaces. | ||||||||||||||||
| draft-power-cdni-cache-control-metadata-00.txt | |||||||||||||||||
| CDNI Cache Control Metadata | |||||||||||||||||
|
This specification adds to the basic Cache Control metadata defined in RFC8006, providing Content Providers and uCDNs more fine-grained control over dCDN caching. Use cases include overriding or adjusting cache-control headers from the origin, bypassing caching altogether, or altering cache keys with dynamically generated values. | ||||||||||||||||
| draft-ppsenak-lsr-igp-flex-algo-reverse-affinity-01.txt | |||||||||||||||||
| IGP Flexible Algorithms Reverse Affinity Constraint | |||||||||||||||||
|
An IGP Flexible Algorithm (Flex-Algorithm) allows IGPs to compute constraint-based paths. This document extends IGP Flex-Algorithm with additional constraints. | ||||||||||||||||
| draft-ppsenak-lsr-igp-ureach-prefix-announce-02.txt | |||||||||||||||||
| IGP Unreachable Prefix Announcement | |||||||||||||||||
|
In the presence of summarization, there is a need to signal loss of reachability to an individual prefix covered by the summary in order to enable fast convergence away from paths to the node which owns the prefix which is no longer reachable. This document describes how to use existing protocol mechanisms in IS-IS and OSPF to advertise such prefix reachability loss. | ||||||||||||||||
| draft-pradeepkumarxplorer-smtp-wildcard-01.txt | |||||||||||||||||
| The LIMITS SMTP Service Extension | |||||||||||||||||
|
To allow wild card emailing like walling | ||||||||||||||||
| draft-prodrigues-extar-00.txt | |||||||||||||||||
| draft-prodrigues-extar-00 | |||||||||||||||||
|
The shift to multi-cloud environments brought data leakage prevention challenges for organisations. The current Cross-Tenant Access Restriction (XTAR) mechanisms do not cover critical scenarios where users can connect to multiple tenants (organisational and personal), facilitating data exfiltration. The goal, similar to previously proposed, reviewed and accepted protocols that have been published as RFC standards and are now widely adopted, is to help organisations keep their data under control when using one or more Cloud Service Providers (CSPs). This can be done by incentivising CSPs to adopt the proposed protocol, Extended-Cross-Tenant Access Restriction (E-XTAR), consisting of a globally readable header specifying the allowed | ||||||||||||||||
| draft-qin-savnet-incentive-03.txt | |||||||||||||||||
| The Incentive Consideration for Defense Against Reflection Attacks | |||||||||||||||||
|
Source address spoofing remains a significant challenge in today's Internet. Although source address validation (SAV) mechanisms, such as ingress filtering [RFC2827], unicast Reverse Path Forwarding (uRPF) [RFC3704], and the Enhanced Feasible-Path Unicast Reverse Path Forwarding (EFP-uRPF) [RFC8704], have been proposed for a long time, some ASes have not deployed SAV due to the problems of existing SAV mechanism, such as inaccurate validation, misaligned incentive, or other overhead concerns. This document specifically explains the misaligned incentive problem of existing SAV mechanisms and clarifies the direct incentive that a new SAV mechanism should achieve. | ||||||||||||||||
| draft-qu-identifier-sm3-for-tsig-00.txt | |||||||||||||||||
| Abstract | |||||||||||||||||
|
This document describes how to use a newly added message digest algorithm "SM3" in the TSIG protocol. It can be used to calculate the digest for the TSIG key by using a hash function. This document details the supplementation of the SM3 algorithm in TSIG. | ||||||||||||||||
| draft-quilbeuf-opsawg-configuration-tracing-01.txt | |||||||||||||||||
| External Transaction ID for Configuration Tracing | |||||||||||||||||
|
Network equipment are often configured by a variety of network management systems (NMS), protocols, and teams. If a network issue arises (e.g., because of a wrong configuration change), it is important to quickly identify the root cause and obtain the reason for pushing that modification. Another potential network issue can stem from concurrent NMSes with overlapping intents, each having their own tasks to perform. In such a case, it is important to map the respective modifications to its originating NMS. This document specifies a NETCONF mechanism to automatically map the configuration modifications to their source, up to a specific NMS change request. Such a mechanism is required, in particular, for autonomous networks to trace the source of a particular configuration change that led to an anomaly detection. This mechanism facilitates the troubleshooting, the post mortem analysis, and in the end the closed loop automation required for self-healing networks. The specification also includes a YANG module that is meant to map a local configuration change to the corresponding change transaction, up to the controller or even the orchestrator. | ||||||||||||||||
| draft-rabadan-bess-evpn-inter-domain-opt-b-01.txt | |||||||||||||||||
| EVPN Inter-Domain Option-B Solution | |||||||||||||||||
|
An EVPN Inter-Domain interconnect solution is required if two or more sites of the same Ethernet Virtual Private Network (EVPN) are attached to different IGP domains or Autonomous Systems (AS), and they need to communicate. The Inter-Domain Option-B connectivity model is one of the most popular solutions for such EVPN connectivity. While multiple documents refer to this type of interconnect solution and specify different aspects of it, there is no document that summarizes the impact of the Inter-Domain Option-B connectivity in the EVPN procedures. This document does not specify new procedures but analyses the EVPN procedures in an Inter-Domain Option-B network and suggests potential solutions for the described issues. Those solutions are based on either other specifications or based on local implementations that do not modify the end-to-end EVPN control plane. | ||||||||||||||||
| draft-rabnic-bess-evpn-mcast-eeg-00.txt | |||||||||||||||||
| EVPN Multicast Forwarding for EVPN to EVPN Gateways | |||||||||||||||||
|
This document proposes an EVPN (Ethernet Virtual Private Network) extension to allow IP multicast forwarding on Service Gateways that interconnect two or more EVPN domains. | ||||||||||||||||
| draft-ralston-mimi-linearized-matrix-00.txt | |||||||||||||||||
| Linearized Matrix API | |||||||||||||||||
|
Matrix is an existing openly specified decentralized secure communications protocol able to provide a framework for instant messaging interoperability. Matrix rooms (aka conversations) currently use a Directed Acyclic Graph (DAG) for persisting events/ messages. Servers broadcast their changes to the DAG to every other server in order to create new events. This model provides excellent decentralization characteristics and conversation history replication, but proves complex when aiming to use Matrix strictly for interoperability between today's existing messaging service providers, which often do not persist chat history serverside, and do not seek to replicate it between servers. This document explores an API surface for Matrix which optimizes for ease of interoperability at the expense of decentralized conversation history at a per-room level. We call this API surface "Linearized Matrix". | ||||||||||||||||
| draft-ralston-mimi-matrix-framework-01.txt | |||||||||||||||||
| Matrix as a Messaging Framework | |||||||||||||||||
|
This document describes how Matrix, an existing openly specified decentralized protocol for secure interoperable communications, works to create a framework for messaging. | ||||||||||||||||
| draft-ralston-mimi-matrix-message-format-00.txt | |||||||||||||||||
| Matrix Message Format | |||||||||||||||||
|
This document specifies a message format using Matrix for messaging interoperability. | ||||||||||||||||
| draft-ralston-mimi-matrix-transport-00.txt | |||||||||||||||||
| Matrix Message Transport | |||||||||||||||||
|
This document specifies an openly federated protocol, Matrix, for interoperable message transport. | ||||||||||||||||
| draft-ralston-mimi-messaging-requirements-00.txt | |||||||||||||||||
| Requirements of Interoperable Messaging | |||||||||||||||||
|
This document describes a set of requirements for messaging services to interoperate. These requirements are independent of any particular protocol or messaging service, describing the set of features an interoperable messaging service should support. Services should expect to go beyond the requirements listed here, as MIMI's future content format evolves. | ||||||||||||||||
| draft-ralston-mimi-terminology-00.txt | |||||||||||||||||
| MIMI Terminology | |||||||||||||||||
|
This document introduces a set of terminology to use when discussing or describing concepts within MIMI. | ||||||||||||||||
| draft-ramakrishna-sat-data-sharing-01.txt | |||||||||||||||||
| Protocol for Requesting and Sharing Views across Networks | |||||||||||||||||
|
With increasing use of DLT (distributed ledger technology) systems, including blockchain systems and networks, for virtual assets, there is a need for asset-related data and metadata to traverse system boundaries and link their respective business workflows. Systems and networks can define and project views, or asset states, outside of their boundaries, as well as guard them using access control policies, and external agents or other systems can address those views in a globally unique manner. Universal interoperability requires such systems and networks to request and supply views via gateway nodes using a request-response protocol. The endpoints of this protocol lie within the respective systems or in networks of peer nodes, but the cross-system protocol occurs through the systems’ respective gateways. The inter-gateway protocol that allows an external party to request a view by an address and a DLT system to return a view in response must be DLT-neutral and mask the internal particularities and complexities of the DLT systems. The view generation and verification modules at the endpoints must obey the native consensus logic of their respective networks. | ||||||||||||||||
| draft-ramakrishna-sat-use-cases-02.txt | |||||||||||||||||
| Secure Asset Transfer (SAT) Use Cases | |||||||||||||||||
|
This document describes prominent scenarios where enterprise systems and networks maintaining digital assets require the ability to securely transfer assets or data to each other. | ||||||||||||||||
| draft-ramakrishna-sat-views-addresses-01.txt | |||||||||||||||||
| Views and View Addresses for Secure Asset Transfer | |||||||||||||||||
|
With increasing use of DLT (distributed ledger technology) systems, including blockchain systems and networks, for virtual assets, there is a need for asset-related data and metadata to traverse system boundaries and link their respective business workflows. Core requirements for such interoperation between systems are the abilities of these systems to project views of their assets to external parties, either individual agents or other systems, and the abilities of those external parties to locate and address the views they are interested in. A view denotes the complete or partial state of a virtual asset, or the output of a function computed over the states of one or more assets, or locks or pledges made over assets for internal or external parties. Systems projecting these views must be able to guard them using custom access control policies, and external parties consuming them must be able to verify them independently for authenticity, finality, and freshness. The end-to-end protocol that allows an external party to request a view by an address and a DLT system to return a view in response must be DLT- neutral and mask the interior particularities and complexities of the DLT systems. The view generation and verification modules at the endpoints must obey the native consensus logic of their respective systems. | ||||||||||||||||
| draft-raviolli-intarea-trusted-domain-srv6-01.txt | |||||||||||||||||
| Trusted Domain SRv6 | |||||||||||||||||
|
SRv6 as designed has evoked interest from various parties, though its deployment is being limited by known security problems in its architecture. This document specifies a standard way to create a solution that closes some of the major security concerns, while retaining the basis of the SRv6 protocol. | ||||||||||||||||
| draft-rdb-ohai-feedback-to-proxy-08.txt | |||||||||||||||||
| Oblivious Relay Feedback | |||||||||||||||||
|
Servers often rate-limit incoming requests, for example, rate-limit based upon the source IP address to provide equitable service to clients. However, oblivious HTTP removes the ability for the server to distinguish amongst clients so the server can only rate-limit traffic from the oblivious relay. This harms all clients behind that oblivious relay. This specification enables a server to convey rate-limit information to an oblivious relay, which can use it to apply rate-limit policies on clients. Cooperating oblivious relays can thus provide more equitable service to their distinguishable clients without impacting on all clients behind that oblivious relay. | ||||||||||||||||
| draft-realvnc-websocket-02.txt | |||||||||||||||||
| Use of the WebSocket Protocol as a Transport for the Remote Framebuffer Protocol | |||||||||||||||||
|
The Remote Framebuffer protocol (RFB) enables clients to connect to and control remote graphical resources. This document describes a transport for RFB using the WebSocket protocol, and defines a corresponding WebSocket subprotocol, enabling an RFB server to offer resources to clients with WebSocket connectivity, such as web- browsers. | ||||||||||||||||
| draft-reddy-add-delegated-credentials-00.txt | |||||||||||||||||
| Delegated Credentials to Host Encrypted DNS Forwarders on CPEs | |||||||||||||||||
|
An encrypted DNS server is authenticated by a certificate signed by a Certificate Authority (CA). However, for typical encrypted DNS server deployments on Customer Premise Equipment (CPEs), the signature cannot be obtained or requires excessive interactions with a Certificate Authority. This document explores the use of TLS delegated credentials for a DNS server deployed on a CPE. This approach is meant to ease operating DNS forwarders in CPEs while allowing to make use of encrypted DNS capabilities. | ||||||||||||||||
| draft-reddy-lamps-jose-eku-02.txt | |||||||||||||||||
| X.509 Certificate Extended Key Usage (EKU) for (JOSE) and CBOR Object Signing and Encryption (COSE) | |||||||||||||||||
|
RFC 5280 specifies several extended key purpose identifiers (KeyPurposeIds) for X.509 certificates. This document defines JSON Web Signature (JWS), JSON Web Encryption (JWE), CBOR Object Web Signature (CWS) and CBOR Object Web Encryption (CWE) KeyPurposeIds inclusion in the Extended Key Usage (EKU) extension of X.509 public key certificates. An application processing JWS, JWE, CWS or CWE may require that the EKU extension be present and that a JWS, JWE, CWS or CWE KeyPurposeId be indicated in order for the certificate to be acceptable to validate the JWS or CWS signature or to encrypt a key in JWE or CWE. | ||||||||||||||||
| draft-reddy-tsvwg-explcit-signal-00.txt | |||||||||||||||||
| Encrypted Transport Protocol Path Explicit Signals | |||||||||||||||||
|
This document defines a mechanism for an endpoint to explicitly signal encrypted metadata to the network, and the network to signal its ability to accommodate that metadata back to the endpoint. This mechanism can be used where the endpoints desire that network elements along the path receive these explicit signals. | ||||||||||||||||
| draft-regext-brown-epp-related-objects-00.txt | |||||||||||||||||
| Extensible Provisioning Protocol (EPP) Extension for Related Objects | |||||||||||||||||
|
This document describes an extension to the Extensible Provisioning Protocol (EPP) that allows EPP clients to request the inclusion of related objects in responses to | ||||||||||||||||
| draft-regext-brown-epp-ttl-04.txt | |||||||||||||||||
| Extensible Provisioning Protocol (EPP) mapping for DNS Time-To-Live (TTL) values | |||||||||||||||||
|
This document describes an extension to the Extensible Provisioning Protocol (EPP) that allows EPP clients to manage the Time-To-Live (TTL) value for domain name delegation records. | ||||||||||||||||
| draft-reitzenstein-kitten-opaque-02.txt | |||||||||||||||||
| A SASL and GSS-API Mechanism using the asymmetric password-authenticated key agreement OPAQUE | |||||||||||||||||
|
This specification describes a Simple Authentication and Security Layer (SASL, RFC4422) authentication mechanisms based on the OPAQUE asymmetric password-authenticated key agreement (PAKE) protocol. The mechanism offers two distinct advantages over the SCRAM family of mechanisms. The underlying OPAQUE protocol provides the ability for clients to register without the server having to have access to the clear text password of an user, preventing password exfiltration at registration. Secondly a successful authentication produces a long- term secret key specific to the user that can be used to access encrypted server-side data without needing to share keys between clients via side-band mechanisms. When used in combination with TLS or an equivalent security layer these mechanisms allow for secure channel binding. | ||||||||||||||||
| draft-retana-idr-bgp-quic-01.txt | |||||||||||||||||
| BGP over QUIC | |||||||||||||||||
|
This document defines the use of QUIC as BGP transport protocol. | ||||||||||||||||
| draft-retana-rtgwg-eacp-06.txt | |||||||||||||||||
| A Framework for Energy Aware Control Planes | |||||||||||||||||
|
Energy is a primary constraint in large-scale network design, particularly in cloud-scale data center fabrics. While compute and storage clearly consume the largest amounts of energy in large-scale networks, the optics and electronics used in transporting data also contribute to energy usage and heat generation. This document provides an overview of various areas of concern in the interaction between network performance and efforts at energy aware control planes, as a guide for those working on modifying current control planes or designing new ones to improve the energy efficiency of high density, highly complex, network deployments. | ||||||||||||||||
| draft-richardson-anima-registrar-considerations-06.txt | |||||||||||||||||
| Operational Considerations for BRSKI Registrar | |||||||||||||||||
|
This document describes a number of operational modes that a BRSKI Registration Authority (Registrar) may take on. Each mode is defined, and then each mode is given a relevance within an over applicability of what kind of organization the Registrar is deployed into. This document does not change any protocol mechanisms. This document includes operational advice about avoiding unwanted consequences. | ||||||||||||||||
| draft-richardson-emu-eap-onboarding-03.txt | |||||||||||||||||
| EAP defaults for devices that need to onboard | |||||||||||||||||
|
This document describes a method by which an unconfigured device can use EAP to join a network on which further device onboarding, network attestation or other remediation can be done. While RFC 5216 supports EAP-TLS without a client certificate, that document defines no method by which unauthenticated EAP-TLS can be used. This draft addresses that issue. First, by defining the @eap.arpa domain, and second by showing how it can be used to provide quarantined network access for onboarding unauthenticated devices. | ||||||||||||||||
| draft-richardson-ipv4-reverse-in-v6-01.txt | |||||||||||||||||
| Simple Provisioning of Reverse IPv4 Names | |||||||||||||||||
|
Merges IPv4 reverse names into IPv6 reverse maps, particularly for IPv6 delegations that are managed automatically. | ||||||||||||||||
| draft-richardson-madinas-bcp-00.txt | |||||||||||||||||
| Best Current Practices for consistent network identity in a privacy preserving way | |||||||||||||||||
|
This document describes the best current practices to identify devices in a post Randomized and Changing MAC address environment. | ||||||||||||||||
| draft-richardson-saag-onpath-attacker-03.txt | |||||||||||||||||
| A taxonomy of eavesdropping attacks | |||||||||||||||||
|
The terms on-path attacker and Man-in-the-Middle Attack have been used in a variety of ways, sometimes interchangeably, and sometimes meaning different things. This document offers an update on terminology for network attacks. A consistent set of terminology is important in describing what kinds of attacks a particular protocol defends against, and which kinds the protocol does not. | ||||||||||||||||
| draft-rieckers-radext-rfc6614bis-02.txt | |||||||||||||||||
| Transport Layer Security (TLS) Encryption for RADIUS | |||||||||||||||||
|
This document specifies a transport profile for RADIUS using Transport Layer Security (TLS) over TCP as the transport protocol. This enables dynamic trust relationships between RADIUS servers as well as encrypting RADIUS traffic between servers using a shared secret. | ||||||||||||||||
| draft-robert-mimi-delivery-service-00.txt | |||||||||||||||||
| MIMI Delivery Service | |||||||||||||||||
|
This document describes the MIMI Delivery Service. | ||||||||||||||||
| draft-robert-privacypass-batched-tokens-01.txt | |||||||||||||||||
| Batched Token Issuance Protocol | |||||||||||||||||
|
This document specifies a variant of the Privacy Pass issuance protocol that allows for batched issuance of tokens. This allows clients to request more than one token at a time and for issuers to isse more than one token at a time. | ||||||||||||||||
| draft-rogaglia-netconf-trace-ctx-extension-02.txt | |||||||||||||||||
| NETCONF Extension to support Trace Context propagation | |||||||||||||||||
|
This document defines how to propagate trace context information across the Network Configuration Protocol (NETCONF), that enables distributed tracing scenarios. It is an adaption of the HTTP-based W3C specification. | ||||||||||||||||
| draft-rosenberg-mimi-arch-options-00.txt | |||||||||||||||||
| Architecture Options for More Messaging Interop (MIMI) | |||||||||||||||||
|
This document outlines architecture options for managing the state of chats in MIMI. | ||||||||||||||||
| draft-rosenberg-mimi-msg-format-00.txt | |||||||||||||||||
| Message format for More Messaging Interop (MIMI) | |||||||||||||||||
|
This document defines a semantic model and format for the inter- provider exchange of chat messages. This format is focused on interoperability, while providing extensibility for additional content downstream. It supports the common messaging features present in chat systems today, including threading, reactions, images, gifs, videos, delivery and read receipts. | ||||||||||||||||
| draft-rosenberg-mimi-protocol-00.txt | |||||||||||||||||
| More Instant Messaging Interop (MIMI) Transport Protocol | |||||||||||||||||
|
This document specifies the More Instant Messaging Interop (mimi) Transport Protocol (MTP)- a protocol for inter-provider persistent group chat. MIMI utilizes Messaging Layer Security (MLS) for end-to- end encryption of content. The MIMI Transport Protocol plays the role of the Delivery Service (DS) defined by the MLS protocol. MTP is meant to represent the minimal protocol required to enable provider to provider federation for messaging exchange using MLS. It is not suitable for client to provider communications. MTP is based on a pull architecture, wherein message delivery from provider A to provider B is accomplished by having provider B pull messages from provider A. This provides better scalability and reliability and is amenable to implementation in modern cloud software architectures, while also reducing spam risk. MTP serves as a transfer protocol for opaque message content, the format of which is specified in a separate document. MTP is also designed to prevent spam, and does so by introducing a layer of authorization for the establishment of connections and addition to group chats. | ||||||||||||||||
| draft-rosenberg-mimi-spin-00.txt | |||||||||||||||||
| Simple Protocol for Inviting Numbers (SPIN) | |||||||||||||||||
|
This document introduces a framework and a protocol for facilitating voice, video and messaging interoperability between application providers. This work is motivated by the recent passage of regulation in the European Union - the Digital Markets Act (DMA) - which, amongst many other provisions, requires that vendors of applications with a large number of users enable interoperability with applications made by other vendors. While such interoperability is broadly present within the public switched telephone network, it is not yet commonplace between over-the-top applications, such as Facetime, WhatsApp, and Facebook Messenger. This document specifically defines the Simple Protocol for Inviting Numbers (SPIN) which is used to deliver invitations to mobile phone numbers that can bootstrap subsequent communications over the Internet. | ||||||||||||||||
| draft-rosenberg-mimi-taxonomy-00.txt | |||||||||||||||||
| A Taxonomy for More Messaging Interop (MIMI) | |||||||||||||||||
|
This document introduces a taxonomy and use cases for More Messaging Interop (mimi). This taxonomy includes how users initiate messaging, how recipients receive initial messages, and so on. | ||||||||||||||||
| draft-rosenblum-cdni-protected-secrets-metadata-00.txt | |||||||||||||||||
| CDNI Protected Secrets Metadata | |||||||||||||||||
|
This is an early draft for a proposed mechanism to protect secret values (such as keys or token salt values) that are part of the Configuration Metadata. | ||||||||||||||||
| draft-rransom-secsh-client-ntru-kex-00.txt | |||||||||||||||||
| Client-Side NTRU Key Exchange for Secure Shell (SSH) | |||||||||||||||||
|
This document describes the specification for using NTRU keypairs generated by the client for key exchange in the Secure Shell (SSH) protocol. | ||||||||||||||||
| draft-rswg-xml2rfcv3-implemented-01.txt | |||||||||||||||||
| The "xml2rfc" version 3 Vocabulary as Implemented | |||||||||||||||||
|
This document describes the "xml2rfc" version 3 vocabulary as implemented in xml2rfc tools at the time of publication. Editorial Note This note is to be removed before publishing as an RFC. Discussion of this draft takes place on the rswg@rfc-editor.org mailing list, which has its home pags at | ||||||||||||||||
| draft-rundgren-cotx-04.txt | |||||||||||||||||
| CBOR Object Type Extension (COTX) | |||||||||||||||||
|
This document describes a CBOR tag for augmenting CBOR data items with type identifiers in the form of arbitrary CBOR text strings. This design enables type identifiers to optionally be expressed as URLs, potentially pointing to Web pages holding related descriptions in human readable form, as well as being compatible with established methods for adding type information to JSON and XML data. | ||||||||||||||||
| draft-ruoska-encoding-06.txt | |||||||||||||||||
| Ruoska Encoding | |||||||||||||||||
|
This document describes hierarchically structured binary encoding format called Ruoska Encoding (later RSK). The main design goals are minimal resource usage, well defined structure with good selection of widely known data types, and still extendable for future usage. The main benefit when compared to non binary hierarchically structured formats like XML is simplicity and minimal resource demands. Even basic XML parsing is time and memory consuming operation. When compared to other binary formats like BER encoding of ASN.1 the main benefit is simplicity. ASN.1 with many different encodings is complex and even simple implementation needs a lot of effort. RSK is also more efficient than BER. | ||||||||||||||||
| draft-rustignoli-panrg-scion-components-02.txt | |||||||||||||||||
| SCION Components Analysis | |||||||||||||||||
|
SCION is an inter-domain Internet architecture that focuses on security and availability. Its fundamental functions are carried out by a number of components. This document analyzes its core components from a functionality perspective, describing their dependencies, outputs, and properties provided. The goal is to answer the following questions: * What are the main components of SCION and their dependencies? Can | ||||||||||||||||
| draft-rvelucha-bfd-offload-yang-06.txt | |||||||||||||||||
| YANG Data Model for Bidirectional Forwarding Detection (BFD) Hardware Offloaded Session | |||||||||||||||||
|
This document defines a extension YANG data model that can be used to manage Hardware Offloaded Bidirectional Forwarding Detection (BFD). This document specially talks about BFD sessions that are offloaded to hardware. The YANG modules in this document conform to the Network Management Datastore Architecture (NMDA). | ||||||||||||||||
| draft-saad-spring-srfa-link-02.txt | |||||||||||||||||
| Segment-Routing over Forwarding Adjacency Links | |||||||||||||||||
|
Label Switched Paths (LSPs) set up in Multiprotocol Label Switching (MPLS) networks can be used to form Forwarding Adjacency (FA) links that carry traffic in those networks. An FA link can be assigned Traffic Engineering (TE) parameters that allow other LSR(s) to include it in their constrained path computation. FA link(s) can be also assigned Segment-Routing (SR) segments that enable the steering of traffic on to the associated FA link(s). The TE and SR attributes of an FA link can be advertised using known protocols that carry link state information. This document elaborates on the usage of FA link(s) and their attributes in SR enabled networks. | ||||||||||||||||
| draft-sajassi-bess-evpn-first-hop-security-00.txt | |||||||||||||||||
| EVPN First Hop Security | |||||||||||||||||
|
DHCP Snoop database stores valid IPv4-to-MAC and IPv6-to-MAC bindings by snooping on Dynamic Host Configuration Protocol (DHCP) messages. These bindings are used by security functions like Dynamic ARP Inspection (DAI), Neighbor Discovery Inspection (NDI), IPv4 Source Guard, and IPv6 Source Guard to safeguard against traffic received with a spoofed address. These functions are collectively referred to as First Hop Security (FHS). This document proposes BGP extensions and new procedures to Ethernet VPN (EVPN) [RFC7432] for distribution and synchronization of DHCP snoop database to support FHS. Such synchronization is needed to support EVPN host mobility and multi- homing. | ||||||||||||||||
| draft-sajassi-bess-evpn-ip-aliasing-06.txt | |||||||||||||||||
| EVPN Support for L3 Fast Convergence and Aliasing/Backup Path | |||||||||||||||||
|
This document proposes an EVPN extension to allow several of its multihoming functions, fast convergence and aliasing/backup path, to be used in conjunction with inter-subnet forwarding. The extension is limited to All-Active and Single-Active redundancy modes. | ||||||||||||||||
| draft-sajassi-bess-evpn-umr-mobility-01.txt | |||||||||||||||||
| Mobility Procedures in Presence of Unknown MAC Route | |||||||||||||||||
|
Interconnect Solution for Ethernet VPN [RFC9014] defines Unknown MAC Route (UMR) utilization for Data Center Interconnect (DCI) when EVPN MPLS or EVPN VXLAN is used as overlay network for such interconnects. The introduction of UMR for such scenarios impacts MAC mobility procedures that are not discussed in [RFC9014]. This document describes additional changes and enhancements needed for MAC mobility procedures when UMR is used. | ||||||||||||||||
| draft-sajassi-bess-secure-evpn-06.txt | |||||||||||||||||
| Secure EVPN | |||||||||||||||||
|
The applications of EVPN-based solutions ([RFC7432] and [RFC8365]) have become pervasive in Data Center, Service Provider, and Enterprise segments. It is being used for fabric overlays and inter- site connectivity in the Data Center market segment, for Layer-2, Layer-3, and IRB VPN services in the Service Provider market segment, and for fabric overlay and WAN connectivity in Enterprise networks. For Data Center and Enterprise applications, there is a need to provide inter-site and WAN connectivity over public Internet in a secured manner with same level of privacy, integrity, and authentication for tenant's traffic as IPsec tunneling using IKEv2. This document presents a solution where BGP point-to-multipoint signaling is leveraged for key and policy exchange among PE devices to create private pair-wise IPsec Security Associations without IKEv2 point-to-point signaling or any other direct peer-to-peer session establishment messages. | ||||||||||||||||
| draft-sandowicz-httpbis-httpa2-01.txt | |||||||||||||||||
| The Hypertext Transfer Protocol Attestable (HTTPA) Version 2 | |||||||||||||||||
|
The Hypertext Transfer Protocol Attestable version 2 (HTTPA/2) is an HTTP extension. It is a transaction-based protocol agnostic to Transport Layer Security (TLS) in which the Trusted Execution Environment (TEE) is considered a new type of requested resource over the Internet. The original Hypertext Transfer Protocol Attestable (HTTPA) (referred to as HTTPA/1 in the rest of the document) includes remote attestation (RA) process onto the HTTPS protocol in the assumption of using Transport Layer Security (TLS) across the Internet. In contrast, the design of HTTPA/2 could establish a trusted (attested) and more secure communication without dependence on TLS. The definition of Attestation for the purposes of this draft: The process of vouching for the accuracy of TEE based services, configuration, and data where the TEE conveys Evidence about its environment, roots of trust and protected functions. The Evidence is a digital expression of TEE trustworthiness. | ||||||||||||||||
| draft-sanoj-ipip-00.txt | |||||||||||||||||
| InterPlanetary Internet Protocol (IPIP) | |||||||||||||||||
|
With an exponential increase in the number of devices being connected to the internet, it is clear that the available address range of 2^128 in IPv6 Protocol would not be sufficient to identify and exchange information with all the devices in the universe. This document describes how Internet Protocol addressing standards can be further enhanced to accommodate a wider scale of network devices. | ||||||||||||||||
| draft-sas-idr-maxprefix-inbound-05.txt | |||||||||||||||||
| Inbound BGP Maximum Prefix Limits | |||||||||||||||||
|
This document describes two threshold types to consider when receiving BGP address prefixes from adjacent systems in order to limit the negative impact of route leaks or resource exhaustion in BGP implementations. | ||||||||||||||||
| draft-saum-bess-dampening-backoff-06.txt | |||||||||||||||||
| Defreezing Optimization post EVPN Mac Dampening | |||||||||||||||||
|
MAC move handling in EVPN deployments is discussed in detail in [RFC7432]. There are few optimizations which can be done in existing way of handling the mac duplication. This document describes few of the potential techniques to do so. This document is of informational type based on comments in the ietf meeting. | ||||||||||||||||
| draft-saum-evpn-lsp-ping-extension-02.txt | |||||||||||||||||
| EVPN Mpls Ping Extension | |||||||||||||||||
|
In an EVPN or any other VPN deployment, there is an urgent need to tailor the reachability checks of the client nodes via off-box tools which can be triggered from a remote Overlay end-point or a centralized controller. There is also a ease of operability needed when the knowledge known is partial or incomplete. This document aims to address the limitation in current standards for doing so and provides solution which can be made standards in future. As an additional requirement, in network border routers, there are liaison/ dummy VRFs created to leak routes from one network/fabric to another. There are scenarios wherein an explicit reachability check for these type of VRFs is not possible with existing mpls-ping mechanisms. This draft intends to address this as well. Few of missing pieces are equally applicable to the native lsp ping as well. | ||||||||||||||||
| draft-saum-nvo3-mtu-propagation-over-evpn-overlays-03.txt | |||||||||||||||||
| MTU propagation over EVPN Overlays | |||||||||||||||||
|
Path MTU Discovery between end-host-devices/Virtual-Machines/servers/ workloads connected over an EVPN-Overlay Network in Datacenter/Campus/enterprise deployment, is a problem, yet to be resolved in the standards forums. It needs a converged solution to ensure optimal usage of network and computational resources of the networking elements, including underlay routers/switches, constituting the overlay network. This documents takes leads from the guidelines presented in [RFC4459]. The overlay connectivity can pan across various sites (geographically seperated or collocated) for realizing a Datacenter Interconnect or intersite VPNs between campus sites (buildings, branch offices etc). This literature intends to solve problem of icmp error propagation from an underlay routing/switching device to an end-host (hooked to EVPN overlay), thus facilitating "accurate MTU" learnings. This document also leverages the icmp multipart message extension, mentioned in [RFC4884] to carry the original packet in the icmp PDU. | ||||||||||||||||
| draft-saumthimma-evpn-ip-binding-sync-01.txt | |||||||||||||||||
| Secure IP Binding Synchronization via BGP EVPN | |||||||||||||||||
|
The distribution of clients of L2 domain across extended, networks leveraging overlay fabric, needs to deal with synchronizing the Client Binding Database. The 'Client IP Binding' indicates the IP, MAC and VLAN details of the clients that are learnt by security protocols. Since learning 'Client IP Binding database' is last mile solution, this information stays local to the end point switch, to which clients are connected. When networks are extended across geographies, that is, both layer2 and layer3, the 'Client IP Binding Database' in end point of switches of remote fabrics should be in sync. This literature intends to align the synchronization of 'Client IP Binding Database" through an extension to BGP control plane constructs and as BGP is a typical control plane protocol configured to communicate across network boundries. | ||||||||||||||||
| draft-saumvinayak-bess-all-df-bum-05.txt | |||||||||||||||||
| All PEs as DF | |||||||||||||||||
|
The Designated forwarder concept is leveraged to prevent looping of BUM traffic into tenant network sourced across NVO fabric for multihoming deployments. [RFC7432] defines a preliminary approach to select the DF for an ES,VLAN or ES,Vlan Group, panning across multiple NVE's. [RFC8584] makes the election logic more robust and fine grained by inculcating fair election of DF handling most of the prevalent use-cases. This document presents a deployment problem and a corresponding solution which cannot be easily resolve by rules mentioned in [RFC7432] and [RFC8584]. It involves redundant firewall deployment on disparate overlay sites connected over WAN. The requirement is to allow reachability, ONLY, to the local firewall, unless there is an outage. In case of outage the reachability can be extended to remote site's firewall over WAN. | ||||||||||||||||
| draft-sbn-tls-svcb-ech-00.txt | |||||||||||||||||
| Bootstrapping TLS Encrypted ClientHello with DNS Service Bindings | |||||||||||||||||
|
To use TLS Encrypted ClientHello (ECH) the client needs to learn the ECH configuration for a server before it attempts a connection to the server. This specification provides a mechanism for conveying the ECH configuration information via DNS, using a SVCB or HTTPS record. | ||||||||||||||||
| draft-schanzen-gns-23.txt | |||||||||||||||||
| The GNU Name System | |||||||||||||||||
|
This document contains the GNU Name System (GNS) technical specification. GNS is a decentralized and censorship-resistant domain name resolution protocol that provides a privacy-enhancing alternative to the Domain Name System (DNS) protocols. This document defines the normative wire format of resource records, resolution processes, cryptographic routines and security considerations for use by implementers. This specification was developed outside the IETF and does not have IETF consensus. It is published here to inform readers about the function of GNS, guide future GNS implementations, and ensure interoperability among implementations including with the pre- existing GNUnet implementation. | ||||||||||||||||
| draft-schanzen-r5n-01.txt | |||||||||||||||||
| The R5N Distributed Hash Table | |||||||||||||||||
|
This document contains the R^5N DHT technical specification. R^5N is a secure distributed hash table (DHT) routing algorithm and data structure for decentralized applications. It features an open peer- to-peer overlay routing mechanism which supports ad-hoc permissionless participation and support for topologies in restricted-route environments. This document defines the normative wire format of protocol messages, routing algorithms, cryptographic routines and security considerations for use by implementers. This specification was developed outside the IETF and does not have IETF consensus. It is published here to guide implementation of R^5N and to ensure interoperability among implementations including the pre-existing GNUnet implementation. | ||||||||||||||||
| draft-scheffenegger-congress-rfc5033bis-00.txt | |||||||||||||||||
| Specifying New Congestion Control Algorithms | |||||||||||||||||
|
The IETF's standard congestion control schemes have been widely shown to be inadequate for various environments (e.g., high-speed networks). Recent research has yielded many alternate congestion control schemes that significantly differ from the IETF's congestion control principles. Using these new congestion control schemes in the global Internet has possible ramifications to both the traffic using the new congestion control and to traffic using the currently standardized congestion control. Therefore, the IETF must proceed with caution when dealing with alternate congestion control proposals. The goal of this document is to provide guidance for considering alternate congestion control algorithms within the IETF. | ||||||||||||||||
| draft-schinazi-connect-udp-listen-02.txt | |||||||||||||||||
| Proxying Listener UDP in HTTP | |||||||||||||||||
|
The mechanism to proxy UDP in HTTP only allows each UDP Proxying request to transmit to a specific host and port. This is well suited for UDP client-server protocols such as HTTP/3, but is not sufficient for some UDP peer-to-peer protocols like WebRTC. This document proposes an extension to UDP Proxying in HTTP that enables such use- cases. | ||||||||||||||||
| draft-schinazi-masque-proxy-00.txt | |||||||||||||||||
| The MASQUE Proxy | |||||||||||||||||
|
MASQUE (Multiplexed Application Substrate over QUIC Encryption) is a set of protocols and extensions to HTTP that allow proxying all kinds of Internet traffic over HTTP. This document defines the concept of a "MASQUE Proxy", an Internet-accessible node that can relay client traffic in order to provide privacy guarantees. | ||||||||||||||||
| draft-schmaus-kitten-sasl-ht-09.txt | |||||||||||||||||
| The Hashed Token SASL Mechanism | |||||||||||||||||
|
This document specifies the family of Hashed Token SASL mechanisms which enable a proof-of-possession-based authentication scheme and are meant to be used for quick re-authentication of a previous session. The Hashed Token SASL mechanism's authentication sequence consists of only one round-trip. The usage of short-lived, exclusively ephemeral hashed tokens is achieving the single round- trip property. The SASL mechanism specified herin further provides hash agility, mutual authentication and support for channel binding. | ||||||||||||||||
| draft-schmutzer-pals-ple-03.txt | |||||||||||||||||
| Private Line Emulation over Packet Switched Networks | |||||||||||||||||
|
This document describes a method for encapsulating high-speed bit- streams as virtual private wire services (VPWS) over packet switched networks (PSN) providing complete signal transport transparency. | ||||||||||||||||
| draft-schmutzer-spring-cs-sr-policy-01.txt | |||||||||||||||||
| Circuit Style Segment Routing Policies | |||||||||||||||||
|
This document describes how Segment Routing (SR) policies can be used to satisfy the requirements for strict bandwidth guarantees, end-to- end recovery and persistent paths within a segment routing network. SR policies satisfying these requirements are called “circuit-style” SR policies (CS-SR policies). | ||||||||||||||||
| draft-schoen-intarea-unicast-0-03.txt | |||||||||||||||||
| Unicast Use of the Formerly Reserved 0/8 | |||||||||||||||||
|
This document redesignates 0/8, the lowest block in the IPv4 address space, so that this space is no longer reserved. It asks implementers to make addresses in this range fully usable for unicast use on the Internet. | ||||||||||||||||
| draft-schoen-intarea-unicast-127-03.txt | |||||||||||||||||
| Unicast Use of the Formerly Special-Cased 127/8 | |||||||||||||||||
|
This document redefines the IPv4 local loopback network as consisting only of the 65,536 addresses 127.0.0.0 to 127.0.255.255 (127.0.0.0/16). It asks implementers to make addresses in the prior loopback range 127.1.0.0 to 127.255.255.255 fully usable for unicast use on the Internet. | ||||||||||||||||
| draft-schoen-intarea-unicast-240-04.txt | |||||||||||||||||
| Unicast Use of the Formerly Reserved 240/4 | |||||||||||||||||
|
This document redesignates 240/4, the region of the IPv4 address space historically known as "Experimental," "Future Use," or "Class E" address space, so that this space is no longer reserved. It asks implementers to make addresses in this range fully usable for unicast use on the Internet. | ||||||||||||||||
| draft-schoen-intarea-unicast-lowest-address-03.txt | |||||||||||||||||
| Unicast Use of the Lowest Address in an IPv4 Subnet | |||||||||||||||||
|
With ever-increasing pressure to conserve IP address space on the Internet, it makes sense to consider where relatively minor changes can be made to fielded practice to improve numbering efficiency. One such change, proposed by this document, is to increase the number of unicast addresses in each existing subnet, by redefining the use of the lowest-numbered (zeroth) host address in each IPv4 subnet as an ordinary unicast host identifier, instead of as a duplicate segment- directed broadcast address. | ||||||||||||||||
| draft-schwartz-httpapi-popup-authentication-00.txt | |||||||||||||||||
| Interactive Authentication of Non-Interactive HTTP Requests | |||||||||||||||||
|
On the World Wide Web, a rich ecosystem of authentication options has been developed to support access control for HTTP resources. However, non-interactive usage of HTTP remains limited to the simple authentication mechanisms defined in the HTTP standards. This specification allows non-interactive HTTP contexts to open a browser- like authentication context when necessary, and close it when authentication is complete. | ||||||||||||||||
| draft-schwartz-httpbis-connect-tcp-01.txt | |||||||||||||||||
| Template-Driven HTTP CONNECT Proxying for TCP | |||||||||||||||||
|
TCP proxying using HTTP CONNECT has long been part of the core HTTP specification. However, this proxying functionality has several important deficiencies in modern HTTP environments. This specification defines an alternative HTTP proxy service configuration for TCP connections. This configuration is described by a URI Template, similar to the CONNECT-UDP and CONNECT-IP protocols. | ||||||||||||||||
| draft-schwartz-masque-access-descriptions-03.txt | |||||||||||||||||
| HTTP Access Service Description Objects | |||||||||||||||||
|
HTTP proxies can operate several different kinds of access services. This specification provides a format for identifying a collection of such services. 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-schwartz-masque-access- descriptions/. Source for this draft and an issue tracker can be found at https://github.com/bemasc/access-services. | ||||||||||||||||
| draft-schwartz-ohai-consistency-doublecheck-03.txt | |||||||||||||||||
| Key Consistency by Double-Checking via a Semi-Trusted Proxy | |||||||||||||||||
|
Several recent IETF privacy protocols require clients to acquire bootstrap information for a service in a way that guarantees both authenticity and consistency, e.g., encrypting to the same key as many other users. This specification defines a procedure for transferring arbitrary HTTP resources in a manner that provides these guarantees. The procedure relies on access to a semi-trusted HTTP proxy, under the same security assumptions as an Oblivious HTTP Relay. | ||||||||||||||||
| draft-seemann-quic-reliable-stream-reset-02.txt | |||||||||||||||||
| Reliable QUIC Stream Resets | |||||||||||||||||
|
QUIC ([RFC9000]) defines a RESET_STREAM frame to reset a stream. When a sender resets a stream, it stops retransmitting STREAM frames for this stream. On the receiver side, there is no guarantee that any of the data sent on that stream is delivered to the application. This document defines a new QUIC frame, the RELIABLE_RESET_STREAM frame, that resets a stream, while guaranteeing reliable delivery of stream data up to a certain byte offset. | ||||||||||||||||
| draft-selander-ace-coap-est-oscore-06.txt | |||||||||||||||||
| Protecting EST Payloads with OSCORE | |||||||||||||||||
|
This document specifies public-key certificate enrollment procedures protected with lightweight application-layer security protocols suitable for Internet of Things (IoT) deployments. The protocols leverage payload formats defined in Enrollment over Secure Transport (EST) and existing IoT standards including the Constrained Application Protocol (CoAP), Concise Binary Object Representation (CBOR) and the CBOR Object Signing and Encryption (COSE) format. | ||||||||||||||||
| draft-selander-lake-authz-00.txt | |||||||||||||||||
| Lightweight Authorization for EDHOC | |||||||||||||||||
|
This document describes a procedure for augmenting the lightweight authenticated Diffie-Hellman key exchange protocol EDHOC with third party assisted authorization, targeting constrained IoT deployments (RFC 7228). | ||||||||||||||||
| draft-shafranovich-rfc4180-bis-04.txt | |||||||||||||||||
| Common Format and MIME Type for Comma-Separated Values (CSV) Files | |||||||||||||||||
|
This RFC documents the common format used for Comma-Separated Values (CSV) files and updates the associated MIME type "text/csv". | ||||||||||||||||
| draft-shahzad-scim-device-model-03.txt | |||||||||||||||||
| Device Schema Extensions to the SCIM model | |||||||||||||||||
|
The initial core schema for SCIM (System for Cross Identity Management) was designed for provisioning users. This memo specifies schema extensions that enables provisioning of devices, using various underlying bootstrapping systems, such as Wifi EasyConnect, RFC 8366 vouchers, and BLE passcodes. | ||||||||||||||||
| draft-sharabayko-moq-metrics-00.txt | |||||||||||||||||
| Estimating Transmission Metrics on a QUIC Connection | |||||||||||||||||
|
This document defines an approach of objectively measuring transmission such metrics like delay, jitter, and loss-related transmission metrics for a QUIC [RFC9000] connection using an artificially generated payload of a specific structure. The measurement is to be carried on an application level to be protocol- independent. | ||||||||||||||||
| draft-sharma-bess-multi-site-evpn-03.txt | |||||||||||||||||
| Multi-Site Solution for Ethernet VPN (EVPN) Overlay | |||||||||||||||||
|
This document describes the procedures for interconnecting two or more Network Virtualization Overlays (NVOs) with EVPN via NVO over IP-only network. The solution interconnects Ethernet VPN network by using NVO with Ethernet VPN (EVPN) to facilitate the interconnect in a scalable fashion. The motivation is to support extension of Layer-2 and Layer-3, Unicast & Multicast, VPNs without having to rely on typical Data Center Interconnect (DCI) technologies like MPLS/VPLS. The requirements for the interconnect are similar to the ones specified in [RFC7209], "Requirements for Ethernet VPN (EVPN)". In particular, this document describes the difference of the Gateways (GWs) procedure and combined functionality from [RFC9014], "Interconnect Solution for Ethernet VPN (EVPN) Overlay Networks" and and [EVPN-IPVPN], "EVPN Interworking with IPVPN", which this solution is interoperable to. This document updates and replaces all previous version of Multi-site EVPN based VXLAN using Border Gateways (draft- sharma-multi-site-evpn). | ||||||||||||||||
| draft-shen-idr-flowspec-traffic-compress-action-00.txt | |||||||||||||||||
| BGP Flow-Spec Traffic Compress Action | |||||||||||||||||
|
Flow-spec is an extension to BGP that allows for the dissemination of traffic flow specification rules and traffic filtering actions. This document specifies a new traffic filtering action to support compressing traffic. | ||||||||||||||||
| draft-sheng-rtgwg-overlay-routing-requirement-00.txt | |||||||||||||||||
| Scenarios and Challenges of Overlay Routing for SD-WAN | |||||||||||||||||
|
Overlay routing is essential during the enterprise networks' evolution from the interconnection among multiple on-premise branch sites to more advanced ones, such as the interconnection to multi- clouds. This document analyzes the technical requirements and challenges of overlay routing for SD-WAN in these scenarios. | ||||||||||||||||
| draft-shi-cats-analysis-of-metric-distribution-00.txt | |||||||||||||||||
| Design analysis of methods for distributing the computing metric | |||||||||||||||||
|
This document analyses different methods for distributing the computing metric from the service instance to the ingress router. | ||||||||||||||||
| draft-shi-cats-ipv6-based-con-00.txt | |||||||||||||||||
| IPv6-based Cloud-Oriented Networking (CON) | |||||||||||||||||
|
This document describes the scenarios, requirements and technologies for IPv6-based Cloud-oriented Networking. | ||||||||||||||||
| draft-shi-moq-design-space-analysis-of-moq-01.txt | |||||||||||||||||
| Design Space Analysis of MoQ | |||||||||||||||||
|
This document investigates potential solution directions within the charter scope of MoQ WG. MoQ aims to provide low-latency, efficient media delivery solution for use cases including live streaming, gaming and video conferencing. To achieve low-latency media transfer efficiently, the network topology of relay nodes and the computation done at the relay nodes should be considered carefully. This document provides the analysis of those factors which can help the design of the MoQ protocols. | ||||||||||||||||
| draft-shi-quic-dtp-07.txt | |||||||||||||||||
| Deadline-aware Transport Protocol | |||||||||||||||||
|
This document defines Deadline-aware Transport Protocol (DTP) to provide block-based deliver-before-deadline transmission. The intention of this memo is to describe a mechanism to fulfill unreliable transmission based on QUIC as well as how to enhance timeliness of data delivery. | ||||||||||||||||
| draft-shi-quic-structured-connection-id-00.txt | |||||||||||||||||
| Structured Connection ID Carrying Metadata | |||||||||||||||||
|
This document describes a mechanism to carry the metadata in the QUIC connection ID so that the intermediary can perform optimization. | ||||||||||||||||
| draft-shishio-grow-isp-rfd-implement-survey-05.txt | |||||||||||||||||
| Route Flap Damping Deployment Status Survey | |||||||||||||||||
|
BGP Route Flap Damping [RFC2439] is a mechanism that targets route stability. It penalyzes routes that flap with the aim of reducing CPU load on the routers. But it has side-effects. Thus, in 2006, RIPE recommended not to use Route Flap Damping (see [RIPE-378]). Now, some researchers propose to turn RFD, with less aggressive parameters, back on [draft-ymbk-rfd-usable]. This document describes results of a survey conducted among service provider on their use of BGP Route Flap Damping. | ||||||||||||||||
| draft-sidor-pce-circuit-style-pcep-extensions-03.txt | |||||||||||||||||
| PCEP extensions for Circuit Style Policies | |||||||||||||||||
|
This document proposes a set of extensions for Path Computation Element Communication Protocol (PCEP) for Circuit Style Policies - Segment-Routing Policy designed to satisfy requirements for connection-oriented transport services. New TLV is introduced to control path recomputation and new flag to add ability to request path with strict hops only. | ||||||||||||||||
| draft-siloniz-cdni-edge-control-metadata-00.txt | |||||||||||||||||
| CDNI Edge Control Metadata | |||||||||||||||||
|
This specification defines MI configuration metadata objects to extend RFC 8006 related to controlling edge access to resources via CDNs and Open Caching systems. Configuring Cross-Origin Resource Sharing (CORS) access rules and the dynamic generation of CORS headers is a key feature of typical configurations, as are the ability to define response body compression rules, client connection timeouts, and traffic type hints for optimized caching. | ||||||||||||||||
| draft-sipos-dtn-bpv7-cla-services-00.txt | |||||||||||||||||
| Bundle Protocol Expected Convergence Layer Adapter Services | |||||||||||||||||
|
This document attempts to harmonize the services expected of a Convergence Layer Adapter (CLA) by an overlaying Bundle Protocol Agent (BPA). This harmonization is based on combining the various existing CLA behaviors into a set of minimum expected service interfaces. | ||||||||||||||||
| draft-sipos-dtn-eid-pattern-00.txt | |||||||||||||||||
| Bundle Protocol Endpoint ID Patterns | |||||||||||||||||
|
This document extends the Endpoint ID (EID) concept into an EID Pattern, which is used to categorize any EID as matching a specific pattern or not. EID Patterns are suitable for expressing agent configuration, for being used on-the-wire by DTN protocols, and for being easily understandable by a layperson. EID Patterns include scheme-specific optimizations for expressing set membership and each scheme pattern includes text and CBOR encoding forms; the pattern for the "ipn" EID scheme being designed to be highly compressible in its CBOR form. This document also defines a Public Key Infrastructure Using X.509 (PKIX) Other Name form to contain an EID Pattern and a handling rule to use a pattern to match an EID. | ||||||||||||||||
| draft-sl-rtgwg-far-dcn-19.txt | |||||||||||||||||
| Generic Fault-Avoidance Routing Protocol for Data Center Networks | |||||||||||||||||
|
This document describes a generic routing method and protocol for a regular data center network, named the Fault-Avoidance Routing (FAR) protocol. The FAR protocol provides a generic routing method for all types of regular topology network architectures that have been proposed for large-scale cloud-based data centers over the past few years. The FAR protocol is designed to leverage any regularity in the topology and compute its routing table in a concise manner. Fat- tree is taken as an example architecture to illustrate how the FAR protocol can be applied in real operational scenarios. | ||||||||||||||||
| draft-slevinski-iswa-2010-00.txt | |||||||||||||||||
| Encoding the graphemes of the SignWriting Script with the x-ISWA-2010 | |||||||||||||||||
|
For concreteness, because the universal character set is not yet universal, because an undocumented and unlabeled coded character set hampers information interchange, a 12-bit coded character set has been created that encodes the graphemes of the SignWriting script as described in the open standard of the International SignWriting Alphabet 2010. The x-ISWA-2010 coded character set is defined with hexadecimal characters and described with Unicode characters, either proposed characters on plane 1 or interchange characters on plane 15. This memo defines a standard coded character set for the Internet community. It is published for reference, examination, implementation, and evaluation. Distribution of this memo is unlimited. | ||||||||||||||||
| draft-smn-idr-inter-domain-ibgp-00.txt | |||||||||||||||||
| Interconnecting domains with Multiprotocol IBGP | |||||||||||||||||
|
This document relaxes the constraints specified in [RFC4364] and [RFC4456] allowing the building of Inter-domain L3VPN architecture with Multiprotocol internal BGP. | ||||||||||||||||
| draft-smyslov-ike2-gost-15.txt | |||||||||||||||||
| Using GOST Cryptographic Algorithms in the Internet Key Exchange Protocol Version 2 (IKEv2) | |||||||||||||||||
|
This document defines a set of cryptographic transforms for use in the Internet Key Exchange protocol version 2 (IKEv2). The transforms are based on Russian cryptographic standard algorithms (GOST). Use of GOST ciphers in IKEv2 was defined in RFC 9227. This document aims to define using GOST algorithms for the rest of cryptographic transforms used in IKEv2. This specification was developed to facilitate implementations that wish to support the GOST algorithms. This document does not imply IETF endorsement of the cryptographic algorithms used in this document. | ||||||||||||||||
| draft-smyslov-ipsecme-ikev2-cookie-revised-05.txt | |||||||||||||||||
| Revised Cookie Processing in the IKEv2 Protocol | |||||||||||||||||
|
This document defines a revised processing of cookies in the Internet Key Exchange protocol Version 2 (IKEv2). It is intended to solve a problem in IKEv2 when due to packets loss and reordering peers may erroneously fail to authenticate each other when cookies are used in the initial IKEv2 exchange. | ||||||||||||||||
| draft-smyslov-ipsecme-ikev2-extended-pld-01.txt | |||||||||||||||||
| Extended IKEv2 Payload Format | |||||||||||||||||
|
This document describes an extended payload format for the Internet Key Exchange protocol version 2 (IKEv2) messages. This format allows both to decrease an overhead many IKEv2 payloads have and to overcome the current 64 Kbytes limit on the maximum payload size. | ||||||||||||||||
| draft-smyslov-ipsecme-ikev2-qr-alt-07.txt | |||||||||||||||||
| Alternative Approach for Mixing Preshared Keys in IKEv2 for Post-quantum Security | |||||||||||||||||
|
An IKEv2 extension defined in [RFC8784] allows IPsec traffic to be protected against someone storing VPN communications today and decrypting it later, when (and if) cryptographically relevant quantum computers are available. However, this protection doesn't cover an initial IKEv2 SA, which might be unacceptable in some scenarios. This specification defines an alternative way get protection against quantum computers, but unlike the [RFC8784] solution it covers the initial IKEv2 SA too. | ||||||||||||||||
| draft-snell-activity-streams-type-01.txt | |||||||||||||||||
| The application/stream+json Media Type | |||||||||||||||||
|
This specification defines and registers the application/stream+json Content Type for the JSON Activity Streams format. | ||||||||||||||||
| draft-song-ippm-inband-e2e-rtt-measurement-04.txt | |||||||||||||||||
| In-band Edge-to-Edge Round Trip Time Measurement | |||||||||||||||||
|
This draft describes a lightweight in-band in-network edge-to-edge flow-based network round trip time measurement architecture and proposes the implementation over IOAM E2E option. By augmenting the IOAM E2E option header, the process can be fully done in data plane without needing to involve the control plane to maintain any states. | ||||||||||||||||
| draft-song-ippm-postcard-based-telemetry-15.txt | |||||||||||||||||
| Postcard-Based On-Path Telemetry using Packet Marking | |||||||||||||||||
|
The document describes a postcard-based on-path telemetry method using packet-marking, referred to as PBT-M. Similar to IOAM DEX, PBT-M does not carry the telemetry data in user packets but sends the telemetry data through a dedicated packet. However, PBT-M does not require an extra instruction header but claims a bit in existing header fields or uses some other equivalent means as a trigger for telemetry data processing and collection. Due to this feature, PBT-M raises some unique issues that need to be considered for its application in different networks. This document describes the high level scheme, summarizes the common requirements and issues, and provides recommendations for solutions. PBT-M is complementary to the other on-path telemetry schemes. | ||||||||||||||||
| draft-song-mpls-eh-indicator-06.txt | |||||||||||||||||
| Options for MPLS Extension Header Indicator | |||||||||||||||||
|
This document enumerates and describes the candidate schemes that can be used to indicate the presence of the MPLS extension header(s) following the MPLS label stack. The similar schemes are also applicable for indicating the potential in-stack extensions. After a careful evaluation of these options by comparing their pros and cons, it is expected that one should be chosen as the final standard scheme for MPLS extension indicator. | ||||||||||||||||
| draft-song-mpls-extension-header-12.txt | |||||||||||||||||
| MPLS Network Actions using Post-Stack Extension Headers | |||||||||||||||||
|
Motivated by the need to support multiple in-network services and functions in an MPLS network (a.k.a. MPLS Network Actions (MNA)), this document describes a generic and extensible method to encapsulate MNA instructions as well as possible ancillary data in an MPLS packet. All the post-stack MNAs are encapsulated in a structure called Post-stack Action Header (PAH). A PAH is composed of a common header plus a chain of extension headers; each extension header is a container for an MNA. The encapsulation method allows chaining multiple post-stack extension headers and provides the means to enable fast access to them as well as the original upper layer headers. This document confines to the solution of PAH encoding and leaves the specification of PAH indicator to the overall MNA solution. We show how PAH can be used to support several new MNAs as a generic post-stack mechanism. | ||||||||||||||||
| draft-song-mpls-flag-based-opt-01.txt | |||||||||||||||||
| Flag-based MPLS On Path Telemetry Network Actions | |||||||||||||||||
|
This document describes the scheme to support two on-path telemetry techniques, PBT-M and Alternate Marking, as flag-based MPLS Network Actions for OAM in MPLS networks. | ||||||||||||||||
| draft-song-mpls-sr-eh-00.txt | |||||||||||||||||
| Segment Routing with MPLS Extension Header | |||||||||||||||||
|
This document describes an alternative approach to implement segment routing in MPLS networks with the use of a post-stack MPLS extension header under the MPLS network action framework. The new approach reduces the MPLS label stack depth and provide supports for advanced functions such as network programming similar to SRv6. | ||||||||||||||||
| draft-song-network-aware-dns-02.txt | |||||||||||||||||
| The Architecture of Network-Aware Domain Name System (DNS) | |||||||||||||||||
|
A simple method of enhancing Domain Name System (DNS) with network awareness is discussed. This enables DNS system responses that are dependent on communication service requirements such as QoS or path without changes in the format of DNS protocol messages or application program interfaces (APIs). The different enhancement methods and use cases are discussed. | ||||||||||||||||
| draft-song-opsawg-ifit-framework-19.txt | |||||||||||||||||
| A Framework for In-situ Flow Information Telemetry | |||||||||||||||||
|
As network scale increases and network operation becomes more sophisticated, existing Operation, Administration, and Maintenance (OAM) methods are no longer sufficient to meet the monitoring and measurement requirements. Emerging data-plane on-path telemetry techniques, such as IOAM and AltMrk, which provide high-precision flow insight and issue notifications in real time can supplement existing proactive and reactive methods that run in active and passive modes. They enable quality of experience for users and applications, and identification of network faults and deficiencies. This document describes a reference framework, named as In-situ Flow Information Telemetry, for the on-path telemetry techniques. The high-level framework outlines the system architecture for applying the on-path telemetry techniques to collect and correlate performance measurement information from the network. It identifies the components that coordinate existing protocol tools and telemetry mechanisms, and addresses deployment challenges for flow-oriented on- path telemetry techniques, especially in carrier networks. The document is a guide for system designers applying the referenced techniques. It is also intended to motivate further work to enhance the OAM ecosystem. | ||||||||||||||||
| draft-song-ship-edge-05.txt | |||||||||||||||||
| Short Hierarchical IP Addresses for Edge Networks | |||||||||||||||||
|
To mitigate the IPv6 header overhead and improve the scalability and performance in edge networks, this draft proposes to use short hierarchical IP addresses excluding the network prefix within edge networks. An edge network can be further organized into a hierarchical architecture containing one or more levels of networks. While each end node only needs to keep a short address suffix as its identifier, the border routers for each hierarchical level are responsible for address augmenting and pruning when a packet leaves or enter a lower level network. Specifically, the top-level border routers of an edge network convert the internal IP header to and from the standard IPv6 header. This draft presents an incrementally deployable scheme allowing packet header to be effectively compressed in edge networks without affecting the network interoperability. Simplifying both network data plane and control plane, the SHIP architecture is suitable for any types of edge networks, especially when low latency, high performance, and high bandwidth efficiency are required. | ||||||||||||||||
| draft-song-spring-siam-05.txt | |||||||||||||||||
| SRv6 In-situ Active Measurement | |||||||||||||||||
|
This draft describes an active measurement method for SRv6 which can support segment-by-segment and end-to-end measurement on any SRv6 path using existing protocols such as IOAM. A packet containing an SRH uses a flag bit to indicate the packet is an active probing packet and requires segment-by-segment processing. The measurement information, such as the IOAM header and data, is encapsulated in UDP payload, indicated by a dedicated port number. The probing packet originates from a segment source node, traverses an arbitrary segment path, and terminates at a segment endpoint node, as configured by the segment list in SRH. Each segment node on the path, when detecting the flag, shall parse the UDP header and the payload. In the case of IOAM, the node shall process the IOAM option conforming to the standard procedures defined in the IOAM documents. The method is compatible with some other SRv6 active measurement proposals and support multiple applications. | ||||||||||||||||
| draft-spaghetti-idr-bgp-sendholdtimer-09.txt | |||||||||||||||||
| Border Gateway Protocol 4 (BGP-4) Send Hold Timer | |||||||||||||||||
|
This document defines the SendHoldTimer session attribute for the Border Gateway Protocol (BGP) Finite State Machine (FSM). Implementation of a SendHoldTimer should help overcome situations where BGP sessions are not terminated after it has become detectable for the local system that the remote system is not processing BGP messages. For robustness, this document specifies that the local system should close BGP connections and not solely rely on the remote system for session closure when BGP timers have expired. This document updates RFC4271. | ||||||||||||||||
| draft-spaghetti-sidrops-aspa-slurm-01.txt | |||||||||||||||||
| Simplified Local Internet Number Resource Management (SLURM) with RPKI Autonomous System Provider Authorizations (ASPA) | |||||||||||||||||
|
ISPs may want to establish a local view of exceptions to the Resource Public Key Infrastructure (RPKI) data in the form of local filters and additions. This document defines an addendum to RFC 8416 by specifying a format for local filters and local assertions for Autonomous System Provider Authorizations (ASPA) for use with the RPKI. | ||||||||||||||||
| draft-spaghetti-sidrops-rpki-asgroup-00.txt | |||||||||||||||||
| A profile for RPKI Signed Groupings of Autonomous System Numbers (ASGroup) | |||||||||||||||||
|
This document defines a Cryptographic Message Syntax (CMS) protected content type for use with the Resource Public Key Infrastructure (RPKI) to carry a general-purpose listing of Autonomous System Numbers (ASNs) and/or pointers to other groupings of ASNs, called an ASGroup. Additionally, the document specifies a mechanism for ASN holders to opt-out of being listed in a given ASGroup. The objective is to offer a RPKI-based successor to plain-text RFC 2622 'as-set' class objects. When validated, an ASGroup confirms that the respective ASN holder produced the ASGroup object. | ||||||||||||||||
| draft-spaghetti-sidrops-rpki-prefixlist-00.txt | |||||||||||||||||
| A profile for RPKI Signed Lists of Prefixes | |||||||||||||||||
|
This document defines a "RPKI Prefix List", a Cryptographic Message Syntax (CMS) protected content type for use with the Resource Public Key Infrastructure (RPKI) to carry the complete list of prefixes which an Autonomous System (AS) may originate to all or any of its routing peers. The validation of a RPKI Prefix List confirms that the holder of the listed ASN produced the object, and that this list is a current, accurate and complete description of address prefixes that may be announced into the routing system originated by this AS. | ||||||||||||||||
| draft-sparks-test-async-submission-00.txt | |||||||||||||||||
| Testing async submission | |||||||||||||||||
|
This draft is submitted only to test the async api submission endpoint | ||||||||||||||||
| draft-spinosa-urn-lex-18.txt | |||||||||||||||||
| A Uniform Resource Name (URN) Namespace for Sources of Law (LEX) | |||||||||||||||||
|
This document describes a Uniform Resource Name (URN) Namespace Identification (NID) convention 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. | ||||||||||||||||
| draft-sr-bess-evpn-dpath-03.txt | |||||||||||||||||
| Domain Path (D-PATH) for Ethernet VPN (EVPN) Interconnect Networks | |||||||||||||||||
|
The BGP Domain PATH (D-PATH) attribute is defined for Inter-Subnet Forwarding (ISF) BGP Sub-Address Families that advertise IP prefixes. When used along with EVPN IP Prefix routes or IP-VPN routes, it identifies the domain(s) through which the routes have passed and that information can be used by the receiver BGP speakers to detect routing loops or influence the BGP best path selection. This document extends the use of D-PATH so that it can also be used along with other EVPN route types. | ||||||||||||||||
| draft-sr-bess-evpn-vpws-gateway-02.txt | |||||||||||||||||
| Ethernet VPN Virtual Private Wire Services Gateway Solution | |||||||||||||||||
|
Ethernet VPN Virtual Private Wire Services (EVPN VPWS) need to be deployed in high scale multi-domain networks, where each domain can use a different transport technology, such as MPLS, VXLAN or Segment Routing with MPLS or IPv6 Segment Identifiers (SIDs). While transport interworking solutions on border routers spare the border routers from having to process service routes, they do not always meet the multi-homing, redundancy, and operational requirements, or provide the isolation that each domain requires. This document analyzes the scenarios in which an interconnect solution for EVPN VPWS using EVPN Domain Gateways is needed, and adds the required extensions to support it. | ||||||||||||||||
| draft-sriram-idr-route-leak-solution-discussion-09.txt | |||||||||||||||||
| Design Discussion of Route Leaks Solution Methods | |||||||||||||||||
|
This document captures the design rationale of the route leaks solution document (see draft-ietf-idr-route-leak-detection- mitigation, draft-ietf-grow-route-leak-detection-mitigation). The designers needed to balance many competing factors, and this document provides insights into the design questions and their resolution. | ||||||||||||||||
| draft-sriram-sidrops-as-hijack-detection-05.txt | |||||||||||||||||
| AS Hijack Detection and Mitigation | |||||||||||||||||
|
This document proposes a method for detection and mitigation of AS hijacking. In this mechanism, an AS operator registers a new object in the RPKI called 'ROAs Exist for All Prefixes (REAP)'. REAP is digitally signed using the AS holder's certificate. By registering a REAP object, the AS operator is declaring that they have Route Origin Authorization (ROA) coverage for all prefixes originated by their AS. A receiving AS will mark a route as Invalid if the prefix is not covered by any Validated ROA Payload (VRP) and the route origin AS has signed a REAP. Here Invalid means that the route is determined to be an AS hijack. | ||||||||||||||||
| draft-sriram-sidrops-drop-invalid-policy-10.txt | |||||||||||||||||
| Origin Validation Policy Considerations for Dropping Invalid Routes | |||||||||||||||||
|
Deployment of Resource Public Key Infrastructure (RPKI) and Route Origin Authorizations (ROAs) is expected to occur gradually over several or many years. During the incremental deployment period, network operators would wish to have a meaningful policy for dropping Invalid routes. Their goal is to balance (A) dropping Invalid routes so hijacked routes can be eliminated, versus (B) tolerance for missing or erroneously created ROAs for customer prefixes. This document considers a Drop Invalid if Still Routable (DISR) policy that is based on these considerations. The key principle of DISR policy is that an Invalid route can be dropped if a Valid or NotFound route exists for a subsuming less specific prefix. | ||||||||||||||||
| draft-srld-teas-5g-slicing-08.txt | |||||||||||||||||
| A Realization of IETF Network Slices for 5G Networks Using Current IP/ MPLS Technologies | |||||||||||||||||
|
5G slicing is a feature that was introduced by the 3rd Generation Partnership Project (3GPP) in mobile networks. This feature covers slicing requirements for all mobile domains, including the Radio Access Network (RAN), Core Network (CN), and Transport Network (TN). This document describes a basic IETF Network Slice realization model in IP/MPLS networks with a focus on the Transport Network fulfilling 5G slicing connectivity requirements. This realization model reuses many building blocks currently commonly used in service provider networks. | ||||||||||||||||
| draft-ssangli-idr-bgp-generic-metric-aigp-04.txt | |||||||||||||||||
| Generic Metric for the AIGP attribute | |||||||||||||||||
|
This document defines extensions to the AIGP attribute to carry Generic Metric sub-types. This is applicable when multiple domains exchange BGP routing information. The extension will aid in intent- based end-to-end path selection. | ||||||||||||||||
| draft-steckbeck-ua-conn-sec-00.txt | |||||||||||||||||
| User Agent Connection Security | |||||||||||||||||
|
The user agent to server transaction has many attack surfaces which have been defended by various recommendations such as Content Security Policy. An attack vector that is currently exploited is the open connection policy to first, second- and third-party resources. A breach of the origin website or other connected resource could require the client to load resources from a malicious network. This document provides a framework which allows authors to publish authorized connectable second- and third-party resources that a user agent should or must follow depending on configuration of that user agent. | ||||||||||||||||
| draft-steele-cose-kyber-00.txt | |||||||||||||||||
| COSE Kyber | |||||||||||||||||
|
This specification defines how to represent cryptographic keys for Kyber, an IND-CCA2-secure key encapsulation mechanism (KEM), for use with the key representation formats of JSON Web Key (JWK) and COSE (COSE_Key). | ||||||||||||||||
| draft-steele-cose-merkle-tree-proofs-00.txt | |||||||||||||||||
| Concise Encoding of Signed Merkle Tree Proofs | |||||||||||||||||
|
This specification describes three CBOR data structures for primary use in COSE envelopes. A format for Merkle Tree Root Signatures with metadata, a format for Inclusions Paths, and a format for disclosure of a single hadh tree leaf payload (Merkle Tree Proofs). | ||||||||||||||||
| draft-storey-smtp-client-id-14.txt | |||||||||||||||||
| SMTP Service Extension for Client Identity | |||||||||||||||||
|
This document defines an extension for the Simple Mail Transfer Protocol (SMTP) called "CLIENTID" to provide a method for clients to indicate an identity to the server. This identity is an additional token that may be used for security and/or informational purposes, and with it a server may optionally apply heuristics using this token. | ||||||||||||||||
| draft-sun-alto-arch-computing-optical-network-02.txt | |||||||||||||||||
| Architecture of Computing Power Optical Network | |||||||||||||||||
|
This document describes the architecture of computing power optical network. | ||||||||||||||||
| draft-sun-nmrg-hybrid-switching-06.txt | |||||||||||||||||
| Resource Allocation Model for Hybrid Switching Networks | |||||||||||||||||
|
The fast increase in traffic volumn within and outside Datacenters is placing an unprecendented challenge on the underline network, in both the capacity it can provide, and the way it delivers traffic. When a large portion of network traffic is contributed by large flows, providing high capacity and slow to change optical circuit switching along side fine-granular packet services may potentially improve network utility and reduce both CAPEX and OpEX. This gives rise to the concept of hybrid switching - a paradigm that seeks to make the best of packet and circuit switching. However, the full potential of hybrid switching networks (HSNs) can only be realized when such a network is optimally designed and operated, in the sense that "an appropriate amount of resource is used to handle an appropriate amount of traffic in both switching planes." The resource allocation problem in HSNs is in fact complex ineractions between three components: resource allocation between the two switching planes, traffic partitioning between the two switching planes, and the overall cost or performance constraints. In this memo, we explore the challenges of planning and operating hybrid switching networks, with a particular focus on the resource allocation problem, and provide a high-level model that may guide resource allocation in future hybrid switching networks. | ||||||||||||||||
| draft-svg-tiny-ps-abrotman-05.txt | |||||||||||||||||
| SVG Tiny Portable/Secure | |||||||||||||||||
|
This document specifies SVG Tiny Portable/Secure (SVG Tiny PS) -- A Scalable Vector Graphics (SVG) profile to be used with documents that are intended for use with more secure requirements, and in some cases, in conjunction with a limited rendering engine. | ||||||||||||||||
| draft-sw-detnet-network-slice-mapping-yang-02.txt | |||||||||||||||||
| YANG Data Model for DetNet Mapping with Network Slice | |||||||||||||||||
|
The convergence of IETF Network Slicing with DetNet achieves adequate network resource allocation and reservation to each node along the way of DetNet flows for latency-sensitive services. This document introduces the applicability of DetNet to network slice , DetNet mapping with Network Slice requirements and YANG data models extensions in the context of IP/ MPLS network. | ||||||||||||||||
| draft-sweet-iot-acme-03.txt | |||||||||||||||||
| ACME-Based Provisioning of IoT Devices | |||||||||||||||||
|
This document extends the Automatic Certificate Management Environment (ACME) [RFC8555] to provision X.509 certificates for local Internet of Things (IoT) devices that are accepted by existing web browsers and other software running on End User client devices. | ||||||||||||||||
| draft-sx-detnet-mpls-queue-05.txt | |||||||||||||||||
| MPLS Sub-Stack Encapsulation for Deterministic Latency Action | |||||||||||||||||
|
This document specifies formats and principals for the MPLS header which contains the Deterministic Latency Action (DLA) option, designed for use over a DetNet network with MPLS data plane. It enables guaranteed latency support and makes scheduling decisions for time-sensitive service running on DetNet nodes that operate within a constrained network domain. | ||||||||||||||||
| draft-t2trg-idevid-considerations-00.txt | |||||||||||||||||
| A Taxonomy of operational security considerations for manufacturer installed keys and Trust Anchors | |||||||||||||||||
|
This document provides a taxonomy of methods used by manufacturers of silicon and devices to secure private keys and public trust anchors. This deals with two related activities: how trust anchors and private keys are installed into devices during manufacturing, and how the related manufacturer held private keys are secured against disclosure. This document does not evaluate the different mechanisms, but rather just serves to name them in a consistent manner in order to aid in communication. RFCEDITOR: please remove this paragraph. This work is occurring in https://github.com/mcr/idevid-security-considerations | ||||||||||||||||
| draft-talpey-rdma-commit-02.txt | |||||||||||||||||
| RDMA Extensions for Enhanced Memory Placement | |||||||||||||||||
|
This document specifies extensions to RDMA (Remote Direct Memory Access) protocols to provide capabilities in support of enhanced remotely-directed data placement on memory-addressable devices, including persistent memory. The extensions include new operations supporting remote commitment to persistence of remotely-managed buffers, which can provide enhanced guarantees and improve performance for low-latency storage applications, and to the visibility of such buffers in support of remote shared memory semantics. This document updates RFC 5040 (Remote Direct Memory Access Protocol (RDMAP)) and updates RFC 7306 (RDMA Protocol Extensions). | ||||||||||||||||
| draft-tan-detnet-cap-discovery-00.txt | |||||||||||||||||
| Echo Request/Reply for DetNet Capability Discovery | |||||||||||||||||
|
This document describes an extension to the echo request/reply mechanisms used in IP, MPLS or other DetNet data plane environments, which can be used within the DetNet domain, allowing the ping initiator node to discover the enabled DetNet capabilities of each relay node of detnet service-sub layer, which including discovering DetNet relay nodes, collecting DetNet service sub-layer specific information from DetNet relay nodes, as well as discovering the locations of PREOF functions. | ||||||||||||||||
| draft-tan-pce-detnet-high-reliability-00.txt | |||||||||||||||||
| PCEP Extension for DetNet High Reliability | |||||||||||||||||
|
Real-time network performance information, like latency, delay variation, packet loss and in order delivery, is becoming critical in the path computation in some networks. This document propose metric extensions to PCEP messages, to better describe the path computation constraints and QoS requirements of Deterministic Networking (DetNet) flows, especially the high reliability requirements on packet loss and in order delivery. PCEP Extensions defined in this document could be used not only for DetNet, but also for other PCEP scenarios. | ||||||||||||||||
| draft-tang-ipv4plus-10.txt | |||||||||||||||||
| IPv4+ The Extended Protocol Based On IPv4 | |||||||||||||||||
|
This document specifies version 4+ of the Internet Protocol (IPv4+). IPv4 is very successful,simple and elegant. continuation and expansion of the IPv4 is necessary. Existing systems, devices only need to upgrade the software to support IPv4+, without the need to update new hardwares,saving investment costs. Ipv4+ is also an interstellar Protocol, so the Internet will evolve into a star Internet. | ||||||||||||||||
| draft-taylor-tvr-prb-stmt-00.txt | |||||||||||||||||
| Time Variant Routing Problem Statement | |||||||||||||||||
|
Existing Routing Protocols expect to maintain contemporaneous, end- to-end connected paths across a network. Changes to that connectivity, such as the loss of an adjacent peer, are considered to be exceptional circumstances that must be corrected prior to the resumption of data transmission. Corrections may include attempting to re-establish lost adjacencies and recalculating or rediscovering a functional topology. However, there are a growing number of use-cases where changes to the routing topology are an expected part of network operations. In these cases the pre-planned loss and restoration of an adjacency, or formation of an alternate adjacency, should be seen as a non- disruptive event. This document attempts to describe the problems perceived with existing routing protocols and act as a "Problem Statement" to be addressed by the proposed Time-Variant Routing (TVR) working group. Readers are recommended to read this document alongside the TVR (Time-Variant Routing) Use Cases (https://datatracker.ietf.org/doc/ draft-birrane-tvr-use-cases/). | ||||||||||||||||
| draft-taylor-uuid-ncname-03.txt | |||||||||||||||||
| Compact UUIDs for Constrained Grammars | |||||||||||||||||
|
The Universally Unique Identifier is a suitable standard for, as the name suggests, uniquely identifying entities in a symbol space large enough that the identifiers do not collide. Many formal grammars, however, are too restrictive to permit the use of UUIDs in their canonical representation (described in RFC 4122 and elsewhere), despite it being useful to do so. This document specifies an alternative compact representation for UUIDs that preserves some properties of the canonical form, with three encoding varietals, to fit these more restrictive contexts. | ||||||||||||||||
| draft-teigen-ippm-app-quality-metric-reqs-01.txt | |||||||||||||||||
| Requirements for a Network Quality Framework Useful for Applications,Users,and Operators | |||||||||||||||||
|
This document describes the features and attributes a network quality framework must have to be useful for different stakeholders. The stakeholders included are developers of Applications, End-Users, and Network Operators and Vendors. At a high level, End-Users need an understandable network metric. Application developers need a network metric that allows them to evaluate how well their application is likely to perform given the measured network performance. Network Operators and Vendors need a metric that facilitates troubleshooting and optimization of their networks. Existing network quality metrics and frameworks typically address the needs of one or two of these stakeholders, but we have yet to find one that bridges the needs of all three. | ||||||||||||||||
| draft-templin-intarea-aero-28.txt | |||||||||||||||||
| Automatic Extended Route Optimization (AERO) | |||||||||||||||||
|
This document specifies an Automatic Extended Route Optimization (AERO) service for IP internetworking over Overlay Multilink Network (OMNI) interfaces. AERO/OMNI use an IPv6 unique-local address format for IPv6 Neighbor Discovery (IPv6 ND) messaging over the OMNI virtual link. Router discovery and neighbor coordination are employed for network admission and to manage the OMNI link forwarding and routing systems. Secure multilink path selection, multinet traversal, mobility management, multicast forwarding, multihop operation and route optimization are naturally supported through dynamic neighbor cache updates. AERO is a widely-applicable mobile internetworking service especially well-suited to aviation, intelligent transportation systems, mobile end user devices and many other applications. | ||||||||||||||||
| draft-templin-intarea-omni-28.txt | |||||||||||||||||
| Transmission of IP Packets over Overlay Multilink Network (OMNI) Interfaces | |||||||||||||||||
|
Mobile nodes (e.g., aircraft of various configurations, terrestrial vehicles, seagoing vessels, space systems, enterprise wireless devices, pedestrians with cell phones, etc.) communicate with networked correspondents over wireless and/or wired-line data links and configure mobile routers to connect end user networks. This document presents a multilink virtual interface specification that enables mobile nodes to coordinate with a network-based mobility service, fixed node correspondents and/or other mobile node peers. The virtual interface provides an adaptation layer service that also applies for both mobile and more static deployments such as enterprise and home networks. This document specifies the transmission of IP packets over Overlay Multilink Network (OMNI) Interfaces. | ||||||||||||||||
| draft-templin-intarea-parcels-62.txt | |||||||||||||||||
| IP Parcels and Advanced Jumbos | |||||||||||||||||
|
IP packets (both IPv4 and IPv6) contain a single unit of transport layer protocol data which becomes the retransmission unit in case of loss. Transport layer protocols including the Transmission Control Protocol (TCP) and reliable transport protocol users of the User Datagram Protocol (UDP) prepare data units known as "segments", with individual IP packets including only a single segment. This document presents new constructs known as "IP Parcels" and "Advanced Jumbos". IP parcels permit a single packet to carry multiple transport layer protocol segments in a "packet-of-packets", while advanced jumbos provide significant operational advantages over standard jumbograms for carrying truly large singleton segments. IP parcels and advanced jumbos provide essential building blocks for improved performance, efficiency and integrity while encouraging larger Maximum Transmission Units (MTUs) in the Internet. | ||||||||||||||||
| draft-temporal-uri-scheme-00.txt | |||||||||||||||||
| Temporal URI scheme | |||||||||||||||||
|
This document registers the "dt" URI scheme, to unambiguously identify a discrete point in time. Note to Readers _RFC EDITOR: please remove this section before publication_ The issues list for this draft can be found at https://github.com/xquery/temporal-uri-scheme (https://github.com/xquery/temporal-uri-scheme). * Editor's Copy (https://xquery.github.io/temporal-uri- scheme/#go.draft-todo-temporal-uri-scheme.html) * Datatracker Page (https://datatracker.ietf.org/doc/draft-todo- temporal-uri-scheme) | ||||||||||||||||
| draft-tgraf-netconf-notif-sequencing-01.txt | |||||||||||||||||
| Support of Hostname and Sequencing in YANG Notifications | |||||||||||||||||
|
This document specifies a new YANG module that augment the NETCONF Event Notification header to support hostname, publisher ID and sequence numbers to identify from which network node and at which time the message was published. This allows the collector to recognize loss, delay and reordering between the publisher and the downstream system storing the message. | ||||||||||||||||
| draft-tgraf-netconf-yang-notifications-versioning-03.txt | |||||||||||||||||
| Support of Versioning in YANG Notifications Subscription | |||||||||||||||||
|
This document extends the YANG notifications subscription mechanism to specify the YANG module semantic version at the subscription. Then, a new extension with the revision and the semantic version of the YANG push subscription state change notification is proposed. | ||||||||||||||||
| draft-tgraf-yang-push-observation-time-00.txt | |||||||||||||||||
| Support of Network Observation Timestamping in YANG Notifications | |||||||||||||||||
|
This document extends the YANG Notification header with the YANG objects observation timestamping, both for the "push-update" and "push-change-update" notifications. | ||||||||||||||||
| draft-thaler-bpf-elf-00.txt | |||||||||||||||||
| eBPF ELF Profile Specification,v0.1 | |||||||||||||||||
|
The Executable and Linking Format (ELF) is specified in Chapter 4 of the System V Application Binary Interface. This document specifies version 0.1 of the eBPF profile for ELF files. | ||||||||||||||||
| draft-thaler-bpf-isa-00.txt | |||||||||||||||||
| eBPF Instruction Set Specification,v1.0 | |||||||||||||||||
|
This document specifies version 1.0 of the eBPF instruction set. The eBPF instruction set consists of eleven 64 bit registers, a program counter, and an implementation-specific amount (e.g., 512 bytes) of stack space. | ||||||||||||||||
| draft-thejeswara-tcpm-tcp-fwa-00.txt | |||||||||||||||||
| TCP FWA: Fast Window Advance for TCP | |||||||||||||||||
|
This document describes TCP Fast Window Advance (FWA) flag in TCP Header to avoid the Head of Line Blocking in TCP long alive connections and in TCP long fat networks. FWA flag shall be set by the sender to force the TCP receiver to change its expected sequence number. This allows the application sender to send fresh application session to receiver on the existing TCP connection without blocking on the earlier session. The FWA flag is will solve long standing Head of Line (HOL) blocking problem in TCP for certain TCP applications. | ||||||||||||||||
| draft-theo-hesp-04.txt | |||||||||||||||||
| HESP - High Efficiency Streaming Protocol | |||||||||||||||||
|
This document describes a protocol for delivering multimedia data, enabling ultra-low latency and fast channel change over HTTP networks. It specifies the data format of the files and the actions to be taken by the server (sender) and the clients (receivers) of the streams. It describes version 2 of this protocol. | ||||||||||||||||
| draft-thomassen-dnsop-cds-consistency-03.txt | |||||||||||||||||
| Consistency for CDS/CDNSKEY and CSYNC is Mandatory | |||||||||||||||||
|
Maintenance of DNS delegations requires occasional changes of the DS and NS record sets on the parent side of the delegation. [RFC7344] automates this for DS records by having the child publish CDS and/or CDNSKEY records which hold the prospective DS parameters. Similarly, CSYNC records indicate a desired update of the delegation's NS records [RFC7477]. Parent-side entities (e.g. Registries, Registrars) typically discover these records by periodically querying them from the child ("polling"), before using them to update the delegation's parameters. This document specifies that if polling is used, parent-side entities MUST ensure that updates triggered via CDS/CDNSKEY and CSYNC records are consistent across the child's authoritative nameservers, before taking any action based on these records. | ||||||||||||||||
| draft-thomassen-dnsop-generalized-dns-notify-01.txt | |||||||||||||||||
| Generalized DNS Notifications | |||||||||||||||||
|
Changes in CDS/CDNSKEY, CSYNC, and other records related to delegation maintenance are usually detected through scheduled scans run by the consuming party (e.g. top-level domain registry), incurring an uncomfortable trade-off between scanning cost and update latency. A similar problem exists when scheduling zone transfers, and has been solved using the well-known DNS NOTIFY mechanism ([RFC1996]). This mechanism enables a primary nameserver to proactively inform secondaries about zone changes, allowing the secondary to initiate an ad-hoc transfer independently of when the next SOA check would be due. This document extends the use of DNS NOTIFY beyond conventional zone transfer hints, bringing the benefits of ad-hoc notifications to DNS delegation maintenance in general. Use cases include DNSSEC key rollovers hints via NOTIFY(CDS) and NOTIFY(DNSKEY) messages, and quicker changes to a delegation's NS record set via NOTIFY(CSYNC) messages. Furthermore, this document proposes a new DNS record type, tentatively referred to as "NOTIFY record", which is used to publish details about where generalized notifications should be sent. TO BE REMOVED: This document is being collaborated on in Github at: https://github.com/peterthomassen/draft-thomassen-dnsop-generalized- dns-notify (https://github.com/peterthomassen/draft-thomassen-dnsop- generalized-dns-notify). The most recent working version of the document, open issues, etc. should all be available there. The authors (gratefully) accept pull requests. | ||||||||||||||||
| draft-thomassen-dnsop-mske-00.txt | |||||||||||||||||
| DNSSEC Multi-Signer Key Exchange (MSKE) | |||||||||||||||||
|
Answering DNSKEY/CDS/CDNSKEY queries in an [RFC8901] multi-signer DNSSEC configuration requires all operators to serve not only their own public key information, but also include each other's public keys. This ensures that clients obtain a consistent view of the DNSSEC configuration regardless of who is answering a given query. In order to enable operators to import the keys needed for assembling these responses, a method for discovering them is necessary. This document specifies how DNS operators can announce which are the keys they intend to use for signing a given zone (DNSKEY) and which keys are designated for secure entry into the zone (CDS/CDNSKEY). It further introduces the CNS record type to facilitate proactive discovery of the aforementioned signals. Taken together, these parts function as an authenticated multi-signer key-exchange (MSKE) scheme. This MSKE mechanism uses the signaling mechanism introduced in [I-D.ietf-dnsop-dnssec-bootstrapping] to complete the automated workflows described in [I-D.ietf-dnsop-dnssec-automation]. | ||||||||||||||||
| draft-thomson-httpbis-alt-svcb-01.txt | |||||||||||||||||
| HTTP Alternative Services,Plan B | |||||||||||||||||
|
HTTP servers deployments that include multiple service endpoints can use alternative services to direct clients to use a different service endpoint. This document obsoletes RFC 7838. | ||||||||||||||||
| draft-thomson-quic-enough-00.txt | |||||||||||||||||
| Signaling That a QUIC Receiver Has Enough Stream Data | |||||||||||||||||
|
Sending on QUIC streams can only be aborted early by the sender with a RESET_STREAM frame. This document describes how a receiver can indicate when the data they have received is enough, allowing the sender to reliably deliver some data, but abort sending for anything more than the indicated amount. | ||||||||||||||||
| draft-thomson-tls-keylogfile-00.txt | |||||||||||||||||
| The SSLKEYLOGFILE Format for TLS | |||||||||||||||||
|
A format that supports the logging information about the secrets used in a TLS connection is described. Recording secrets to a file in SSLKEYLOGFILE format allows diagnostic and logging tools that use this file to decrypt messages exchanged by TLS endpoints. | ||||||||||||||||
| draft-thomson-webtrans-session-limit-00.txt | |||||||||||||||||
| Applying Per-Session Limits for WebTransport | |||||||||||||||||
|
Limits to how a WebTransport session uses QUIC resources like streams or data can help limit the effect that one WebTransport session has on other uses of the same HTTP/3 connection. This describes mechanisms for limiting the number of streams and quantity of data that can be consumed by each WebTransport session. | ||||||||||||||||
| draft-thubert-6lo-prefix-registration-02.txt | |||||||||||||||||
| IPv6 Neighbor Discovery Prefix Registration | |||||||||||||||||
|
This document updates the 6LoWPAN extensions to IPv6 Neighbor Discovery (RFC 8505) to enable a node that owns or is directly connected to a prefix to register that prefix to neighbor routers. The registration indicates that the registered prefix can be reached via the advertising node without a loop. The prefix registration also provides a protocol-independent interface for the node to request neighbor router(s) to redistribute the prefix to the larger routing domain using their specific routing protocols. As an example, this document extends RFC 9010 to enable the 6LR to inject the registered prefix in RPL. | ||||||||||||||||
| draft-thubert-schc-over-ppp-00.txt | |||||||||||||||||
| SCHC over PPP | |||||||||||||||||
|
This document extends RFC 5172 to signal the use of SCHC as the compression method between a pair of nodes over PPP. Combined with RFC 2516, this enables the use of SCHC over Ethernet and Wi-Fi. | ||||||||||||||||
| draft-tian-spring-srv6-deployment-consideration-07.txt | |||||||||||||||||
| SRv6 Deployment Consideration | |||||||||||||||||
|
SRv6 has significant advantages over SR-MPLS and has attracted more and more attention and interest from network operators and verticals. Smooth network migration towards SRv6 is a key focal point and this document provides network design and migration guidance and recommendations on solutions in various scenarios. Deployment cases with SRv6 are also introduced. | ||||||||||||||||
| draft-tigress-gssapi-impl-00.txt | |||||||||||||||||
| Tigress-GSS API-Sample Implementation | |||||||||||||||||
|
This document describes a sample implementation of transferring digital credentials securily (Tigress) using GSS API. About This Document This note is to be removed before publishing as an RFC. The latest revision of this draft can be found at https://datatracker.ietf.org/doc/draft-tigress-gssapi-impl/. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-tigress-gssapi-impl/. Source for this draft and an issue tracker can be found at https://github.com/dimmyvi/tigress-requirements. | ||||||||||||||||
| draft-tigress-requirements-09.txt | |||||||||||||||||
| Transfer Digital Credentials Securely - Requirements | |||||||||||||||||
|
This document describes the use cases necessitating the secure transfer of Digital Credentials, residing in a Digital Wallet, between two devices and defines general assumptions, requirements and the scope for possible solutions to this problem. | ||||||||||||||||
| draft-tigress-sample-implementation-01.txt | |||||||||||||||||
| Transfer Digital Credentials Securely: sample implementation and threat model | |||||||||||||||||
|
This document describes a sample implementation of Tigress internet draft [Tigress-00] and a threat model of this implementation. | ||||||||||||||||
| draft-tigress-signal-impl-00.txt | |||||||||||||||||
| Tigress-Signal-Sample Implementation | |||||||||||||||||
|
This document describes a sample implementation of transferring digital credentials securily (Tigress) using Signal protocol. About This Document This note is to be removed before publishing as an RFC. The latest revision of this draft can be found at https://datatracker.ietf.org/doc/draft-tigress-signal-impl/. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-tigress-signal-impl/. Source for this draft and an issue tracker can be found at https://github.com/dimmyvi/tigress-requirements. | ||||||||||||||||
| draft-tigress-webdav-impl-00.txt | |||||||||||||||||
| Tigress-WebDAV-Sample Implementation | |||||||||||||||||
|
This document describes a sample implementation of transferring digital credentials securily (Tigress) using WebDAV protocol. About This Document This note is to be removed before publishing as an RFC. The latest revision of this draft can be found at https://datatracker.ietf.org/doc/draft-tigress-webdav-impl/. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-tigress-webdav-impl/. Source for this draft and an issue tracker can be found at https://github.com/dimmyvi/tigress-requirements. | ||||||||||||||||
| draft-tiloca-ace-group-oscore-profile-10.txt | |||||||||||||||||
| The Group Object Security for Constrained RESTful Environments (Group OSCORE) Profile of the Authentication and Authorization for Constrained Environments (ACE) Framework | |||||||||||||||||
|
This document specifies a profile for the Authentication and Authorization for Constrained Environments (ACE) framework. The profile uses Group OSCORE to provide communication security between a Client and a (set of) Resource Server(s) as members of an OSCORE Group. The profile securely binds an OAuth 2.0 Access Token with the public key of the Client associated with the private key used in the OSCORE group. The profile uses Group OSCORE to achieve server authentication, as well as proof-of-possession for the Client's public key. Also, it provides proof of the Client's membership to the OSCORE group, by binding the Access Token to information from the Group OSCORE Security Context, thus allowing the Resource Server(s) to verify the Client's membership upon receiving a message protected with Group OSCORE from the Client. | ||||||||||||||||
| draft-tiloca-core-groupcomm-proxy-08.txt | |||||||||||||||||
| Proxy Operations for CoAP Group Communication | |||||||||||||||||
|
This document specifies the operations performed by a proxy, when using the Constrained Application Protocol (CoAP) in group communication scenarios. Such a proxy processes a single request sent by a client over unicast, and distributes the request over IP multicast to a group of servers. Then, the proxy collects the individual responses from those servers and relays those responses back to the client, in a way that allows the client to distinguish the responses and their origin servers through embedded addressing information. This document updates RFC7252 with respect to caching of response messages at proxies. | ||||||||||||||||
| draft-tiloca-core-oscore-capable-proxies-06.txt | |||||||||||||||||
| OSCORE-capable Proxies | |||||||||||||||||
|
Object Security for Constrained RESTful Environments (OSCORE) can be used to protect CoAP messages end-to-end between two endpoints at the application layer, also in the presence of intermediaries such as proxies. This document defines how to use OSCORE for protecting CoAP messages also between an origin application endpoint and an intermediary, or between two intermediaries. Also, it defines how to secure a CoAP message by applying multiple, nested OSCORE protections, e.g., both end-to-end between origin application endpoints, as well as between an application endpoint and an intermediary or between two intermediaries. Thus, this document updates RFC 8613. The same approach can be seamlessly used with Group OSCORE, for protecting CoAP messages when group communication with intermediaries is used. | ||||||||||||||||
| draft-tiloca-core-oscore-discovery-13.txt | |||||||||||||||||
| Discovery of OSCORE Groups with the CoRE Resource Directory | |||||||||||||||||
|
Group communication over the Constrained Application Protocol (CoAP) can be secured by means of Group Object Security for Constrained RESTful Environments (Group OSCORE). At deployment time, devices may not know the exact security groups to join, the respective Group Manager, or other information required to perform the joining process. This document describes how a CoAP endpoint can use descriptions and links of resources registered at the CoRE Resource Directory to discover security groups and to acquire information for joining them through the respective Group Manager. A given security group may protect multiple application groups, which are separately announced in the Resource Directory as sets of endpoints sharing a pool of resources. This approach is consistent with, but not limited to, the joining of security groups based on the ACE framework for Authentication and Authorization in constrained environments. | ||||||||||||||||
| draft-tiloca-schc-8824-update-00.txt | |||||||||||||||||
| Clarifications and Updates on using Static Context Header Compression (SCHC) for the Constrained Application Protocol (CoAP) | |||||||||||||||||
|
This document clarifies, updates and extends the method specified in RFC 8824 for compressing Constrained Application Protocol (CoAP) headers using the Static Context Header Compression and fragmentation (SCHC) framework. In particular, it considers recently defined CoAP options and specifies how CoAP headers are compressed in the presence of intermediaries. Therefore, this document updates RFC 8824. | ||||||||||||||||
| draft-timbru-sidrops-change-pubserver-00.txt | |||||||||||||||||
| Change Publication Server used by an RPKI CA | |||||||||||||||||
|
This draft outlines how Krill, an RPKI CA and Publication Server, implements the process that allows a CA to change the Publication Server it uses, migrating its content from the old server, to the new server's repository. The current implementation is modelled after the RPKI CA Key Rollover process defined in RFC 6489, except that in this case a new location is used for the new key. It incudes some discussion about possible improvements to the process. The goal of this draft is to serve as a starting point for a broader discussion on how RPKI Repository Migration should be done. If adopted as a working group item, the status could be changed to standard or bcp, and the intent would of course be to update the content to reflect working group consensus rather than what happens to have been implemented in Krill at this time. | ||||||||||||||||
| draft-timbru-sidrops-rpki-publication-v2-00.txt | |||||||||||||||||
| RPKI Publication Protocol Version 2 | |||||||||||||||||
|
The RPKI Publication Protocol first described in RFC 8181 has worked very well. That said, as it turns out, there are a number of requirements emerging from operational experience which cannot be supported by the current protocol. In particular, identity key roll overs, support for publication quota and stricter verification of content by the server. This document is an early write-up with the following goals: (1) support discussions about requirements for additional work and (2) explore a possible version 2 with solutions to meet those requirements. | ||||||||||||||||
| draft-tjiang-dmm-5g-dupf-5mbs-01.txt | |||||||||||||||||
| 5G Distributed UPFs for 5G Multicast and Broadcast Services (5MBS) | |||||||||||||||||
|
The drafts [I-D.zzhang-dmm-5g-distributed-upf] and [I-D.zzhang-dmm-mup-evolution] have described the 5G mobile user plane (MUP) via the refinement of distributed UPFs and a more radical proposal by integrating gNB & UPF as a single network function (NF). Some user plane implementation requirements that vendors and operators are exploring are not introducing changes to 3GPP architecture & signaling, if possible. The document 3GPP TS 23.247 [_3GPP-23.247] for 5G multicast and broadcast services, or 5MBS, specifies the 5GS architecture to support MBS communication. Thanks to the addition of new 5GS network functions (NFs) and MB-interfaces on 5G CP & UP, specifically if coupled with the increasingly popular satellite-related requirements, these would certainly post additional provisioning & implementation challenges to the underlay transport infrastructure. This document is not an attempt to do 3GPP SDO work in IETF. Instead, it discusses how to potentially integrate distributed UPFs with the delivery of 5MBS communication, as well as the benefits of using distributed UPFs to handle 5MBS traffic delivery. | ||||||||||||||||
| draft-tjw-dbound2-problem-statement-00.txt | |||||||||||||||||
| Domain Boundaries 2.0 Problem Statement | |||||||||||||||||
|
Internet clients attempt to make inferences about the administrative relationship based on domain names. Currently it is not possible to confirm organizational boundaries in the DNS. Current mitigation strategies have there own issues. This memo attempts to outline these issues. | ||||||||||||||||
| draft-tllq-tsr-03.txt | |||||||||||||||||
| Multicast DNS conflict resolution using the Time Since Received (TSR) RR | |||||||||||||||||
|
This document specifies a new conflict resolution mechanism for DNS, for use in cases where the advertisement is being proxied, rather than advertised directly, e.g. when using a combined DNS-SD Advertising Proxy and SRP registrar. A new DNS RR is defined that communicates the time at which the set of resource records on a particular DNS owner name was most recently updated. | ||||||||||||||||
| draft-tls-westerbaan-xyber768d00-02.txt | |||||||||||||||||
| X25519Kyber768Draft00 hybrid post-quantum key agreement | |||||||||||||||||
|
This memo defines X25519Kyber768Draft00, a hybrid post-quantum key exchange for TLS 1.3. | ||||||||||||||||
| draft-todo-temporal-uri-scheme-02.txt | |||||||||||||||||
| Temporal URI scheme | |||||||||||||||||
|
This document registers the "dt" URI scheme, to unambiguously identify a discrete point in time. Note to Readers _RFC EDITOR: please remove this section before publication_ The issues list for this draft can be found at https://github.com/xquery/temporal-uri-scheme (https://github.com/xquery/temporal-uri-scheme). * Editor's Copy (https://xquery.github.io/temporal-uri- scheme/#go.draft-todo-temporal-uri-scheme.html) * Datatracker Page (https://datatracker.ietf.org/doc/draft-todo- temporal-uri-scheme) * Working Group Draft (https://datatracker.ietf.org/doc/html/draft- todo-temporal-uri-scheme) * Compare Editor's Copy to Working Group Draft (https://xquery.github.io/temporal-uri-scheme/#go.draft-todo- temporal-uri-scheme.diff) | ||||||||||||||||
| draft-touch-tcpm-tcp-syn-ext-opt-12.txt | |||||||||||||||||
| TCP SYN Extended Option Space Using an Out-of-Band Segment | |||||||||||||||||
|
This document describes an experimental method to extend the option space for connection parameters within the initial TCP SYN segment, at the start of a TCP connection. This method effectively extends the option space of an initial SYN by using an additional coupled segment that is sent 'out-of-band'. It complements the proposed Extended Data Offset (EDO) option that is applicable only after the initial segment. | ||||||||||||||||
| draft-toutain-lpwan-access-control-01.txt | |||||||||||||||||
| SCHC Rule Access Control | |||||||||||||||||
|
The framework for SCHC defines an abstract view of the rules, formalized with through a YANG Data Model. In its original description rules are static and share by 2 entities. The use of YANG authorizes rules to be uploaded or modified in a SCHC instance and leads to some possible attacks, if the changes are not controlled. This document summarizes some possible attacks and define augmentation to the existing Data Mode, to restrict the changes in the rule. | ||||||||||||||||
| draft-toutain-lpwan-sid-allocation-02.txt | |||||||||||||||||
| SCHC Rule Access Control | |||||||||||||||||
|
blabla | ||||||||||||||||
| draft-toutain-schc-access-control-00.txt | |||||||||||||||||
| SCHC Rule Access Control | |||||||||||||||||
|
The framework for SCHC defines an abstract view of the rules, formalized with through a YANG Data Model. In its original description rules are static and share by 2 entities. The use of YANG authorizes rules to be uploaded or modified in a SCHC instance and leads to some possible attacks, if the changes are not controlled. This document summarizes some possible attacks and define augmentation to the existing Data Mode, to restrict the changes in the rule. | ||||||||||||||||
| draft-toutain-schc-sid-allocation-00.txt | |||||||||||||||||
| SCHC Sid Allocation | |||||||||||||||||
|
blabla | ||||||||||||||||
| draft-trossen-rtgwg-rosa-02.txt | |||||||||||||||||
| Routing on Service Addresses | |||||||||||||||||
|
This document proposes a novel communication approach which reasons about WHAT is being communicated (and invoked) instead of WHO is communicating. Such approach is meant to transition away from locator-based addressing (and thus routing and forwarding) to an addressing scheme where the address semantics relate to services being invoked (e.g., for computational processes, and their generated information requests and responses). The document introduces Routing on Service Addresses (ROSA), as a realization of what is referred to as 'service-based routing' (SBR), to replace the usual DNS+IP sequence, i.e., the off-path discovery of a service name to an IP locator mapping, through an on-path discovery with in-band data transfer to a suitable service instance location for a selected set of services, not all Internet-based services. SBR is designed to be constrained by service-specific parameters that go beyond load and latency, as in today's best effort or traffic engineering based routing, leading to an approach to steer traffic in a service-specific constraint-based manner. Particularly, this document outlines sample ROSA use case scenarios, requirements for its design, and the ROSA system design itself. | ||||||||||||||||
| draft-trr-bess-bgp-srv6-args-01.txt | |||||||||||||||||
| SRv6 Argument Signaling for BGP Services | |||||||||||||||||
|
RFC9252 defines procedures and messages for SRv6-based BGP services including L3VPN, EVPN, and Internet services. This document updates RFC9252 and provides more detailed specifications for the signaling and processing of SRv6 SID advertisements for BGP Service routes associated with SRv6 Endpoint Behaviors that support arguments. | ||||||||||||||||
| draft-tschofenig-rats-psa-token-11.txt | |||||||||||||||||
| Arm's Platform Security Architecture (PSA) Attestation Token | |||||||||||||||||
|
The Platform Security Architecture (PSA) is a family of hardware and firmware security specifications, as well as open-source reference implementations, to help device makers and chip manufacturers build best-practice security into products. Devices that are PSA compliant are able to produce attestation tokens as described in this memo, which are the basis for a number of different protocols, including secure provisioning and network access control. This document specifies the PSA attestation token structure and semantics. The PSA attestation token is a profiled Entity Attestation Token (EAT). This specification describes what claims are used in an attestation token generated by PSA compliant systems, how these claims get serialized to the wire, and how they are cryptographically protected. | ||||||||||||||||
| draft-tsou-behave-ftp46-01.txt | |||||||||||||||||
| An FTP Application Layer Gateway (ALG) for IPv4-to-IPv6 Translation | |||||||||||||||||
|
An FTP ALG for NAT64 was defined in RFC 6384. Its scope was limited to an IPv6 client connecting to an IPv4 server. This memo supports the case of an IPv4 client connecting to an IPv6 server. | ||||||||||||||||
| draft-tsou-softwire-port-set-algorithms-analysis-04.txt | |||||||||||||||||
| Analysis of Algorithms For Deriving Port Sets | |||||||||||||||||
|
This memo analyzes some port set definition algorithms used for stateless IPv4 to IPv6 transition technologies. The transition technologies using port set algorithms can be divided into two categories: fully stateless approach and binding approach. Some algorithms can work for both approaches. | ||||||||||||||||
| draft-tu-nmrg-blockchain-trusted-protocol-01.txt | |||||||||||||||||
| A Blockchain Trusted Protocol for Intelligent Communication Network | |||||||||||||||||
|
This document defines a blockchain-based trusted protocol for sixth- generation (6G) intelligent communication network. | ||||||||||||||||
| draft-tuexen-tsvwg-rfc4895-bis-03.txt | |||||||||||||||||
| Authenticated Chunks for the Stream Control Transmission Protocol (SCTP) | |||||||||||||||||
|
This document describes a new chunk type, several parameters, and procedures for the Stream Control Transmission Protocol (SCTP). This new chunk type can be used to authenticate SCTP chunks by using shared keys between the sender and receiver. The new parameters are used to establish the shared keys. | ||||||||||||||||
| draft-tuexen-tsvwg-rfc6951-bis-03.txt | |||||||||||||||||
| UDP Encapsulation of Stream Control Transmission Protocol (SCTP) Packets for End-Host to End-Host Communication | |||||||||||||||||
|
This document describes a simple method of encapsulating Stream Control Transmission Protocol (SCTP) packets into UDP packets and its limitations. This allows the usage of SCTP in networks with legacy NATs that do not support SCTP. It can also be used to implement SCTP on hosts without directly accessing the IP layer, for example, implementing it as part of the application without requiring special privileges. Please note that this document only describes the functionality needed within an SCTP stack to add on UDP encapsulation, providing only those mechanisms for two end-hosts to communicate with each other over UDP ports. In particular, it does not provide mechanisms to determine whether UDP encapsulation is being used by the peer, nor the mechanisms for determining which remote UDP port number can be used. These functions are out of scope for this document. This document covers only end-hosts and not tunneling (egress or ingress) endpoints. | ||||||||||||||||
| draft-tuexen-tsvwg-sctp-init-fwd-01.txt | |||||||||||||||||
| INIT Forwarding for the Stream Control Transmission Protocol | |||||||||||||||||
|
The Stream Control Transmission Protocol (SCTP) extension described in this document allows the support of a simple mechanism to distribute association requests between a cluster of SCTP end points providing the same service. In particular, this allows the use of anycast addresses in combination with SCTP. | ||||||||||||||||
| draft-tuexen-tsvwg-sctp-multipath-25.txt | |||||||||||||||||
| Load Sharing for the Stream Control Transmission Protocol (SCTP) | |||||||||||||||||
|
The Stream Control Transmission Protocol (SCTP) supports multi-homing for providing network fault tolerance. However, mainly one path is used for data transmission. Only timer-based retransmissions are carried over other paths as well. This document describes how multiple paths can be used simultaneously for transmitting user messages. | ||||||||||||||||
| draft-tuexen-tsvwg-sctp-udp-encaps-cons-07.txt | |||||||||||||||||
| Additional Considerations for UDP Encapsulation of Stream Control Transmission Protocol (SCTP) Packets | |||||||||||||||||
|
RFC 6951 specifies the UDP encapsulation of SCTP packets. The described handling of received packets requires the check of the verification tag. However, RFC 6951 misses a specification of the handling of received packets for which this check is not possible. This document updates RFC 6951 by specifying the handling of received packets for which the verification tag can not be checked. | ||||||||||||||||
| draft-tuexen-tsvwg-sctp-zero-checksum-02.txt | |||||||||||||||||
| Zero Checksum for the Stream Control Transmission Protocol | |||||||||||||||||
|
The Stream Control Transmission Protocol (SCTP) uses a 32-bit checksum in the common header of each packet to provide some level of data integrity. When the lower layer used by SCTP provides already the same or a higher level of data integrity, computing this checksum does not provide any additional protection, but does require computing resources. This document provides a simple extension to SCTP allowing to save these computing resources by using the constant 0 as the checksum in a backwards compatible way. | ||||||||||||||||
| draft-uberti-rtcweb-rfc8829bis-04.txt | |||||||||||||||||
| JavaScript Session Establishment Protocol (JSEP) | |||||||||||||||||
|
This document describes the mechanisms for allowing a JavaScript application to control the signaling plane of a multimedia session via the interface specified in the W3C RTCPeerConnection API and discusses how this relates to existing signaling protocols. This specification obsoletes RFC 8829. | ||||||||||||||||
| draft-uni-qsckeys-dilithium-00.txt | |||||||||||||||||
| Quantum Safe Cryptography Key Information for CRYSTALS-Dilithium | |||||||||||||||||
|
This proposal defines key management approaches for the Quantum Safe Cryptographic (QSC) algorithm CRYSTALS-Dilithium which has been selected for standardization by the NIST Post Quantum Cryptography (PQC) process. This includes key identification, key serialization, and key compression. The purpose is to provide guidance such that the adoption of quantum safe algorithms is not hampered with the fragmented evolution of necessary key management standards. Early definition of key material standards will help expedite the adoption of new quantum safe algorithms and at the same time as improving interoperability between implementations and minimizing divergence across standards. | ||||||||||||||||
| draft-uni-qsckeys-falcon-00.txt | |||||||||||||||||
| Quantum Safe Cryptography Key Information for FALCON | |||||||||||||||||
|
This proposal defines key management approaches for the Quantum Safe Cryptographic (QSC) algorithm FALCON which has been selected for standardization by the NIST Post Quantum Cryptography (PQC) process. This includes key identification and key serialization. The purpose is to provide guidance such that the adoption of quantum safe algorithms is not hampered with the fragmented evolution of necessary key management standards. Early definition of key material standards will help expedite the adoption of new quantum safe algorithms and at the same time as improving interoperability between implementations and minimizing divergence across standards. | ||||||||||||||||
| draft-uni-qsckeys-kyber-00.txt | |||||||||||||||||
| Quantum Safe Cryptography Key Information for CRYSTALS-Kyber | |||||||||||||||||
|
This proposal defines key management approaches for the Quantum Safe Cryptographic (QSC) algorithm CRYSTALS-Kyber which has been selected for standardization by the NIST Post Quantum Cryptography (PQC) process. This includes key identification, key serialization, and key compression. The purpose is to provide guidance such that the adoption of quantum safe algorithms is not hampered with the fragmented evolution of necessary key management standards. Early definition of key material standards will help expedite the adoption of new quantum safe algorithms and at the same time as improving interoperability between implementations and minimizing divergence across standards. | ||||||||||||||||
| draft-uni-qsckeys-sphincsplus-00.txt | |||||||||||||||||
| Quantum Safe Cryptography Key Information for SPHINCS-PLUS | |||||||||||||||||
|
This proposal defines key management approaches for the Quantum Safe Cryptographic (QSC) algorithm SPHINCS+ (or SPHINCS-PLUS) which has been selected for standardization by the NIST Post Quantum Cryptography (PQC) process. This includes key identification and key serialization. The purpose is to provide guidance such that the adoption of quantum safe algorithms is not hampered with the fragmented evolution of necessary key management standards. Early definition of key material standards will help expedite the adoption of new quantum safe algorithms at the same time as improving interoperability between implementations and minimizing divergence across standards. | ||||||||||||||||
| draft-urien-coin-sec-00.txt | |||||||||||||||||
| COIN Security | |||||||||||||||||
|
This draft introduces some security issues for COIN systems. | ||||||||||||||||
| draft-urien-coinrg-iose-07.txt | |||||||||||||||||
| Internet of Secure Elements | |||||||||||||||||
|
This draft defines an infrastructure for secure elements over internet, and features needed for their secure remote use. It describes a network architecture based on the TLS 1.3 protocol, which enables remote calls of cryptographic procedures, identified by Unified Resource Identifier (URI) such as schemeS://sen@server.com:443/?query The Internet of Secure Element (IoSE) is a set of secure elements providing TLS servers, communication interfaces, and identified by their name (Secure Element Name, sen). | ||||||||||||||||
| draft-urien-core-blockchain-transaction-protocol-09.txt | |||||||||||||||||
| Blockchain Transaction Protocol for Constraint Nodes | |||||||||||||||||
|
The goal of the blockchain transaction protocol for constraint nodes is to enable the generation of blockchain transactions by constraint nodes, according to the following principles: - transactions are triggered by Provisioning-Messages that include the needed blockchain parameters. - binary encoded transactions are returned in Transaction-Messages, which include sensors/actuators data. Constraint nodes, associated with blockchain addresses, compute the transaction signature. | ||||||||||||||||
| draft-urien-core-bmac-11.txt | |||||||||||||||||
| Bijective MAC for Constraint Nodes | |||||||||||||||||
|
In this draft context, things are powered by micro controllers units (MCU) comprising a set of memories such as static RAM (SRAM), FLASH and EEPROM. The total memory size, ranges from 10KB to a few megabytes. In this context code and data integrity are major security issues, for the deployment of Internet of Things infrastructure. The goal of the bijective MAC (bMAC) is to compute an integrity value, which cannot be guessed by malicious software. In classical keyed MACs, MAC is computing according to a fixed order. In the bijective MAC, the content of N addresses is hashed according to a permutation P (i.e. bijective application). The bijective MAC key is the permutation P. The number of permutations for N addresses is N!. So the computation of the bMAC requires the knowledge of the whole space memory; this is trivial for genuine software, but could very difficult for corrupted software, especially for time stamped bMAC. | ||||||||||||||||
| draft-urien-core-racs-18.txt | |||||||||||||||||
| Remote APDU Call Secure (RACS) | |||||||||||||||||
|
This document describes the Remote APDU Call Protocol Secure (RACS) protocol, dedicated to Grid of Secure Elements (GoSE). These servers host Secure Elements (SE), i.e. tamper resistant chips offering secure storage and cryptographic resources. Secure Elements are microcontrollers whose chip area is about 25mm2; they deliver trusted computing services in constrained environments. RACS supports commands for GoSE inventory and data exchange with secure elements. It is designed according to the representational State Transfer (REST) architecture. RACS resources are identified by dedicated URIs. An HTTP interface is also supported. An open implementation [OPENRACS] is available (https://github.com/purien) for various OS. | ||||||||||||||||
| draft-urien-lwig-security-classes-09.txt | |||||||||||||||||
| Security Classes for IoT devices | |||||||||||||||||
|
This draft attempts to define security classes for constraint IoT devices. A device security is characterized by five Boolean security attributes: one time programmable memory (OTP), firmware loader (FLD), secure firmware loader (FLD-SEC), tamper resistant key (TRT- KEY) and diversified key (DIV-KEY). This leads to the definition of 6 classes of devices, embedding or not OTP resource, whose security increases with the class number (0 to 5). The suffix + indicates OTP availability. | ||||||||||||||||
| draft-urien-tls-im-08.txt | |||||||||||||||||
| Identity Module for TLS Version 1.3 | |||||||||||||||||
|
TLS 1.3 will be deployed in the Internet of Things ecosystem. In many IoT frameworks, TLS or DTLS protocols, based on pre-shared key (PSK), are used for device authentication. So PSK tamper resistance, is a critical market request, in order to prevent hijacking issues. If DH exchange is used with certificate bound to DH ephemeral public key, there is also a benefit to protect its signature procedure. The TLS identity module (im) MAY be based on secure element; it realizes some HKDF operations bound to PSK, and cryptographic signature if certificates are used. Secure Element form factor could be standalone chip, or embedded in SoC like eSIM. | ||||||||||||||||
| draft-urien-tls-se-06.txt | |||||||||||||||||
| Secure Element for TLS Version 1.3 | |||||||||||||||||
|
This draft presents ISO7816 interface for TLS1.3 stack running in secure element. It presents supported cipher suites and key exchange modes, and describes embedded software architecture. TLS 1.3 is the de facto security stack for emerging Internet of Things (IoT) devices. Some of them are constraint nodes, with limited computing resources. Furthermore cheap System on Chip (SoC) components usually provide tamper resistant features, so private or pre shared keys are exposed to hacking. According to the technology state of art, some ISO7816 secure elements are able to process TLS 1.3, but with a limited set of cipher suites. There are two benefits for TLS-SE; first fully tamper resistant processing of TLS protocol, which increases the security level insurance; second embedded software component ready for use, which relieves the software of the burden of cryptographic libraries and associated attacks. TLS-SE devices may also embed standalone applications, which are accessed via internet node, using a routing procedure based on SNI extension. | ||||||||||||||||
| draft-urn-ddi-01.txt | |||||||||||||||||
| A Uniform Resource Name (URN) Namespace for the Data Documentation Initiative (DDI) | |||||||||||||||||
|
This document describes the Namespace Identifier (NID) "ddi" for Uniform Resource Names (URNs) used to identify resources that conform to the standards published by the Data Documentation Initiative (DDI) Alliance (https://ddialliance.org/). | ||||||||||||||||
| draft-uttaro-idr-bgp-oad-00.txt | |||||||||||||||||
| One Administrative Domain using BGP | |||||||||||||||||
|
This document defines a new External BGP (EBGP) peering type known as EBGP-OAD. EBGP-OAD peering is used between two EBGP peers that belong to One Administrative Domain (OAD). | ||||||||||||||||
| draft-valin-opus-dred-00.txt | |||||||||||||||||
| Deep Audio Redundancy (DRED) Extension for the Opus Codec | |||||||||||||||||
|
This document proposes a mechanism for embedding very low bitrate deep audio redundancy (DRED) within the Opus codec (RFC6716) bitstream. | ||||||||||||||||
| draft-valin-opus-extension-01.txt | |||||||||||||||||
| Extension Formatting for the Opus Codec | |||||||||||||||||
|
This document proposes a mechanism to extend the Opus codec (RFC6716) in a way that maintains inter-operability, while adding optional functionality. | ||||||||||||||||
| draft-vanrein-dnstxt-krb1-11.txt | |||||||||||||||||
| Declaring Kerberos Realm Names in DNS (_kerberos TXT) | |||||||||||||||||
|
This specification defines a method to determine Kerberos realm names for services that are known by their DNS name. Currently, such information can only be found in static mappings or through educated guesses. DNS can make this process more flexible, provided that DNSSEC is used to assure authenticity of resource records. | ||||||||||||||||
| draft-vanrein-httpauth-sasl-08.txt | |||||||||||||||||
| HTTP Authentication with SASL | |||||||||||||||||
|
Most application-level protocols standardise their authentication exchanges under the SASL framework. HTTP has taken another course, and often ends up replicating the work to allow individual mechanisms. This specification adopts full SASL authentication into HTTP. | ||||||||||||||||
| draft-vanrein-tls-kdh-08.txt | |||||||||||||||||
| Quantum Relief with TLS and Kerberos | |||||||||||||||||
|
This specification describes a mechanism to use Kerberos authentication within the TLS protocol. This gives users of TLS a strong alternative to classic PKI-based authentication, and at the same time introduces a way to insert entropy into TLS' key schedule such that the resulting protocol becomes resistant against attacks from quantum computers. We call this Quantum Relief, and specify it as part of a more general framework to make it easier for other technologies to achieve similar benefits. | ||||||||||||||||
| draft-vattaparambil-iotops-poa-based-onboarding-01.txt | |||||||||||||||||
| draft-vattaparambil-iotops-poa-based-onboarding-01 | |||||||||||||||||
|
Industrial network layer onboarding demands a technique that is efficient, scalable, and secure. In this document, we propose Power of Attorney based authorization technique as a decentralized solution for onboarding devices. This enables users such as integrators and subcontractors to onboard devices permanently or temporarily according to terms and requirements set in the PoAs. | ||||||||||||||||
| draft-vattaparambil-oauth-poa-grant-type-00.txt | |||||||||||||||||
| draft-vattaparambil-oauth-poa-grant-type-00 | |||||||||||||||||
|
This draft proposes a new grant type for OAuth based on PoA-based authorization, that introduces a new role "principal" who controls the client, and enables the client to access resources owned by the resource owner via OAuth authorization server, on behalf of the principal, even if the principal is not online. | ||||||||||||||||
| draft-vattaparambil-positioning-of-poa-00.txt | |||||||||||||||||
| draft-vattaparambil-positioning-of-poa-00 | |||||||||||||||||
|
Power of Attorney (PoA) based authorization is a generic and decentralized subgranting based authorization technique. In this, a principal can grant limited credibilities for an agent to act on its behalf for some limited time and context. This can be used for example with semi-autonomous devices to have them act on behalf. PoA is a self-contained document that a principal sign and directs to an agent, thereby providing it the power to execute user actions on behalf of the principal for a predefined time. In this document, we compare PoA based authorization with different existing internet protocols for authorization and the relation with existing identity solutions. | ||||||||||||||||
| draft-vda-lisp-underlay-multicast-trees-00.txt | |||||||||||||||||
| Enhancements to Signal-Free Locator/ID Separation Protocol (LISP) Multicast | |||||||||||||||||
|
This draft augments the signal-free LISP Multicast RFC 8378 and RFC6831 to support multicast underlays between LISP sites. This draft defines the many-to-1, 1-to-many, and many-to-many relationship between multicast EIDs and the Replication List Entries (RLEs) RLOC records they map to. The mechanisms in this draft allow a multicast LISP overlay to run over a mixed underlay of unicast and/or multicast functionality. | ||||||||||||||||
| draft-vesely-email-agreement-00.txt | |||||||||||||||||
| Mailing List Manager (MLM) Transformations | |||||||||||||||||
|
This draft proposes a way to standardize an agreement between a recipient and a sender, acknowledged by the recipient's MTA. The subject of the agreement expresses the willingness of the recipient to receive an identified, authenticated mail stream. After an MTA acknowledges the agreement, it will unconditionally accept complying messages, even if the recipient is not mentioned in any destination address field. | ||||||||||||||||
| draft-vfv-bmwg-srmpls-bench-meth-06.txt | |||||||||||||||||
| Benchmarking Methodology for MPLS Segment Routing | |||||||||||||||||
|
This document defines a methodology for benchmarking Segment Routing (SR) performance for Segment Routing over MPLS (SR-MPLS). It builds upon [RFC2544], [RFC5695] and [RFC8402]. | ||||||||||||||||
| draft-vfv-bmwg-srv6-bench-meth-06.txt | |||||||||||||||||
| Benchmarking Methodology for IPv6 Segment Routing | |||||||||||||||||
|
This document defines a methodology for benchmarking Segment Routing (SR) performance for Segment Routing over IPv6 (SRv6). It builds upon [RFC2544], [RFC5180], [RFC5695] and [RFC8402]. | ||||||||||||||||
| draft-viathinksoft-oidip-05.txt | |||||||||||||||||
| Retrieving information about Object Identifiers using a text-based protocol | |||||||||||||||||
|
This document defines a method for retrieving information about Object Identifiers (OIDs) and their associated Registration Authorities (RAs) through a text-based protocol, in a way that is both human-readable and machine-readable. Besides a text output format, OID-IP also supports sending information in JSON and XML. | ||||||||||||||||
| draft-voit-rats-trustworthy-path-routing-07.txt | |||||||||||||||||
| Trusted Path Routing | |||||||||||||||||
|
There are end-users who believe encryption technologies like IPSec alone are insufficient to protect the confidentiality of their highly sensitive traffic flows. These end-users want their flows to traverse devices which have been freshly appraised and verified for trustworthiness. This specification describes Trusted Path Routing. Trusted Path Routing protects sensitive flows as they transit a network by forwarding traffic to/from sensitive subnets across network devices recently appraised as trustworthy. | ||||||||||||||||
| draft-vv-6man-nd-support-mhmp-02.txt | |||||||||||||||||
| Neighbor Discovery support for Multi-home Multi-prefix | |||||||||||||||||
|
Multi-home Multi-prefix (MHMP) IPv6 environment is the norm for businesses that need to have uplink resiliency. Several solutions have been already discussed and proposed to address MHMP and how it can be enabled in different network contexts. This draft looks at MHMP from the perspective of Neighbour Discovery Protocols (NDP). For any considered destination, the MHMP challenge may be split into 3 sub-challenges (important to solve in the below order): 1) the host should choose the proper source address for the packet, 2) the host should choose the best default router as the next hop, 3) site topology may be complicated and may need the source routing through the site. This draft is concerned with the solution for the first two problems that need improvement for the ND (RFC 4861) SLAAC (RFC 4862) and Default Address Selection (RFC 6724). The last problem is considered as properly discussed by Multihoming in Enterprise (RFC 8678). | ||||||||||||||||
| draft-vyncke-v6ops-james-03.txt | |||||||||||||||||
| Just Another Measurement of Extension header Survivability (JAMES) | |||||||||||||||||
|
In 2016, RFC7872 has measured the drop of packets with IPv6 extension headers. This document presents a slightly different methodology with more recent results. It is still work in progress. | ||||||||||||||||
| draft-wang-bess-l3-accessible-evpn-05.txt | |||||||||||||||||
| Layer-3 Accessible EVPN Services | |||||||||||||||||
|
This draft describes layer-3 accessible EVPN service interfaces according to [RFC7432], and proposes a new solution which can simplify the deployment of layer-3 accessible EVPN service. This solution allows each PE in EVPN network to maintain only one IP-VRF. | ||||||||||||||||
| draft-wang-bess-mvpn-upstream-df-selection-06.txt | |||||||||||||||||
| Multicast VPN Upstream Designated Forwarder Selection | |||||||||||||||||
|
This document defines Multicast Virtual Private Network (VPN) extensions and procedures of designated forwarder election performed between ingress PEs, which is different from the one described in [RFC9026] in which the upstream designated forwarder determined by using the "Standby PE Community" carried in the C-Multicast routes. Based on the DF election, the failure detection point discovery mechanism between DF and standby DF is extended in MVPN procedures to achieve fast failover by using BFD session to track the status of detection point. To realize a stable "warm root standby", this document obsolete the P-Tunnel status determining procedure for downstream PEs in regular MVPN by introducing a RPF Set Checking mechanism as an instead. | ||||||||||||||||
| draft-wang-bess-sbfd-discriminator-05.txt | |||||||||||||||||
| Advertising S-BFD Discriminators in BGP | |||||||||||||||||
|
Seamless Bidirectional Forwarding Detection (S-BFD) is a simplified BFD mechanism. It eliminates most negotiation aspects and provides advantages such as fast configuration injection. S-BFD is especially useful in multi-homing PE scenarios and reduces resource overheads on the dual-homing PEs. Although S-BFD is simpler than BFD, a large number of manual configurations are required when there are a large number of PEs. This document provides the mechanism of distributing S-BFD discriminators with VPN service routes, which simplifies S-BFD deployment for VPN services. | ||||||||||||||||
| draft-wang-cats-green-challenges-00.txt | |||||||||||||||||
| Green Challenges in Cats | |||||||||||||||||
|
As mobile edge computing networks sink computing tasks from cloud data centers to the edge of the network, tasks need to be processed by computing resources close to the user side. Therefore, CATS was raised. Reducing carbon footprint is a major challenge of our time. Networks are the main enablers of carbon reductions. The introduction of computing dimension in CATS makes it insufficient to consider the energy saving of network dimension in the past, so the green for CATS based on network and computing combination is worth exploring. This document outlines a series of challenges and associated research to explore ways to reduce carbon footprint and reduce network energy based on CATS. | ||||||||||||||||
| draft-wang-detnet-tsn-over-srv6-06.txt | |||||||||||||||||
| DetNet Data Plane: IEEE 802.1 Time Sensitive Networking over SRv6 | |||||||||||||||||
|
This document specifies the Deterministic Networking data plane when TSN networks interconnected over an Segment Routing IPv6 Packet Switched Networks. | ||||||||||||||||
| draft-wang-dyncast-centralized-service-routing-00.txt | |||||||||||||||||
| Centralized service routing solution for dyncast | |||||||||||||||||
|
This document introduces a centralized service routing solution for dyncast architecture, which will improve the network scability and avoid the traffic loop problem. | ||||||||||||||||
| draft-wang-ffd-framework-01.txt | |||||||||||||||||
| Framework of Fast Fault Detection for IP-based Network | |||||||||||||||||
|
The IP-based distributed system and software application layer often use heartbeat to maintain the network topology status. However, the heartbeat setting is long, which prolongs the system fault detection time. IP-based storage network is the typical usage of that scenario. When the IP-based storage network fault occurs, NVMe connections need to be switched over. Currently, no effective method is available for quick detection, switchover is performed only based on keepalive timeout, resulting in low performance. This document defines the basic framework of how network assisted host devices can quickly detect application connection failures caused by network faults. | ||||||||||||||||
| draft-wang-i2nsf-intelligent-detection-01.txt | |||||||||||||||||
| YANG Data Models for Attacks Intelligent Detection | |||||||||||||||||
|
This document describes how to extend the Interface to Network Security Function (I2NSF) framework to make it suitable for attacks intelligent detection. Intelligent detection means that the network can dynamically adjust detection policies based on resource status, traffic features, or detection results. This document describes the application of I2NSF Framework for Security Management Automation (SMA) for attacks intelligent detection in Software-Defined Networking (SDN) and Service Function Chaining (SFC) environment. This document will extend the YANG data model of Monitoring Interface, Analytics Interface and NSF-Facing Interface in I2NSF for SMA framework to make it suitable for attacks intelligent detection in SDN and SFC environments. | ||||||||||||||||
| draft-wang-idr-cpr-01.txt | |||||||||||||||||
| BGP Colorful Prefix Routing (CPR) for SRv6 based Services | |||||||||||||||||
|
This document describes a mechanism to advertise different IPv6 prefixes which are associated with different color attributes to establish end-to-end intent-aware paths for SRv6 services. Such IPv6 prefixes are called "Colorful Prefixes", and this mechanism is called Colorful Prefix Routing (CPR). In SRv6 networks, the colorful prefixes are the SRv6 locators associated with different intent. SRv6 services (e.g. SRv6 VPN services) with specific intent could be assigned with SRv6 SIDs under the corresponding SRv6 locators, which are advertised as colorful prefixes. This allows the SRv6 service traffic to be steered into end-to-end intent-aware paths simply based on the SRv6 Service SIDs. The existing IPv6 Address Family could be used for the advertisement of IPv6 colorful prefixes, thus this mechanism is easy to interoperate and allows incremental deployment in multi-domain networks. | ||||||||||||||||
| draft-wang-idr-flowspec-dip-origin-as-filter-07.txt | |||||||||||||||||
| Destination-IP-Origin-AS Filter for BGP Flow Specification | |||||||||||||||||
|
BGP Flowspec mechanism (BGP-FS) [RFC8955] [RFC8956] propagates both traffic Flow Specifications and Traffic Filtering Actions by making use of the BGP NLRI and the BGP Extended Community encoding formats. This document specifies a new BGP-FS component type to support AS- level filtering. The match field is the origin AS number of the destination IP address that is encoded in the Flowspec NLRI. This function is applied in a single administrative domain. | ||||||||||||||||
| draft-wang-ippm-alt-mark-yang-02.txt | |||||||||||||||||
| A YANG Data Model for Alternate Marking Method | |||||||||||||||||
|
Alternate-Marking Method (AMM) is a technique used to perform packet loss, delay, and jitter measurements on live traffic. This document defines a YANG data model for Alternate Marking Method. | ||||||||||||||||
| draft-wang-ippm-ipv6-distributed-flow-measurement-02.txt | |||||||||||||||||
| Distributed Flow Measurement in IPv6 | |||||||||||||||||
|
In IPv6 networks, performance measurements such as packet loss, delay and jitter of real traffic can be carried out based on the Alternate-Marking method. Usually, the controller needs to collect statistical data on network devices, calculate and present the measurement results. This document proposes a distributed method for on-path flow measurement, which is independent of the controller. | ||||||||||||||||
| draft-wang-ippm-ipv6-flow-measurement-04.txt | |||||||||||||||||
| Flow Measurement in IPv6 Network | |||||||||||||||||
|
This document describes how to deploy in-situ flow performance measurement based on Alternate-Marking method in IPv6 domain. | ||||||||||||||||
| draft-wang-lsr-prefix-unreachable-annoucement-11.txt | |||||||||||||||||
| Prefix Unreachable Announcement | |||||||||||||||||
|
This document describes a mechanism that can trigger the switchover of the services which rely on the reachability of the peer endpoints, for example the BGP or the tunnel services. It is mainly used in the scenarios that the summary prefixes are advertised at the border routers whereas the services endpoints are located in different IGP areas or levels, whose reachabilities are covered by the summary prefixes. It introduces a new signaling mechanism using a negative prefix announcement called Prefix Unreachable Announcement Mechanism(PUAM), utilized to detect a link or node down event and signal the overlay services that the communication endpoint is unreachabe to force the overlay service headend switchover immediately. | ||||||||||||||||
| draft-wang-lsr-redistribution-credibility-id-00.txt | |||||||||||||||||
| Route Redistribution Credibility ID for Avoiding Routing Loop | |||||||||||||||||
|
The route redistribution is often deployed in current network between two different protocols domain or instance/process, such as the ISIS domain redistribute to OSPF domain, the OSPF domain redistribute to BGP domain, IS-IS redistribute to another IS-IS instance/process and so on. The existing network have more complex multiple IGP domains architecture. Therefore, bidirectional route redistribution deployment is more complex for different protocols or instances/ processes to learn routes from each other. In recent years, these route redistributions have had many routing loops cases that cause network incident. This document proposes a simplified method to positively avoid routing loop, and introduces new sub-TLVs to support advertisement IPv4 and IPv6 prefix extended attribute as Redistribution Credibility ID, while redistributing route from one protocol domain or instance/ process to another. | ||||||||||||||||
| draft-wang-lsr-stub-link-attributes-06.txt | |||||||||||||||||
| Advertisement of Stub Link Attributes | |||||||||||||||||
|
This document describes the mechanism that can be used to advertise the stub link attributes within the IS-IS or OSPF domain. | ||||||||||||||||
| draft-wang-pce-vlan-based-traffic-forwarding-07.txt | |||||||||||||||||
| PCEP Procedures and Extension for VLAN-based Traffic Forwarding | |||||||||||||||||
|
This document defines the Path Computation Element Communication Protocol (PCEP) extension for VLAN-based traffic forwarding in native IP network and describes the essential elements and key processes of the data packet forwarding system based on VLAN info to accomplish the End to End (E2E) traffic assurance for VLAN-based traffic forwarding in native IP network. | ||||||||||||||||
| draft-wang-ppm-dap-taskprov-03.txt | |||||||||||||||||
| In-band Task Provisioning for DAP | |||||||||||||||||
|
An extension for the Distributed Aggregation Protocol (DAP) is specified that allows the task configuration to be provisioned in- band. | ||||||||||||||||
| draft-wang-spring-multicast-vpn-segment-00.txt | |||||||||||||||||
| Segment Encoding and Procedures For Multicast VPN Service in Native IPv6 Network | |||||||||||||||||
|
This draft defines a new segment type for Multicast VPN, which contains the information of VPN customer. This segment type can be used for customer traffic differentiation by destination address on egress PEs, and assures the source and destination address not changed during the transmission. | ||||||||||||||||
| draft-wang-tcpm-tcp-service-affinity-option-02.txt | |||||||||||||||||
| Service Affinity Solution for TCP based Application in Anycast Situation | |||||||||||||||||
|
This draft proposes a service affinity solution between client and server based on the newly defined TCP Options. This solution can avoid the waste of resources caused by saving a large amount of customer status data in the network equipment, and realize the optimized scheduling of resources based on network conditions and computing resources in the computing-aware traffic steering scenario, so as to realize the reasonable operation of cloud network resources. | ||||||||||||||||
| draft-wdbsp-teas-nrp-yang-00.txt | |||||||||||||||||
| A YANG Data Model for Network Resource Partitions (NRPs) | |||||||||||||||||
|
This document defines a YANG data model for Network Resource Partitions (NRPs). The model can be used, in particular, for the realization of the IETF Network Slice Services. | ||||||||||||||||
| draft-wei-nmrg-gnn-based-dtn-modeling-00.txt | |||||||||||||||||
| Graph Neural Network Based Modeling for Digital Twin Network | |||||||||||||||||
|
This draft introduces the scenarios and requirements for performance modeling of digital twin networks, and explores the implementation methods of network models, proposing a network modeling method based on graph neural networks (GNNs). This method combines GNNs with graph sampling techniques to improve the expressiveness and granularity of the model. The model is generated through data training and validated with typical scenarios. The model performs well in predicting QoS metrics such as network latency, providing a reference option for network performance modeling methods. | ||||||||||||||||
| draft-weng-ippm-srpm-path-consistency-over-srv6-03.txt | |||||||||||||||||
| SRPM Path Consistency over SRv6 | |||||||||||||||||
|
TWAMP can be used to measure the performance of end-to-end paths in networks. STAMP [rfc8762] and TWAMP light are more lightweight measurement methods. In the SRv6 network, it is also necessary to measure the performance of SRv6 policy. This document describes a method to measure srv6 policy through stamp and TWAMP light. | ||||||||||||||||
| draft-westerbaan-cfrg-hpke-xyber768d00-01.txt | |||||||||||||||||
| X25519Kyber768Draft00 hybrid post-quantum KEM for HPKE | |||||||||||||||||
|
This memo defines X25519Kyber768Draft00, a hybrid post-quantum KEM, for HPKE (RFC9180). This KEM does not support the authenticated modes of HPKE. | ||||||||||||||||
| draft-westerlund-tsvwg-sctp-crypto-chunk-00.txt | |||||||||||||||||
| Stream Control Transmission Protocol (SCTP) CRYPTO Chunk | |||||||||||||||||
|
This document describes a method for adding cryptographic protection to the Stream Control Transmission Protocol (SCTP). The SCTP CRYPTO chunk defined in this document is intended to enable communications privacy for applications that use SCTP as their transport protocol and allows applications to communicate in a way that is designed to prevent eavesdropping and detect tampering or message forgery. The CRYPTO chunk defined here in is one half of a complete solution. Where a companion specification is required to define how the content of the CRYPTO chunk is protected, authenticated, and protected against replay, as well as how key management is accomplished. Applications using SCTP CRYPTO chunk can use all transport features provided by SCTP and its extensions. | ||||||||||||||||
| draft-westerlund-tsvwg-sctp-crypto-dtls-00.txt | |||||||||||||||||
| Datagram Transport Layer Security (DTLS) in the Stream Control Transmission Protocol (SCTP) CRYPTO Chunk | |||||||||||||||||
|
This document defines a usage of Datagram Transport Layer Security (DTLS) 1.2 or 1.3 to protect the content of Stream Control Transmission Protocol (SCTP) packets using the framework provided by the SCTP CRYPTO chunk which we name DTLS in SCTP. DTLS in SCTP provides encryption, source authentication, integrity and replay protection for the SCTP association with mutual authentication of the peers. The specification is also targeting very long-lived sessions of weeks and months and supports mutual re-authentication and rekeying with ephemeral key exchange. This is intended as an alternative to using DTLS/SCTP (RFC 6083) and SCTP-AUTH (RFC 4895). | ||||||||||||||||
| draft-white-linklocal-capability-02.txt | |||||||||||||||||
| Link-Local Next Hop Capability for BGP | |||||||||||||||||
|
BGP, described in [RFC4271], was originally designed to provide reachability between domains and between the edges of a domain. As such, BGP assumes the next hop towards any reachable destination may not reside on the advertising speaker, but rather may either be through a router connected to the same subnet as the speaker, or through a router only reachable by traversing multiple hops through the network. Because of this, BGP does not recognize the use of IPv6 link-local addresses, as described in [RFC4291], as a valid next hop for forwarding purposes. However, BGP speakers are now often deployed on point-to-point links in networks where multihop reachability of any kind is not assumed or desired (all next hops are assumed to be the speaker reachable through a directly connected point-to-point link). This is common, for instance, in data center fabrics. In these situations, a global IPv6 address is not required for the advertisement of reachability information; in fact, providing global IPv6 addresses in these kinds of networks can be detrimental to Zero Touch Provisioning (ZTP). This draft standardizes the operation of BGP over a point-to-point link using link-local IPv6 addressing only. | ||||||||||||||||
| draft-wing-opsawg-authenticating-network-01.txt | |||||||||||||||||
| Asserting Wireless Network Connections Using DNS Revolvers' Identities | |||||||||||||||||
|
This document describes how a host uses the encrypted DNS server identity to reduce an attacker's capabilities if the attacker is emulating a wireless network. | ||||||||||||||||
| draft-winters-v6ops-cpe-lan-pd-02.txt | |||||||||||||||||
| IPv6 CE Routers LAN Prefix Delegation | |||||||||||||||||
|
This document defines requirements for IPv6 CE Routers to support DHCPv6 Prefix Delegation for redistributing any unused prefix(es) that were delegated to the IPv6 CE Router. This document updates RFC 7084. | ||||||||||||||||
| draft-wkumari-dhc-addr-notification-07.txt | |||||||||||||||||
| Registering Self-generated IPv6 Addresses using DHCPv6 | |||||||||||||||||
|
This document defines a method to inform a DHCPv6 server that a device has a self-generated or statically configured address. | ||||||||||||||||
| draft-wkumari-not-a-draft-17.txt | |||||||||||||||||
| Just because it's an Internet-Draft doesn't mean anything... at all... | |||||||||||||||||
|
Anyone can publish an Internet Draft (ID). This doesn't mean that the "IETF thinks" or that "the IETF is planning..." or anything similar. | ||||||||||||||||
| draft-wlin-bess-group-policy-id-extended-community-02.txt | |||||||||||||||||
| Group Policy ID BGP Extended Community | |||||||||||||||||
|
Group Based Policy can be used to achieve micro or macro segmentation of user traffic. For Group Based Policy, a Group Policy ID, also known as Group Policy Tag, is used to represent a logical group that shares the same policy and access privilege. This specification defines a new BGP extended community that can be used to propagate Group Policy ID through a BGP route advertisement in the control plane. This is to facilitate policy enforcement at the ingress node when the optimization of network bandwidth is desired. | ||||||||||||||||
| draft-wright-http-patch-byterange-01.txt | |||||||||||||||||
| Byte Range PATCH | |||||||||||||||||
|
This document specifies a media type for PATCH payloads that overwrites a specific byte range, to allow random access writes, or allow a resource to be uploaded in several segments. | ||||||||||||||||
| draft-wu-identifier-data-escrow-interface-06.txt | |||||||||||||||||
| Abstract | |||||||||||||||||
|
This document describes the Data Escrow report requirement and technical details of the interfaces provides by the Top-level Node (TLN) to its contracted parties. Second-level Node (SLN) MUST periodically send data escrow report to Top-level Node (TLN) and Data Escrow Agent (DEA). DEA MUST sends report verify result to TLN and SLN after processing the report. | ||||||||||||||||
| draft-wu-identifier-sln-objects-mapping-06.txt | |||||||||||||||||
| Abstract | |||||||||||||||||
|
This document specifies the format, contents and semantics of data escrow deposits for Industrial Internet Identifier Second-level Node (SLN). SLN directly serves enterprises and provides services such as identifier registration, identifier resolution, data sharing, etc. The mapping objects in this document mainly refers to the enterprise registration information of the SLN and the Enterprise-level Node (ELN) registered in the SLN. | ||||||||||||||||
| draft-wu-idr-bgp-segment-allocation-ext-11.txt | |||||||||||||||||
| BGP Extensions for IDs Allocation | |||||||||||||||||
|
This document describes extensions to the BGP for IDs allocation. The IDs are SIDs for segment routing (SR), including SR for IPv6 (SRv6). They are distributed to their domains if needed. | ||||||||||||||||
| draft-wu-idr-flowspec-redirect-group-01.txt | |||||||||||||||||
| BGP Flowspec Redirect Load Balancing Group Community | |||||||||||||||||
|
This document defines an extension to "BGP Community Container Attribute" [draft-ietf-idr-wide-bgp-communities], which allows flowspec redirection to multiple paths. This extended community serves to redirect traffic to a load balancing group and supports both equal-cost multi-path(ECMP) and unequal-cost multi-path(UCMP) scenarios. | ||||||||||||||||
| draft-wu-ietf-sfc-scheduling-implementation-report-01.txt | |||||||||||||||||
| Implementation Report for Service Function Chain Scheduling Algorithm | |||||||||||||||||
|
This document provides the application examples of mapping and deployment algorithms to address the problems of large resource overhead and end-to-end latency in Service Function Chain(SFC) that cannot meet the requirements of latency-sensitive applications in terms of both latency optimization and resource optimization.In terms of delay-optimized mapping and deployment of SFC, the application example of granularity-variable SFC mapping algorithm based on microservice architecture reduces the number of instantiated microservice units and the number of end-to-end routing hops by merging redundant microservice units within the service function chain and reusing microservice units between the service function chains.In terms of resource-optimized mapping and deployment of SFC, the application example of SFC mapping algorithm based on improved gray wolf optimization algorithm optimizes the mapping of SFC through two strategies of reverse learning initialization and nonlinear convergence factor, and improves the efficiency of the mapping scheme. | ||||||||||||||||
| draft-wu-savnet-inter-domain-architecture-01.txt | |||||||||||||||||
| Inter-domain Source Address Validation (SAVNET) Architecture | |||||||||||||||||
|
Source address validation (SAV) is critical to preventing attacks based on source IP address spoofing. The proposed inter-domain SAVNET architecture enables an AS to generate SAV rules based on SAV- related information from multiple sources. This architecture integrates existing SAV mechanisms and offers ample design space for new SAV mechanisms. The document focuses on architectural components and SAV-related information in an inter-domain SAVNET deployment, without specifying any protocols or protocol extensions. | ||||||||||||||||
| draft-wu-savnet-inter-domain-problem-statement-07.txt | |||||||||||||||||
| Source Address Validation in Inter-domain Networks Gap Analysis,Problem Statement,and Requirements | |||||||||||||||||
|
This document provides the gap analysis of existing inter-domain source address validation mechanisms, describes the fundamental problems, and defines the requirements for technical improvements. | ||||||||||||||||
| draft-wussler-openpgp-pqc-01.txt | |||||||||||||||||
| Post-Quantum Cryptography in OpenPGP | |||||||||||||||||
|
This document defines a post-quantum public-key algorithm extension for the OpenPGP protocol. Given the generally assumed threat of a cryptographically relevant quantum computer, this extension provides a basis for long-term secure OpenPGP signatures and ciphertexts. Specifically, it defines composite public-key encryption based on CRYSTALS-Kyber, composite public-key signatures based on CRYSTALS- Dilithium, both in combination with elliptic curve cryptography, and SPHINCS+ as a standalone public key signature scheme. | ||||||||||||||||
| draft-wzwb-opsawg-network-inventory-management-01.txt | |||||||||||||||||
| An Inventory Management Model for Enterprise Networks | |||||||||||||||||
|
This document defines a YANG model for network inventory management, which provides consistent representation and reporting of network nodes (including endpoints) inventory and enable a network orchestrator in the enterprise network to maintain a centralized view of all the endpoint types across multiple domains of the underlying network to implement a coherent control strategy. | ||||||||||||||||
| draft-xiao-mpls-lsp-ping-ioam-conf-state-00.txt | |||||||||||||||||
| LSP Ping/Traceroute for Enabled In-situ OAM Capabilities | |||||||||||||||||
|
This document describes the MPLS Node IOAM Information Query functionality, which uses the MPLS echo request/reply messages, allowing the IOAM encapsulating node to discover the enabled IOAM capabilities of each IOAM transit and decapsulating node. | ||||||||||||||||
| draft-xiao-nvo3-pm-geneve-06.txt | |||||||||||||||||
| Performance Measurement for Geneve | |||||||||||||||||
|
This document describes the method to achieve Performance Measurement (PM) in point-to-point Generic Network Virtualization Encapsulation (Geneve) tunnels used to make up an overlay network. | ||||||||||||||||
| draft-xiao-spring-srv6-checksum-00.txt | |||||||||||||||||
| SRv6 Upper-Layer Checksum | |||||||||||||||||
|
This document provides a unified mechanism that makes the upper-layer checksum computation rule defined in IPv6 Specification applicable, whether SRv6 SIDs or SRv6 compressed SIDs are used. | ||||||||||||||||
| draft-xie-idr-mpbgp-extension-4map6-01.txt | |||||||||||||||||
| MP-BGP Extension and the Procedures for IPv4/IPv6 Mapping Advertisement | |||||||||||||||||
|
This document defines MP-BGP extension and the procedures for IPv4 service delivery in multi-domain IPv6-only underlay networks. It defines a new BGP path attribute known as the "4map6" in conjunction with the existing AFI/SAFI in IPv6-only routing paradigm for transferring IPv4/IPv6 address mapping rule within and across IPv6-only domains. In addition, the behavior of each type of network node in this extension is also illustrated. | ||||||||||||||||
| draft-xie-spring-srv6-multicast-00.txt | |||||||||||||||||
| SRv6 Multicast: Approaches and Impacts to SRv6 Architecture | |||||||||||||||||
|
Multicast was not originally supported with SR, as indicated in [RFC8402]: Segment Routing is defined for unicast. However, with the wide development and deployment of SR and SRv6 technology, there have been proposals to develop SR-based multicast solutions, showing the interests to develop multicast solutions that facilitate incremental deployment based on SR and SRv6. This document examines two typical SRv6 multicast approaches and considers a number of different aspects to provide a framework for understanding. The purpose is to help the working group and IETF community to understand and thus evaluate these possible impacts. | ||||||||||||||||
| draft-xing-alto-sdn-controller-aware-mptcp-mpquic-07.txt | |||||||||||||||||
| The SDN-based MPTCP-aware and MPQUIC-aware Transmission Control Model using ALTO | |||||||||||||||||
|
This document aims to study and implement Multipath Transmission Control Protocol (MPTCP) and Multipath QUIC (MPQUIC) using application layer traffic optimization (ALTO) in software defined network (SDN). In a software-defined network, ALTO server collects network cost indicators (including link delay, number of paths, availability, network traffic, bandwidth and packet loss rate etc.), and the controller extracts MPTCP or MPQUIC packet header to allocate MPTCP or MPQUIC packet to suitable transmission path according to the network cost indicators by ALTO, which can reduce the probability of transmission path congestion and improving path utilization. | ||||||||||||||||
| draft-xiong-detnet-6man-queuing-option-04.txt | |||||||||||||||||
| IPv6 Option for DetNet Data Fields | |||||||||||||||||
|
The enhanced Deterministic Networking (DetNet) is required to provide packet treatment for data plane to achieve the DetNet QoS such as deterministic latency. New functions and related metadata should be supported and DetNet data fields and option types such as Deterministic Latency Action (DLA) option should be carried in enhanced DetNet. This document defines how DetNet data fields are encapsulated in IPv6 option. | ||||||||||||||||
| draft-xiong-detnet-data-fields-edp-00.txt | |||||||||||||||||
| Data Fields for DetNet Enhanced Data Plane | |||||||||||||||||
|
This document discusses the specific metadata which should be carried in Enhanced Data plane (EDP), proposes the DetNet data fields and option types for EDP such as Deterministic Latency Action Option. DetNet Data-Fields for EDP can be encapsulated into a variety of protocols such as MPLS, IPv6 and SRv6 networks. | ||||||||||||||||
| draft-xiong-detnet-enhanced-detnet-gap-analysis-00.txt | |||||||||||||||||
| Gap Analysis for Enhanced DetNet Data Plane | |||||||||||||||||
|
From charter and milestones, the enhanced Deterministic Networking (DetNet) is required to provide the enhancement of flow identification and packet treatment for data plane to achieve the DetNet QoS in large-scale networks. This document analyzes the gaps of the existing technologies especially applying the DetNet data plane as per RFC8938. | ||||||||||||||||
| draft-xiong-detnet-large-scale-enhancements-02.txt | |||||||||||||||||
| Enhanced DetNet Data Plane (EDP) Framework for Scaling Deterministic Networks | |||||||||||||||||
|
The Enhanced Deterministic Networking (EDN) is required to provide the enhancement of flow identification and packet treatment for Deterministic Networking (DetNet) to achieve the DetNet QoS in large- scale networks. This document proposes the enhancement of packet treatment to support the functions and metadata for Enhanced DetNet Data plane (EDP). It describes related enhanced controller plane considerations as well. | ||||||||||||||||
| draft-xiong-detnet-spring-srh-extensions-00.txt | |||||||||||||||||
| Segment Routing Header Extensions for DetNet Data Fields | |||||||||||||||||
|
This document defines how DetNet data fields are encapsulated as part of the Segment Routing with IPv6 data plane (SRv6) header [RFC8754]. | ||||||||||||||||
| draft-xiong-idr-detnet-flow-mapping-04.txt | |||||||||||||||||
| BGP Flow Specification for DetNet and TSN Flow Mapping | |||||||||||||||||
|
This document proposes extensions to BGP Flow Specification for the flow mapping of Deterministic Networking (DetNet) when interconnected with IEEE 802.1 Time-Sensitive Networking (TSN). The BGP flowspec is used for the filtering of the packets that match the DetNet newtworks and the mapping between TSN streams and DetNet flows in the control plane. | ||||||||||||||||
| draft-xiong-pce-detnet-bounded-latency-02.txt | |||||||||||||||||
| PCEP Extension for DetNet Bounded Latency | |||||||||||||||||
|
In certain networks, such as Deterministic Networking (DetNet), it is required to consider the bounded latency for path selection. This document describes the extensions to PCEP to carry deterministic latency constraints and distribute deterministic paths for end-to-end path computation in DetNet service. | ||||||||||||||||
| draft-xl-bess-source-segment-00.txt | |||||||||||||||||
| Source Segment for SRv6 based Multicast VPN | |||||||||||||||||
|
This document defines the general concept of source segment which is used as the IPv6 source address in an IPv6 packet. Source segment for multicast VPN service is introduced in this document. | ||||||||||||||||
| draft-xl-msr6-source-segment-03.txt | |||||||||||||||||
| Source Segment for Multicast Source Routing over IPv6 | |||||||||||||||||
|
This document defines the general concept of source segment which is used as the IPv6 source address in an IPv6 packet. Source segment for multicast service is introduced in this document. | ||||||||||||||||
| draft-xp-mpls-spring-lsp-ping-path-sid-06.txt | |||||||||||||||||
| Label Switched Path (LSP) Ping for Segment Routing (SR) Path Segment Identifiers (SIDs) with MPLS Data Planes | |||||||||||||||||
|
Path Segment is a type of SR segment, which is used to identify an SR path. This document provides Target Forwarding Equivalence Class (FEC) stack TLV definitions for Path Segment Identifiers. | ||||||||||||||||
| draft-xpbs-pce-topology-filter-02.txt | |||||||||||||||||
| Path Computation Element Communication Protocol (PCEP) Extensions for Topology Filter | |||||||||||||||||
|
This document proposes a set of extensions for Path Computation Element Communication Protocol (PCEP) to support the topology filter during path computation. | ||||||||||||||||
| draft-xu-intarea-ip-in-udp-11.txt | |||||||||||||||||
| Encapsulating IP in UDP | |||||||||||||||||
|
Existing IP-in-IP encapsulation technologies are not adequate for efficient load balancing of IP-in-IP traffic across IP networks. This document specifies additional IP-in-IP encapsulation technology, referred to as IP-in-UDP (User Datagram Protocol), which can facilitate the load balancing of IP-in-IP traffic across IP networks. | ||||||||||||||||
| draft-xu-ipsecme-esp-in-udp-lb-10.txt | |||||||||||||||||
| Encapsulating IPsec ESP in UDP for Load-balancing | |||||||||||||||||
|
IPsec Virtual Private Network (VPN) is widely used by enterprises to interconnect their geographical dispersed branch office locations across the Wide Area Network (WAN) or the Internet, especially in the Software-Defined-WAN (SD-WAN) era. In addition, IPsec is also increasingly used by cloud providers to encrypt IP traffic traversing data center networks and data center interconnect WANs so as to meet the security and compliance requirements, especially in financial cloud and governmental cloud environments. To fully utilize the bandwidth available in the data center network, the data center interconnect WAN or the Internet, load balancing of IPsec traffic over Equal Cost Multi-Path (ECMP) and/or Link Aggregation Group (LAG) is much attractive to those enterprises and cloud providers. This document defines a method to encapsulate IPsec Encapsulating Security Payload (ESP) packets over UDP tunnels for improving load-balancing of IPsec ESP traffic. | ||||||||||||||||
| draft-xu-ipsecme-risav-00.txt | |||||||||||||||||
| An RPKI and IPsec-based AS-to-AS Approach for Source Address Validation | |||||||||||||||||
|
This document presents RISAV, a protocol for establishing and using IPsec security between Autonomous Systems (ASes) using the RPKI identity system. In this protocol, the originating AS adds authenticating information to each outgoing packet at its Border Routers (ASBRs), and the receiving AS verifies and strips this information at its ASBRs. Packets that fail validation are dropped by the ASBR. RISAV achieves Source Address Validation among all participating ASes. | ||||||||||||||||
| draft-xu-lsr-isis-service-function-adv-00.txt | |||||||||||||||||
| Advertising Service Functions Using IS-IS | |||||||||||||||||
|
The MPLS source routing mechanism developed by Source Packet Routing in Networking (SPRING) WG can be leveraged to realize a unified source routing instruction which works across both IPv4 and IPv6 underlays in addition to the MPLS underlay. The unified source routing instruction can be used to realize a transport-independent service function chaining by encoding the service function path information or service function chain information as an MPLS label stack. This document describes how to advertise service functions and their corresponding attributes (e.g., service function label) using IS-IS. | ||||||||||||||||
| draft-xu-lsr-ospf-service-function-adv-00.txt | |||||||||||||||||
| Advertising Service Functions Using OSPF | |||||||||||||||||
|
The Segment Routing mechanism can be leveraged to realize the service path layer functionality of the Service Function Chaining (i.e, steering traffic through the service function path). This document describes how to advertise service functions and their corresponding attributes (e.g., segment ID) using OSPF. Here the OSPF means both OSPFv2 and OSPFv3. | ||||||||||||||||
| draft-xu-savax-control-03.txt | |||||||||||||||||
| Control Plane of Inter-Domain Source Address Validation Architecture | |||||||||||||||||
|
Because the Internet forwards packets according to the IP destination address, packet forwarding typically takes place without inspection of the source address and malicious attacks have been launched using spoofed source addresses. The inter-domain source address validation architecture is an effort to enhance the Internet by using state machine to generate consistent tags. When communicating between two end hosts at different ADs of IPv6 network, tags will be added to the packets to identify the authenticity of the IPv6 source address. This memo focus on the control plane of the SAVA-X mechanism. | ||||||||||||||||
| draft-xu-savax-data-03.txt | |||||||||||||||||
| Data Plane of Inter-Domain Source Address Validation Architecture | |||||||||||||||||
|
Because the Internet forwards packets according to the IP destination address, packet forwarding typically takes place without inspection of the source address and malicious attacks have been launched using spoofed source addresses. The inter-domain source address validation architecture is an effort to enhance the Internet by using state machine to generate consistent tags. When communicating between two end hosts at different ADs of IPv6 network, tags will be added to the packets to identify the authenticity of the IPv6 source address. This memo focus on the data plane of the SAVA-X mechanism. | ||||||||||||||||
| draft-xu-savax-protocol-03.txt | |||||||||||||||||
| Communication Protocol Between the AD Control Server and the AD Edge Router of Inter-Domain Source Address Validation Architecture | |||||||||||||||||
|
Because the Internet forwards packets according to the IP destination address, packet forwarding typically takes place without inspection of the source address and malicious attacks have been launched using spoofed source addresses. The inter-domain source address validation architecture is an effort to enhance the Internet by using state machine to generate consistent tags. When communicating between two end hosts at different ADs of IPv6 network, tags will be added to the packets to identify the authenticity of the IPv6 source address. This memo focus on the packet formats and processing flow of the SAVA-X mechanism. | ||||||||||||||||
| draft-xz-pim-flex-algo-01.txt | |||||||||||||||||
| Flex-Algorithm TLV in PIM Join Attributes | |||||||||||||||||
|
This document defines a PIM join attribute to support building multicast distribution trees flowing Flex-Algorithm path. | ||||||||||||||||
| draft-xzc-lsr-mpls-flc-frld-02.txt | |||||||||||||||||
| Signaling Flow-ID Label Capability and Flow-ID Readable Label Depth | |||||||||||||||||
|
Flow-ID Label (FL) is used for MPLS flow identification and flow- based performance measurement with alternate marking method. The ability to process Flow-ID labels is called Flow-ID Label Capability (FLC), and the capability of reading the maximum label stack depth and performing FL-based performance measurement is called Flow-ID Readable Label Depth (FRLD). This document defines a mechanism to signal the FLC and the FRLD using IGP and BGP-LS. | ||||||||||||||||
| draft-xzlnp-bier-ioam-05.txt | |||||||||||||||||
| BIER Encapsulation for IOAM Data | |||||||||||||||||
|
In-situ Operations, Administration, and Maintenance (IOAM) collects operational and telemetry information in the packet while the packet traverses a path between two points in the network. Bit Index Explicit Replication (BIER) is an architecture that provides optimal multicast forwarding through a "multicast domain", without requiring intermediate routers to maintain any per-flow state or to engage in an explicit tree-building protocol. The BIER header contains a bit- string in which each bit represents exactly one egress router to forward the packet to. This document outlines the requirements to carry IOAM data in BIER header and specifies how IOAM data is encapsulated in BIER header. | ||||||||||||||||
| draft-yan-dmm-man-10.txt | |||||||||||||||||
| Mobility Capability Negotiation as a 5G Mobility Pattern | |||||||||||||||||
|
Mobility support is an important network capability for mobile node, and 5G introduces the Mobility Pattern used by the Access and Mobility Management Function (AMF) to optimize mobility support provided to the UE. More specific, The AMF determines and updates Mobility Pattern of the UE according to the subscription of the UE, statistics of the UE mobility, network local policy, and the UE assisted information, or any combination of them with the help of Network Data Analytics Function (NWDAF). Based on different requirements, multiple mobility management protocols have been developed under IPv6. However, different protocols have different functional requirements on the network element or the host and then a scheme should be used in order to support the negotiation and selection of adopted mobility management protocol when a host (or UE) accesses to a new network. Besides, Mobility restrictions should also be considerred especially in 5G. In this draft, this issue is analyzed. | ||||||||||||||||
| draft-yang-alto-multi-domain-01.txt | |||||||||||||||||
| ALTO Multi-Domain Services | |||||||||||||||||
|
Application-Layer Traffic Optimization (ALTO) provides means for network applications to obtain network information. In the definitions of ALTO services ([RFC7285] and existing extensions), there is no requirement on whether the source and the destination endpoints must belong to the same autonomous network, which is a single-domain setting, or they can belong to different autonomous networks, which is a multi-domain setting. This document explains problems of realizing ALTO in multi-domain settings and then presents 3 potential solutions to realize ALTO multi-domain services. | ||||||||||||||||
| draft-yang-apn-sd-wan-usecase-06.txt | |||||||||||||||||
| Usage scenarios of Application-aware Networking (APN) for SD-WAN | |||||||||||||||||
|
This document describes the usage of Application-aware Networking (APN) in SD-WAN scenarios. In these scenarios, APN is able to identify a application group, steer its traffic flows along explicit path across the network, and provide SLA guaranteed network services such as low latency and high reliability. | ||||||||||||||||
| draft-yang-bfd-sbfd-proxy-02.txt | |||||||||||||||||
| S-BFD Proxy | |||||||||||||||||
|
This document proposes an extension to Seamless Bidirectional Forwarding Detection (S-BFD). The S-BFD initiator will send packets that carry extra information, and this enables reflector to act as a proxy, and respond with the extra information in consideration. This document updates RFC 7880. | ||||||||||||||||
| draft-yang-i2nsf-security-policy-translation-14.txt | |||||||||||||||||
| Guidelines for Security Policy Translation in Interface to Network Security Functions | |||||||||||||||||
|
This document proposes the guidelines for security policy translation in Interface to Network Security Functions (I2NSF) Framework. When I2NSF User delivers a high-level security policy for a security service, Security Policy Translator in Security Controller translates it into a low-level security policy for Network Security Functions (NSFs). For this security policy translation, this document specifies the relation between a high-level security policy based on the Consumer-Facing Interface YANG data model and a low-level security policy based on the NSF-Facing Interface YANG data model. Also, it describes an architecture of a security policy translator along with an NSF database, and the process of security policy translation with the NSF database. | ||||||||||||||||
| draft-yang-idr-bgp-redundancy-policy-01.txt | |||||||||||||||||
| Advertising Redundancy Policy in BGP | |||||||||||||||||
|
Redundancy Protection is a generalized protection mechanism by replicating and transmitting copies of flow packets on redundancy node over multiple different and disjoint paths, and further eliminating the redundant packets at merging node. In order to support the replication behavior of redundancy protection, Redundancy Policy is used to instruct the replication of service packets and assign more than one redundancy forwarding paths. This document defines the extensions to BGP to advertise the redundancy policy. | ||||||||||||||||
| draft-yang-masque-dgram-retrans-01.txt | |||||||||||||||||
| A Configurable Retransmission Extension for HTTP/3 Datagrams | |||||||||||||||||
|
When using HTTP/3 Datagrams for traffic tunneling, it is desirable to retransmit HTTP/3 Datagrams in some scenarios where the retransmission is beneficial for the tunneled end-to-end connection. This document defines an extension to the HTTP Datagrams and the Capsule Protocol, which allows HTTP/3 Datagrams to be retransmitted according to the configuration of the HTTP/3 Datagram flow. | ||||||||||||||||
| draft-yang-nmrg-data-transfer-intent-00.txt | |||||||||||||||||
| Wan data transmission intent - one of IBN use cases | |||||||||||||||||
|
With the advent of the digital era, there are more and more scenarios such as data off-site AI training, data off-site cloud, and the demand for big data transmission in the WAN is increasing. WAN data transmission involves throughput, delay, packet loss, security and other performance indicators, as well as cost investment. Users have been exploring how to achieve the best performance of data transmission at the lowest cost. This paper implements high quality WAN data transmission based on IBNS. | ||||||||||||||||
| draft-yang-nmrg-network-measurement-intent-06.txt | |||||||||||||||||
| Network measurement intent - one of IBN use cases | |||||||||||||||||
|
As an important technical mean to detect network state, network measurement has attracted more and more attention in the development of networks. However, the current network measurement technology has the problem that the measurement method and the measurement purpose cannot match well. To solve this problem, this memo introduces network measurement intent, presents a process of scheduling the network resource and measurement task to meet the user or network operator's needs. And it can be seen as a specific use case of intent based network. | ||||||||||||||||
| draft-yang-spring-sid-as-source-address-01.txt | |||||||||||||||||
| SID as source address in SRv6 | |||||||||||||||||
|
In SRv6 network, the SRv6 packets usually use loopback address as source address. However, when there is symmetric traffic requirement for bidirectional flow, or there is requirement for traffic source validation, using loopback address as source address is not sufficient. This document proposes using SID as source address for SRv6 traffic, also identifies solution for several use cases. | ||||||||||||||||
| draft-yang-sr-policy-intelligent-routing-02.txt | |||||||||||||||||
| Intelligent Routing Method of SR Policy | |||||||||||||||||
|
Segment Routing is a source routing paradigm that explicitly indicates the forwarding path for packets at the ingress node. An SR Policy is associated with one or more candidate paths, and each candidate path is either dynamic, explicit or composite. This document describes an intelligent routing method for SR Policy based on network quality in MPLS and IPv6 environments. | ||||||||||||||||
| draft-yang-teep-tee-dp-00.txt | |||||||||||||||||
| Trusted Execution Environment Distributed Provisioning Protocol | |||||||||||||||||
|
In big data area, computing resource manager like MESOS[MESOS], YARM[YARN], kubernets[Kubernetes] or computing framework like Spark[Spark], use Master-Worker structure to split computing task. In the master component, the computing task will be splited into different child tasks. Each of thess child tasks will be loaded to a executor which is managed by Worker. The Master and Worker are usually exist as cluster, cloud or other distributed framework. When the big data tasks needs to be processed in TEE in lifecycle, this document could be used for Master to provision child tasks in distributed TEEs. | ||||||||||||||||
| draft-yao-alto-core-level-load-balancing-00.txt | |||||||||||||||||
| A Load-aware core level load balancing framework | |||||||||||||||||
|
Most existing literature on load balancing in data center networks(DCN) focuses on balancing traffic between servers (links), but there is relatively little attention given to balancing traffic at the core-level of individual servers. In this draft, we present a load balancing framework for DCN that is aware of core-level load, in order to address this issue. Specifically, our approach transfers real-time load from CPUs to an L4 load balancer, which then selects a core with lower load based on load information to deliver the data packet. Theoretically, our approach can completely avoid this problem, making the system more stable and enabling higher CPU utilization without overprovisioning. | ||||||||||||||||
| draft-yao-cats-gap-reqs-00.txt | |||||||||||||||||
| Computing-Aware Traffic Steering (CATS) Gap Analysis and Requirements | |||||||||||||||||
|
This document provides gap analysis and requirements for the problems and use cases that champion the joint optimization of both network and computing resources as outlined in[I-D.yao-cats-ps-usecases]. It also identifies the key engineering investigation areas which require adequate architectures and protocols to achieve balanced computing and networking resource utilization among facilities providing the services. | ||||||||||||||||
| draft-yao-cats-ps-usecases-00.txt | |||||||||||||||||
| Computing-Aware Traffic Steering (CATS) Problem Statement and Use Cases | |||||||||||||||||
|
Many service providers have been exploring distributed computing techniques to achieve better service response time and optimized energy consumption. Such techniques rely upon the distribution of computing services and capabilities over many locations in the network, such as its edge, the metro region, virtualized central office, and other locations. In such a distributed computing environment, providing services by utilizing computing resources hosted in various computing facilities (e.g., edges) is being considered, e.g., for computationally intensive and delay sensitive services. Ideally, services should be computationally balanced using service-specific metrics instead of simply dispatching the service requests in a static way or optimizing solely connectivity metrics. For example, systematically directing end user-originated service requests to the geographically closest edge or some small computing units may lead to an unbalanced usage of computing resources, which may then degrade both the user experience and the overall service performance. We have named this kind of network with dynamic sharing of edge compute resources “Computing-Aware Networking” (CAN). This document provides the problem statement and the typical scenarios of CAN, which is to show the necessity of considering more factors when steering the traffic to the appropriate service instance based on the basic edge computing deployment to provide the service equivalency. | ||||||||||||||||
| draft-yao-coinrg-generic-framework-00.txt | |||||||||||||||||
| A Generic COIN framework in controlled environments | |||||||||||||||||
|
There have been a lot of academic research and industrial practice in the area of COIN, but most of them are case-by-case design and currently they also rely heavily on programmable network devices, which lacks some generality and scalability, thus will impede the development of COIN. This document summarizes the computing primitives/operations/semantics that can be implemented inside the network, through analysis of different COIN use cases, and proposes a generic framework of COIN in the controlled environments. Enabling technologies related to the framework and the standardization landscape are also analyzed in the document. | ||||||||||||||||
| draft-yaoyang-dutf-01.txt | |||||||||||||||||
| DUTF,a Dynamic Unicode Transformation Format | |||||||||||||||||
|
The Unicode Standard and ISO/IEC 10646 jointly define a coded character set, referred to as Unicode, which encompasses most of the world's writing systems. Characters of the same language are arranged close to each other in the Unicode code table. This memo proposes a dynamic Unicode transformation format(DUTF). DUTF has the characteristic of preserving the full US-ASCII range, and uses XOR to calculate the offset value between the Unicode code point of adjacent non-ASCII characters in the source string, then encodes the result as a variable-length sequence of octets. | ||||||||||||||||
| draft-yc-nmrg-dtn-owd-measurement-01.txt | |||||||||||||||||
| One-way delay measurement method based on Digital Twin Network | |||||||||||||||||
|
This document implements an accurate network delay measurement method based on the digital twin network. This is a use case of digital twin network. This method does not need to send measurement packets, does not need to change the physical network configuration, does not need to change the format of service packets, do not require physical network elements to support the time synchronization protocol, and support the one-way delay measurement of any service packet.The digital twin network architecture of this document follows the NMRG working group paper draft-irtf-nmrg-network-digital-twin-arch-00. | ||||||||||||||||
| draft-yee-ssh-iana-requirements-01.txt | |||||||||||||||||
| Update to the IANA SSH Protocol Parameters Registry Requirements | |||||||||||||||||
|
This specification updates the requirements for adding new entries to the IANA Secure Shell (SSH) Protocol Parameters registry. Currently, the requirement is generally for "IETF Review", as defined in RFC 8126, although a few portions of the registry require "Standards Action". This specification will change that former requirement to "Expert Review". This draft updates RFC 4250, RFC 4716, RFC 4819, RFC 8308. | ||||||||||||||||
| draft-yi-idr-bgp-fs-edge-service-metadata-00.txt | |||||||||||||||||
| Distribution of Service Metadata in BGP FlowSpec | |||||||||||||||||
|
In edge computing, a service may be deployed on multiple instances within one or more sites, called edge service. The edge service is associated with an ANYCAST IP address, and the route of it along with service metadata can be collected by a central controller. The controller may process the metadata and distribute the result to ingress routers using BGP FlowSpec. The service metadata can be used by ingress routers to make path selections not only based on the routing cost but also the running environment of the edge services. This document describes a mechanism to distribute the information of the service routes and related service metadata using BGP FlowSpec. | ||||||||||||||||
| draft-yin-milp-rwa-otn-15.txt | |||||||||||||||||
| A MILP Model to Solve the Problem of Loading Balance of Routing and Wavelength Assignment for Optical Transport Networks | |||||||||||||||||
|
The RWA problem can be formulated as a Mixed-Integer linear program. Load balancing is a key factor for the optical transport networks. However, the existed approaches using mixed-Integer linear program to solve the RWA problem are not perfect enough without considering the load balancing of the networks. This documentary provides a model of Mixed-Integer Linear Programming to solve the problem of load balancing needed by routing and wavelength assignment (RWA) process in optical transport networks. | ||||||||||||||||
| draft-yizhou-detnet-ipv6-options-for-cqf-variant-01.txt | |||||||||||||||||
| IPv6 Options for Cyclic Queuing and Forwarding Variants | |||||||||||||||||
|
The fundamental Cyclic Queuing and Forwarding (CQF) defined by Time- Sensitive Networking (TSN) requires no per-stream per-hop state maintenance and at the same time its end-to-end bounded latency and jitter can be easily computed. Such features are attractive and therefore CQF is being considered in wider deployments. To accommodate the different deployments, there are variants of CQF enhancement. This document introduces a new IPv6 option to include the cycle identification to help leverage CQF variants in DetNet network to facilitate the deployments. | ||||||||||||||||
| draft-ymbk-9020-update-00.txt | |||||||||||||||||
| A Minor Update to Finding and Using Geofeed Data | |||||||||||||||||
|
This document specifies how to augment the Routing Policy Specification Language inetnum: class to refer specifically to geofeed data comma-separated values (CSV) files and describes an optional scheme that uses the Routing Public Key Infrastructure to authenticate the geofeed data CSV files. | ||||||||||||||||
| draft-ymbk-sidrops-9092-update-00.txt | |||||||||||||||||
| A Minor Update to Finding and Using Geofeed Data | |||||||||||||||||
|
This document specifies how to augment the Routing Policy Specification Language inetnum: class to refer specifically to geofeed data files and describes an optional scheme that uses the Routing Public Key Infrastructure to authenticate the geofeed datafiles. | ||||||||||||||||
| draft-young-md-query-18.txt | |||||||||||||||||
| Metadata Query Protocol | |||||||||||||||||
|
This document defines a simple protocol for retrieving metadata about named entities, or named collections of entities. The goal of the protocol is to profile various aspects of HTTP to allow requesters to rely on certain, rigorously defined, behaviour. This document is a product of the Research and Education Federations (REFEDS) Working Group process. | ||||||||||||||||
| draft-young-md-query-saml-18.txt | |||||||||||||||||
| SAML Profile for the Metadata Query Protocol | |||||||||||||||||
|
This document profiles the Metadata Query Protocol for use with SAML metadata. This document is a product of the Research and Education Federations (REFEDS) Working Group process. Editorial Note (To be removed by RFC Editor before publication) Discussion of this draft takes place on the MDX mailing list (mdx@lists.iay.org.uk), which is accessed from [MDX.list]. XML versions, latest edits and the issues list for this document are available from [md-query]. The changes in this draft are summarized in Appendix A.19. | ||||||||||||||||
| draft-yu-ccamp-optical-resource-pm-yang-00.txt | |||||||||||||||||
| A YANG Data Model for Optical Resource Performance Monitoring | |||||||||||||||||
|
This document defines a YANG data model for performance Monitoring in optical networks which provides the functionalities of performance monitoring task management, TCA (Threshold Crossing Alert) configuration and current or historic performance data retrieval. This data model should be used in the northbound of PNC. | ||||||||||||||||
| draft-yu-imap-client-id-09.txt | |||||||||||||||||
| IMAP Service Extension for Client Identity | |||||||||||||||||
|
This document defines an Internet Message Access Protocol (IMAP) service extension called "CLIENTID" which provides a method for clients to indicate an identity to the server. This identity is an additional token that may be used for security and/or informational purposes, and with it a server may optionally apply heuristics using this token. | ||||||||||||||||
| draft-yuchaozhang-i2bgp-01.txt | |||||||||||||||||
| Desensitize Intra-domain Information for Inter-domain Routing | |||||||||||||||||
|
Border Gateway Protocol (BGP) is a routing protocol for autonomous systems running on TCP. It is currently the only protocol capable of handling multiple connections between unrelated routing domains, such as the size of the Internet. BGP is built on the experience of EGP. The main function of BGP system is to exchange network access information with other BGP systems. However, it cannot fully utilize the complete information in the domain to achieve the optimal decision. This document proposes I2BGP, which describes how to obtain desensitization information in the domain to optimize routing decisions. | ||||||||||||||||
| draft-yusef-oauth-nested-jwt-06.txt | |||||||||||||||||
| JSON Web Token (JWT) Embedded Tokens | |||||||||||||||||
|
This specification defines a mechanism for embedding tokens into a JWT token. The JWT token and the embedded tokens are issued by different issuers. | ||||||||||||||||
| draft-yz-nmrg-dtn-flow-simulation-01.txt | |||||||||||||||||
| Digital Twin Network Flow Simulation | |||||||||||||||||
|
Some important application scenarios of digital twin network, such as network new technology experiment, network configuration verification, network performance optimization, etc., all require the virtual traffic in the twin network to accurately simulate the real traffic in the physical network.The real traffic in the physical network is called the physical traffic, and the virtual traffic in the twin network is called the twin traffic. In order to realize the high-fidelity simulation of the physical traffic by the twin traffic, this paper proposes that the twin traffic and the physical traffic should satisfy three consistent characteristics, and an implementation method of twin flow is introduced. | ||||||||||||||||
| draft-yzz-detnet-enhanced-data-plane-02.txt | |||||||||||||||||
| DetNet Enhanced Data Plane | |||||||||||||||||
|
Aiming at providing the bounded latency to DetNet services, DetNet data plane is required to be enhanced. This document provides a method to extend DetNet data plane by introducing the Bounded Latency Information (BLI), which facilitates DetNet transit nodes to guarantee the bounded latency transmission in data plane. | ||||||||||||||||
| draft-zcz-nmrg-digitaltwin-data-collection-02.txt | |||||||||||||||||
| Data Collection Requirements and Technologies for Digital Twin Network | |||||||||||||||||
|
A Digital Twin Network is a virtual representation of a physical network, which is meant to be used by a management system to analyze, diagnose, emulate and control the physical network based on monitoring information, data, models, and interfaces. The construction and state update of a Digital Twin Network require obtaining real-time information of the physical network it represents (i.e., telemetry data). This document aims to describe the data collection requirements and provide data collection methods or tools to build the data repository for building and updating a digital twin network. | ||||||||||||||||
| draft-zern-webp-12.txt | |||||||||||||||||
| WebP Image Format | |||||||||||||||||
|
This document defines the WebP image format and registers a media type supporting its use. | ||||||||||||||||
| draft-zhang-bier-babel-extensions-08.txt | |||||||||||||||||
| BIER in BABEL | |||||||||||||||||
|
BIER introduces a novel multicast architecture. It does not require a signaling protocol to explicitly build multicast distribution trees, nor does it require intermediate nodes to maintain any per- flow state. Babel defines a distance-vector routing protocol that operates in a robust and efficient fashion both in wired as well as in wireless mesh networks. This document defines a way to carry necessary BIER signaling information in Babel. | ||||||||||||||||
| draft-zhang-cats-computing-aware-sdwan-usecase-00.txt | |||||||||||||||||
| Use Cases for Computing-aware Software-Defined Wide Area Network(SD-WAN) | |||||||||||||||||
|
SD-WAN is aware of the computing power of applications deployed in the multiple sites of enterprise and can perform the routing policy according to such information. This is defined as the computing- aware SD-WAN.This document describes the use cases for computing- aware Software-Defined Wide Area Network(SD-WAN). | ||||||||||||||||
| draft-zhang-cats-computing-aware-sfc-usecase-00.txt | |||||||||||||||||
| Use Cases of Computing-aware Service Function Chaining (SFC) | |||||||||||||||||
|
Multiple occurrences of the same service function(SF) can exist in the same administrative domain and each occurrence of SF is called SF instance. A Service Function Path(SFP) is determined by composing selected SF instances and overlay links. The SF instances are selected according to the computing power of SFs in addition to the network information and this is defined as the computing-aware SFC in this document. This document describes the use cases for computing-aware Service Function Chaining(SFC). | ||||||||||||||||
| draft-zhang-idr-sr-policy-enhanced-detnet-00.txt | |||||||||||||||||
| SR Policy for enhanced DetNet | |||||||||||||||||
|
SR Policy is a set of candidate SR paths consisting of one or more segment lists and necessary path attributes. It enables instantiation of an ordered list of segments with a specific intent for traffic steering. DetNet provides the capability to carry specified unicast or multicast data flows with extremely low data loss rates and bounded end-to-end latency within a network domain. This document defines the SR policy enhancement to carry the Bounded Latency Information with a candidate path of SR policy. So that BLI behavior can be enabled automatically when the SR Policy is applied. | ||||||||||||||||
| draft-zhang-idr-sr-policy-metric-04.txt | |||||||||||||||||
| BGP SR Policy Extensions for metric | |||||||||||||||||
|
SR Policy candidate paths can be represented in BGP UPDATE messages. BGP can then be used to propagate the SR Policy candidate paths to the headend nodes in the network. After SR Policy is installed on the ingress node, the packets can be steered into SR Policy through route selection. Therefore, route selection may be performed on the ingress node of the SR Policy. If there are multiple routes to the same destination, the route selection node can select routes based on the local policy. The local policy may use the IGP metric of the selected path, which is the IGP Metric of the SR Policy. Thus the BGP UPDATE message need carry the metric of each segment list of the SR Policy Candidate Path, which can be used in path selection of routing. | ||||||||||||||||
| draft-zhang-idr-sr-policy-template-02.txt | |||||||||||||||||
| BGP SR Policy Extensions for template | |||||||||||||||||
|
Segment Routing(SR) Policies can be advertised using BGP. An SR Policy may has lots of constraints, and as the application and features evolve, the SR Policy may need have more and more attribute constraints. To avoid modifying BGP when constraints are added to an SR Policy, we can define a template. The identifier and content of the template are defined by the receiver of the SR Policy. The advertiser of an SR policy only needs to know the ID of the template. When advertising SR policy, the advertiser carries the template ID in the tunnel encapsulation information of the SR policy. After receiving the SR Policy information, the receiver obtains the corresponding template and content according to the template ID, thereby obtaining abundant constraint configuration information. | ||||||||||||||||
| draft-zhang-pce-enhanced-detnet-01.txt | |||||||||||||||||
| PCEP for Enhanced DetNet | |||||||||||||||||
|
PCEP is used to provide a communication between a PCC and a PCE. This document defines the extensions to PCEP to support the bounded- latency path computation. Specifically, two new objects and three new TLVs are defined for the transmission of bounded latency information between PCC and PCE to guarantee the bounded latency transmission in control plane. | ||||||||||||||||
| draft-zhang-rtgwg-mechanism-computing-network-01.txt | |||||||||||||||||
| Collaborative Mechanism for Integrated Computing and Network Service | |||||||||||||||||
|
This document introduces a collaborative mechanism of the SLA policy for integrated computing and network service when users access to the computing interconnection network and consume both computing and network resources. | ||||||||||||||||
| draft-zhang-rtgwg-srv6-computing-connect-usecases-01.txt | |||||||||||||||||
| Usecases of SRv6 Based Computing Interconnection Network | |||||||||||||||||
|
The requirements of computing interconnection are increasingly attracting the attention of service providers. They have been thinking about how to leverage their network advantages to provide integrated networking and computing services. This document describes some scenarios of using SRv6 based network technology which can partially meet the service requirement of computing interconnection. | ||||||||||||||||
| draft-zhang-sr-policy-enhanced-detnet-01.txt | |||||||||||||||||
| SR Policy for enhanced DetNet | |||||||||||||||||
|
SR Policy is a set of candidate SR paths consisting of one or more segment lists and necessary path attributes. It enables instantiation of an ordered list of segments with a specific intent for traffic steering. DetNet provides the capability to carry specified unicast or multicast data flows with extremely low data loss rates and bounded end-to-end latency within a network domain. This document defines the SR policy enhancement to carry the Bounded Latency Information with a candidate path of SR policy. So that BLI behavior can be enabled automatically when the SR Policy is applied. | ||||||||||||||||
| draft-zhao-pim-evpn-multicast-yang-01.txt | |||||||||||||||||
| Yang Data Model for EVPN multicast | |||||||||||||||||
|
This document describes a YANG data model for EVPN multicast services. The model is agnostic of the underlay as well as RFC 9251. This document mainly focuses on EVPN instance framework. | ||||||||||||||||
| draft-zheng-ccamp-client-pm-yang-07.txt | |||||||||||||||||
| A YANG Data Model for Client Signal Performance Monitoring | |||||||||||||||||
|
A transport network is a server-layer network to provide connectivity services to its client. Given the client signal is configured, the followup function for performance monitoring, such as latency and bit error rate, would be needed for network operation. This document describes the data model to support the performance monitoring functionalities. | ||||||||||||||||
| draft-zheng-ccamp-client-tunnel-yang-12.txt | |||||||||||||||||
| A YANG Data Model for Client-layer Tunnel | |||||||||||||||||
|
A transport network is a server-layer network to provide connectivity services to its client. In this draft the tunnel of client is described, with the definition of client tunnel YANG model. | ||||||||||||||||
| draft-zhou-alto-dbors-framework-00.txt | |||||||||||||||||
| Database-based Open Resource Service Framework | |||||||||||||||||
|
This document proposes the framework of Database-based Open Resource Service. It contributes to the overall integration of network and cloud by providing fine-granularity differentiated services and increasing resource utilization rate over the cloud and network. | ||||||||||||||||
| draft-zhou-alto-dbors-requirement-usecase-00.txt | |||||||||||||||||
| Requirements and Use Cases of DB-ORS (Database-based Open Resource Service) | |||||||||||||||||
|
This draft introduces the new challenges for the network brought by massive access services under the background of the convergence of the cloud and the network which acquires the network to identify and convey the information of fine-grain user and application requirements, aiming to fulfill differentiated service provisioning and improve the comprehensive utilization of network resources. The draft raises the scope of current solution gap analysis and further proposes the definition of DB-ORS in which network capabilities are abstracted as atomic services and can be orchestrated by applications. Scenarios of cloud access and DCI are outlined to clarify the concepts and principles of DB-ORS in overcoming challenges. | ||||||||||||||||
| draft-zhou-idr-bgp-srmpls-elp-07.txt | |||||||||||||||||
| BGP Extension for SR-MPLS Entropy Label Position | |||||||||||||||||
|
This document proposes extensions for BGP to indicate the entropy label position in the SR-MPLS label stack when delivering SR Policy via BGP. | ||||||||||||||||
| draft-zhou-intarea-aware-route-san-database-00.txt | |||||||||||||||||
| Computing Status Awareness,Advertisement and Service Routing methods Based on Databases of SAN | |||||||||||||||||
|
This draft proposes a unified method to perceive and advertise the running status of computing resources in a Service Awareness Network by introducing a distributed database. The forwarding operation in a fine-grained service routing policy is correspondingly defined which is completely decoupled from conventional IP routing. In the scheme proposed, the impact of high frequency changes of computing resources is avoided and the compatibility of the network is enhanced. | ||||||||||||||||
| draft-zhou-intarea-computing-segment-san-01.txt | |||||||||||||||||
| Computing Segment for Service Routing in SAN | |||||||||||||||||
|
Since services delivered from cloud need delicate coordination among the client, network and cloud, this draft defines a new Segment to provide service routing and addressing functions by leveraging SRv6 Segment programming capabilities. With Computing Segments proposed, the network gains its capability to identify and process SAN header in need and a complete service routing procedure can be achieved. | ||||||||||||||||
| draft-zhou-ippm-enhanced-alternate-marking-12.txt | |||||||||||||||||
| Enhanced Alternate Marking Method | |||||||||||||||||
|
This document extends the IPv6 Alternate Marking Option to provide enhanced capabilities and allow advanced functionalities. With this extension, it can be possible to perform thicker packet loss measurements and more dense delay measurements with no limitation for the number of concurrent flows under monitoring. | ||||||||||||||||
| draft-zhou-rtgwg-sinc-00.txt | |||||||||||||||||
| Signaling In-Network Computing operations (SINC) | |||||||||||||||||
|
This memo introduces "Signaling In-Network Computing operations" (SINC), a mechanism to enable signaling in-network computing operations on data packets in specific scenarios like NetReduce, NetDistributedLock, NetSequencer, etc. In particular, this solution allows to flexibly communicate computational parameters, to be used in conjunction with the payload, to in-network SINC-enabled devices in order to perform computing operations. | ||||||||||||||||
| draft-zhou-rtgwg-sinc-deployment-considerations-00.txt | |||||||||||||||||
| Signaling In-Network Computing operations (SINC) deployment considerations | |||||||||||||||||
|
This document is intended to discuss some aspects of the deployment of "Signaling In-Network Computing operations" (SINC). Based on the actual topology of the SINC domain, this document analyzes how each device in the SINC chain undertakes its own functions. This document provides some specific solutions to the use of SINC mechanism. | ||||||||||||||||
| draft-zhou-spring-srh-le-change-01.txt | |||||||||||||||||
| Define the Value 255 in Last Entry field of Segment Routing Header | |||||||||||||||||
|
This document proposes to define the value 255 in Last Entry field in Segment Routing Header (SRH) [RFC8754], to indicate an SRH without any SID left. | ||||||||||||||||
| draft-zhu-intarea-gma-control-03.txt | |||||||||||||||||
| UDP-based Generic Multi-Access (GMA) Control Protocol | |||||||||||||||||
|
A device can be simultaneously connected to multiple networks, e.g., Wi-Fi, LTE, 5G, and DSL. It is desirable to seamlessly combine the connectivity over these networks below the transport layer (L4) to improve quality of experience for applications that do not have built in multi-path capabilities. This document presents a new control protocol to manage traffic steering, splitting, and duplicating across multiple connections. The solution has been developed by the authors based on their experiences in multiple standards bodies including the IETF and 3GPP, is not an Internet Standard and does not represent the consensus opinion of the IETF. This document will enable other developers to build interoperable implementations in order to experiment with the protocol. | ||||||||||||||||
| draft-zw-tvr-igp-extensions-01.txt | |||||||||||||||||
| IS-IS and OSPF extensions for TVR (Time-Variant Routing) | |||||||||||||||||
|
TVR needs IGP to calculate different results depending on the time, without convergence after the detection of link or nodes. IGP nodes need to learn the predictable and scheduled changes in advance. This document defines the IGP extensions for predictable and scheduled changes of TVR. | ||||||||||||||||
| draft-zwx-bier-te-extensions-02.txt | |||||||||||||||||
| IS-IS and OSPF extensions for BIER-TE (Tree Engineering for Bit Index Explicit Replication) with MPLS and non-MPLS Encapsulation | |||||||||||||||||
|
This document describes the IS-IS and OSPF protocol extensions that are required for BIER-TE and RBS with MPLS and non-MPLS encapsulation. | ||||||||||||||||
| draft-zwx-rift-leaf-ring-02.txt | |||||||||||||||||
| Supporting leaves without northbound neighbors connecting to a fat-tree network using RIFT | |||||||||||||||||
|
This document discusses the usage and solution for leaf nodes without northbound neighbors connecting to a fat-tree network by leaf nodes having direct northbound neighbors in RIFT. | ||||||||||||||||
| draft-zzd-tvr-use-case-tidal-network-00.txt | |||||||||||||||||
| Use Case of Tidal Network | |||||||||||||||||
|
The tidal effect of traffic is very typical on our network, this document introduces the time variant routing scenario in the tidal network, and then describes the assumptions and routing impacts based on the use case. Finally, an exempar of a network to the use case is provided. | ||||||||||||||||
| draft-zzhang-bier-anycast-02.txt | |||||||||||||||||
| BIER with Anycast | |||||||||||||||||
|
BIER architecture currently does not support anycast, in that each BIER Forwarding Router (BFR) has its own unique BFR-prefix and BFR- ID. BIER signaling protocols also check if there are duplicate BFR- IDs advertised. This document discusses and specifies anycast support with BIER. It updates RFC 8279, RFC 8401 and RFC 8444. | ||||||||||||||||
| draft-zzhang-bier-egress-protection-overlay-00.txt | |||||||||||||||||
| BIER Flow Overlay with Anycast Egress Protection | |||||||||||||||||
|
This document discusses considerations and specifies procedures for multicast flow overlay when BIER Anycast is used for egress protection in the context of MVPN and EVPN. Future revisions will cover other flow overlay protocols like PIM/MLD/mLDP. | ||||||||||||||||
| draft-zzhang-dmm-mup-evolution-04.txt | |||||||||||||||||
| Mobile User Plane Evolution | |||||||||||||||||
|
[I-D.zzhang-dmm-5g-distributed-upf] describes evolution of mobile user plane in 5G, including distributed User Plane Functions (UPFs)and alternative user plane implementations that some vendors/ operators are promoting without changing 3GPP architecture/signaling. Building on top of that, this document further discusses potentially integrating UPF and Access Node (AN) in a future generation (xG) of mobile network. This document is not an attempt to do 3GPP work in IETF. Rather, it discusses potential integration of IETF/wireline and 3GPP/wireless technologies - first among parties who are familiar with both areas and friendly with IETF/wireline technologies. If the ideas in this document are deemed reasonable, feasible and desired among these parties, they can then be brought to 3GPP for further discussions. | ||||||||||||||||
| draft-zzhang-idr-tunnel-encapsulation-label-stack-02.txt | |||||||||||||||||
| MPLS Label Stacks in Tunnel Encapsulation Attribute | |||||||||||||||||
|
RFC 9012 defines an MPLS Label Stack sub-TLV for Tunnel Encapsulation Attribute, and specifies that it is to be pushed BEFORE other labels. This document clarifies the use case for that, defines a new Tunnel Label Stack sub-TLV for a label stack to be pushed AFTER other labels (e.g., the label embedded in the NLRI for a labeled address family, and/or the stack in an MPLS Label Stack sub-TLV), and defines two new Segment sub-TLVs to encode a segment list in a compact format. | ||||||||||||||||
| draft-zzhang-mpls-mldp-rsvp-p2mp-srv6-01.txt | |||||||||||||||||
| mLDP/RSVP-TE P2MP Tunnel with SRv6 SID | |||||||||||||||||
|
This document specifies extensions to mLDP and RSVP-TE P2MP protocols to set up mLDP and RSVP-TE P2MP tunnels with SRv6 SIDs intead of MPLS labels. | ||||||||||||||||
| draft-zzhang-pim-multicast-scaling-considerations-00.txt | |||||||||||||||||
| Multicast Scaling Considerations | |||||||||||||||||
|
This informational document discusses various multicast scaling aspects, compares different multicast technologies with respect to scaling, and suggests a general approach of combined solutions to scale multicast. This discussion is independent of IPv4/IPv6 or MPLS/SRv6 data planes. | ||||||||||||||||
| draft-zzhang-spring-microtap-segment-01.txt | |||||||||||||||||
| MicroTap Segment in Segment Routing | |||||||||||||||||
|
This document specifies a microTap segment that can be used to instruct a transit node to make a copy of a segment-routed packet and deliver it to a specified node for the purpose of network monitoring, trouble shooting, or lawful intercept. | ||||||||||||||||
| draft-zzhang-spring-service-interworking-00.txt | |||||||||||||||||
| MPLS/SRv6 Service Interworking Option BC | |||||||||||||||||
|
Draft-bonica-spring-srv6-end-dtm specifies SRv6/MPLS transport interworking procedures, and draft-agrawal-spring-srv6-mpls- interworking specifies SRv6/MPLS transport and service interworking procedures. For service interworking, the latter draft defines two modes, similar to VPN Inter-AS Option A and Option B. This document specifies another Option BC for service interworking which has much better scaling property. | ||||||||||||||||