|
|
| |
| Common Catalog Format for moq-transport |
|
|
This specification defines a Common Catalog specification for streaming formats implementing the MOQ Transport Protocol [MoQTransport]. Media over QUIC Transport (MOQT) defines a publish/ subscribe based unified media delivery protocol for delivering media for streaming and interactive applications over QUIC. The catalog describes the content made available by a publisher, including information necessary for subscribers to select, subscribe and initialize tracks. |
| 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. |
| Legacy RSASSA-PKCS1-v1_5 codepoints for TLS 1.3 |
|
|
This document allocates code points for the use of RSASSA-PKCS1-v1_5 with client certificates in TLS 1.3. This removes an obstacle for some deployments to migrate to TLS 1.3. |
|
|
| |
| 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. Another use case is using CWT claims with payloads that are not CWT Claims Sets, including payloads that are not CBOR at all. |
| Using DNSSEC Authentication of Named Entities (DANE) with DNS Service Bindings (SVCB) and QUIC |
|
|
Service Binding (SVCB) records introduce a new form of name indirection in DNS. They also convey information about the endpoint's supported protocols, such as whether QUIC transport is available. This document specifies how DNS-Based Authentication of Named Entities (DANE) interacts with Service Bindings to secure connections, including use of port numbers and transport protocols discovered via SVCB queries. The "_quic" transport name label is introduced to distinguish TLSA records for DTLS and QUIC. |
| 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. |
| 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. |
| LibrePGP Message Format |
|
|
This document specifies the message formats used in LibrePGP. LibrePGP is an extension of the OpenPGP format which 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 LibrePGP 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 is based on: RFC 4880 (OpenPGP), RFC 5581 (Camellia in OpenPGP), and RFC 6637 (Elliptic Curves in OpenPGP). |
| Legacy RSASSA-PKCS1-v1_5 codepoints for TLS 1.3 |
|
|
This document allocates code points for the use of RSASSA-PKCS1-v1_5 with client certificates in TLS 1.3. This removes an obstacle for some deployments to migrate to TLS 1.3. |
| RADIUS accounting via IPFIX |
|
|
The Remote Authentication Dial In User Server (RADIUS) Protocol provides for a number of simple session-based metrics. There is a need to increase the number of metrics, and to add metrics for individual flows within a session. This document leverages IP Flow Information Export (IPFIX) to address both needs. |
|
|
| |
| Credentials Provisioning and Management via EAP (EAP-CREDS) |
|
|
With the increase number of devices, protocols, and applications that rely on strong credentials (e.g., digital certificates, keys, or tokens) for network access, the need for a standardized credentials provisioning and management framework is paramount. The 802.1x architecture allows for entities (e.g., devices, applications, etc.) to authenticate to the network by providing a communication channel where different methods can be used to exchange different types of credentials. However, the need for managing these credentials (i.e., provisioning and renewal) is still a hard problem to solve. Usually, credentails used in an access network can be in different levels (e.g., network-level, user-level) and sometimes tend to live unmanaged for quite a long time due to the challenges of operation and implementation. EAP-CREDS (RFC XXXX), if implemented in Managed Networks (e.g., Cable Modems), could enable our operators to offer a registration and credentials management service integrated in the home WiFi thus enabling visibility about registered devices. During initialization, EAP-CREDS also allows for MUD files or URLs to be transferred between the EAP Peer and the EAP Server, thus giving detailed visibility about devices when they are provisioned with credentials for accessing the networks. The possibility provided by EAP-CREDS can help to secure home or business networks by leveraging the synergies of the security teams from the network operators thanks to the extended knowledge of what and how is registered/ authenticated. This specifications define how to support the provisioning and management of authentication credentials that can be exploited in different environments (e.g., Wired, WiFi, cellular, etc.) to users and/or devices by using EAP together with standard provisioning protocols. |
| Security Profiles in Bootstrap Voucher Artifacts |
|
|
This document describes an extension of the RFC8366 Voucher Artifact in order to support security profiles. This allows the owner to change and customize the security posture of the device dynamically and securely. This lets the owner to selectively enable or disable each of the underlying security parameters that make up the security posture of the device. |
|
|
| |
| 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. |
| 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. |
| 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, rejoining thereafter, and to easily splice in additional service functions or splice service functions out of a service chain. The IETF has received a liaison from International Telecommunication Union (ITU) indicating their interest in such requirements. This document provides use cases and specifies extensions to SFC to support these requirements. |
| Realizing Network Slices in IP/MPLS Networks |
|
| draft-ietf-teas-ns-ip-mpls-03.txt |
| Date: |
26/11/2023 |
| Authors: |
Tarek Saad, Vishnu Beeram, Jie Dong, Bin Wen, Daniele Ceccarelli, Joel Halpern, Shaofu Peng, Ran Chen, Xufeng Liu, Luis Contreras, Reza Rokui, Luay Jalil |
| Working Group: |
Traffic Engineering Architecture and Signaling (teas) |
|
Realizing network slices may require the Service Provider to have the ability to partition a physical network into multiple logical networks of varying sizes, structures, and functions so that each slice can be dedicated to specific services or customers. Multiple network slices can be realized on the same network while ensuring slice elasticity in terms of network resource allocation. This document describes a scalable solution to realize network slicing in IP/MPLS networks by supporting multiple services on top of a single physical network by relying on compliant domains and nodes to provide forwarding treatment (scheduling, drop policy, resource usage) on to packets that carry identifiers that indicate the slicing service that is to be applied to the packets. |
|
|
| |
| BGP Link-State Shortest Path First (SPF) Routing |
|
| draft-ietf-lsvr-bgp-spf-29.txt |
| Date: |
25/11/2023 |
| Authors: |
Keyur Patel, Acee Lindem, Shawn Zandi, Wim Henderickx |
| Working Group: |
Link State Vector Routing (lsvr) |
|
Many Massively Scaled Data Centers (MSDCs) have converged on simplified layer 3 routing. Furthermore, requirements for operational simplicity has 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. |
| Towards a CAP Theorem for Censorship Circumvention |
|
|
This Internet-Draft is a submission to the IAB Workshop on Barriers to Internet Access of Services [biasws]. 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-cfm-circumvention-cap- theorem/. Source for this draft and an issue tracker can be found at https://github.com/cfm/draft-cfm-circumvention-cap-theorem. |
|
|
| |
| 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. |
| 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. |
| OAuth 2.0 Web Message Response Mode for Popup- and Iframe-based Authorization Flows |
|
|
This specification defines the web message response mode that authorization servers use for transmitting authorization response parameters via the user-agent's postMessage API to the client. This mode is intended for authorization flows that use secondary windows, which are well-suited for browser-based applications. |
| Guidance for HTTP Capsule Protocol Extensibility |
|
|
This document updates RFC 9297 with further guidance for extensibility of the HTTP Capsule Protocol. |
|
|
| |
| 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. |
| 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. |
| Distributed Ledger Time-Stamp |
|
| draft-intesigroup-dlts-07.txt |
| Date: |
22/11/2023 |
| Authors: |
Emanuele Cisbani, Daniele Ribaudo, Giuseppe Damiano |
| Working Group: |
Individual Submissions (none) |
|
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. |
| BGP Extensions for Source Address Validation Networks (BGP SAVNET) |
|
| draft-geng-idr-bgp-savnet-03.txt |
| Date: |
22/11/2023 |
| Authors: |
Nan Geng, Zhenbin Li, Zhen Tan, Mingxing Liu, Dan Li, Fang Gao |
| Working Group: |
Individual Submissions (none) |
|
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 scenarios. This document proposes BGP SAVNET by extending BGP protocol for SAV. This protocol can propagate SAV-related information through BGP messages. The propagated information will help edge/border routers automatically generate accurate SAV rules. These rules construct a validation boundary for the network and help check the validity of source addresses of arrival data packets. |
| SR based Loop-free implementation |
|
|
Microloops are brief packet loops that occur in the network following a topology change (link down, link up, node fault, or metric change events). Microloops are caused by the non-simultaneous convergence of different nodes in the network. If nodes converge and send traffic to a neighbor node that has not converged yet, traffic may be looped between these two nodes, resulting in packet loss,jitter, and out-of-order packets. This document presents some optional implementation methods aimed at providing loop avoidance in the case of IGP network convergence event in different scenarios. |
| The DNS-Based scheme to revoke certificates in Transport Layer Security (TLS) Protocol: TLSR |
|
|
This memo presents the definition of a new DNS resouce record type named TLSR, and then discusses a new framework for certificate revocation and certificate status verification. This document can solve the existing problems in the current certificate revocation schemes. This requires matching improvements in TLS client software, but no change in TLS server software. |
| Deterministic Networks - Navigating Precision in Communication |
|
|
This document offers a comprehensive overview of deterministic networks, elucidating their significance, key characteristics, and the challenges they address in comparison to non-deterministic counterparts. With a focus on Time-Sensitive Networking (TSN) and Precision Time Protocol (PTP), the technological aspects are explored, encompassing synchronization mechanisms, traffic shaping, and security considerations. Real-world applications in industrial automation, control systems, and multimedia streaming underscore the practical relevance of deterministic networks. The document emphasizes the importance of precise time synchronization, security measures, and collaboration within the networking community. Through acknowledgments, the collaborative efforts of the Deterministic Networking (DetNet) Working Group, authors of relevant standards, and the broader community are recognized, highlighting the collective dedication to advancing deterministic networking technologies. |
|
|
| |
| 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. |
| 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. |
| Control Plane of Inter-Domain Source Address Validation Architecture |
|
| draft-xu-savax-control-06.txt |
| Date: |
21/11/2023 |
| Authors: |
Ke Xu, Jianping Wu, Xiaoliang Wang, Yangfei Guo |
| Working Group: |
Individual Submissions (none) |
|
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 machines to generate consistent tags. When communicating between two end hosts at different ADs of the IPv6 network, tags will be added to the packets to identify the authenticity of the IPv6 source address. |
| Data Plane of Inter-Domain Source Address Validation Architecture |
|
| draft-xu-savax-data-05.txt |
| Date: |
21/11/2023 |
| Authors: |
Ke Xu, Jianping Wu, Xiaoliang Wang, Yangfei Guo |
| Working Group: |
Individual Submissions (none) |
|
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 machines to generate consistent tags. When communicating between two end hosts at different ADs of the IPv6 network, tags will be added to the packets to identify the authenticity of the IPv6 source address. This memo focuses on the data plane of the SAVA-X mechanism. |
| 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 machines to generate consistent tags. When communicating between two end hosts at different ADs of the IPv6 network, tags will be added to the packets to identify the authenticity of the IPv6 source address. This memo focuses on the data plane of the SAVA-X mechanism. |
| IBM i Telnet Enhancements |
|
|
This obsoletes RFC4777 with an enhanced Automatic Sign-On PBKDF2 with HMAC SHA-512 password hash available with systems running with V7R5M0 or later and configured to use Password Level (QPWDLVL) 4 or higher for the user profile passwords Section 5.3. Require use of Transport Layer Security (TLS) to secure the telnet session between the Telnet server and client Section 13. Add Telnet Device Negotiation Termination Section 10.5 documenting how telnet clients that do not follow 5250 negotiation are handled. Document use of Transport Layer Security (TLS) using port 992 Section 14. Enhancement to add Multi Factor Authentication to automatic sign-on Changes since -00 Draft * Update abstract for PBKDF2 with HMAC SHA-512 password hash * Document use of Transport Layer Security (TLS) in Security Considerations Section 13 Changes since -01 Draft * TLS handshake must complete before invite for terminal type is sent in Section 2 * Change using TLS from RECOMENDED to REQUIRED to be ccompliant with this draft Section 13 * Change disabling port 23 from RECOMENDED to REQUIRED Section 13 * Detail use and related DCM configuration for TLS Section 13 * Add IANA Considerations use of port 992 for Telnet using TLS/SSL (service telnet-ssl) to Section 14 * Include "application definition" and "Digital Certificate Manager (DCM)" to Section 1.1 * Update abstract for Authentication factor in Section 5 * Update Response Codes for Authentication factor in Section 10.4 |
| Flooding Reduction in CLOS Networks |
|
|
In a CLOS topology, an OSPF (or ISIS) router may receive identical copies of an LSA (or LSP) from multiple OSPF (or ISIS) neighbors. Moreover, two OSPF (or ISIS) neighbors may exchange the same LSA (or LSP) simultaneously. This results in unnecessary flooding of link- state information, which wastes the precious resources of OSPF (or ISIS) routers. Therefore, this document proposes extensions to OSPF (or ISIS) to reduce this flooding within CLOS networks. The reduction of OSPF (or ISIS) flooding is highly beneficial for improving the scalability of CLOS networks. |
|
|
| |
| 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, which is typically the case for intangible media such as wireless and overlays. A study of the issues with IPv6 ND over intangible media is presented, and a framework to solve those issues within the new architecture is proposed. |
| 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. |
| 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 the 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. |
| Generalized Arguments of SRv6 Segment |
|
|
This document analyzes the challenges of Arguments of SRv6 SID, and the chance of using Arguments of SRv6 SID to reduce the length of the IPv6 extension header. According to these analysis, this document specifies a kind of generalized and structured Arguments for SRv6 SID, which can carry multiple Arguments parts for a SRv6 SID. |
| Simple Random Candidate Selection |
|
|
This document describes a process to randomly select a subset of named candidates from a larger set of candidates. The process uses an unpredictable value that can be trusted by all candidates. This draft has a GitHub repository (https://github.com/paulehoffman/ draft-hoffman-random-candidate-selection). Issues and pull requests can be made there. |
|
|
| |
| 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. |
| Update to Message Submission for Mail |
|
|
This memo adds updated advice for e-mail message submission. This memo also offers guidance to software that constructs a message envelope from a message's headers prior to submission. |
|
|
| |
| A Concise Binary Object Representation (CBOR) of DNS Messages |
|
| draft-lenders-dns-cbor-06.txt |
| Date: |
17/11/2023 |
| Authors: |
Martine Lenders, Carsten Bormann, Thomas Schmidt, Matthias Waehlisch |
| Working Group: |
Individual Submissions (none) |
|
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. |
| 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. |
| QUIC Accurate ECN Acknowledgements |
|
|
QUIC defines a variant of the ACK frame that carries cumulative count for each of the three ECN codepoints (ECT(1), ECT(0) and CE). From this information, the recipient of the ACK frame cannot deduce which ECN marking the individual packets were received with. This document defines an alternative ACK frame that encodes enough information to indicate which ECN mark each individual packet was received with. |
| 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. |
|
|
| |
| AC-Aware Bundling Service Interface in EVPN |
|
|
An EVPN (Ethernet VPNs) provides an extensible and flexible multihoming 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 Integrated Routing and Bridging (IRB) is one of the common deployment scenarios. Some deployments requires the capability to have multiple subnets designated with multiple VLAN IDs in the 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 a single broadcast domain. In this document, we define a new service interface type to support multiple subnets in the single broadcast domain. Service interface proposed in this document will be applicable to multihoming cases only. |
| The Use Cases for Secure Routing Path |
|
|
Current routing mechanism is based on the shortest path, which only take the link status and the path accessibility into consideration, without the security and trustworthiness 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. |
| EPP Pre-Registration Verification |
|
|
This Internet Draft introduces an extension to the Extensible Provisioning Protocol (EPP) for top-level domain (TLD) registries, enabling registrars to submit pre-registration information for domain names. The extension facilitates quality verification by the registry, employing advanced Artificial Intelligence and Machine Learning (AI/ML) techniques. Pre-registrations are assigned a quality score based on the analysis of the submitted data, ranging from 0 for non-abusive registrations to 100 for potentially abusive ones. This extension addresses the critical need to proactively identify and mitigate abusive domain registrations within TLDs, contributing to a safer and more reliable internet environment. The document outlines the EPP command definitions, XML schemas, data flow, and security considerations necessary to implement this innovative quality assurance mechanism, thereby enhancing the integrity and trustworthiness of TLD registrations. |