- Home
- RFCs by Subject
- link layer
- Ethernet
Ethernet
IP over Ethernet, Ethernet interworking and OAM
Within this page
Ethernet RFCs (149)
RFC 10018: Multicast and Ethernet VPN with Segment Routing Point-to-Multipoint (P2MP) and Ingress Replication
Proposed Standard- R. Parekh
- D. Voyer
- C. Filsfils
- H. Bidgoli
- Z. Zhang
- August 2026
- IETF publication
- Routing Area
Abstract
A Point-to-Multipoint (P2MP) tree in a Segment Routing (SR) domain carries traffic from a Root to a set of Leaves. This document specifies extensions to BGP encodings and procedures for P2MP trees and Ingress Replication used in BGP/MPLS IP VPNs and Ethernet VPNs (EVPNs) in an SR domain. This document updates RFCs 6514 and 7988.
Abstract
A Point-to-Multipoint (P2MP) tree in a Segment Routing (SR) domain carries traffic from a Root to a set of Leaves. This document specifies extensions to BGP encodings and procedures for P2MP trees and Ingress Replication used in BGP/MPLS IP VPNs and Ethernet VPNs (EVPNs) in an SR domain. This document updates RFCs 6514 and 7988.
RFC 10031: Media Access Control (MAC) Addresses in X.509 Certificates
Proposed Standard- R. Housley
- C. Bonnell
- J. Mandel
- T. Okubo
- M. StJohns
- August 2026
- IETF publication
- Security Area
Abstract
This document defines a new GeneralName.otherName for inclusion in the X.509 Subject Alternative Name (SAN) and Issuer Alternative Name (IAN) extensions to carry an IEEE Media Access Control (MAC) address. The new name form makes it possible to bind a Layer 2 interface identifier to a public key certificate. Additionally, this document defines how constraints on this name form can be encoded and processed in the X.509 Name Constraints extension (NCE).
Abstract
This document defines a new GeneralName.otherName for inclusion in the X.509 Subject Alternative Name (SAN) and Issuer Alternative Name (IAN) extensions to carry an IEEE Media Access Control (MAC) address. The new name form makes it possible to bind a Layer 2 interface identifier to a public key certificate. Additionally, this document defines how constraints on this name form can be encoded and processed in the X.509 Name Constraints extension (NCE).
RFC 9892: Dynamic Link Exchange Protocol (DLEP) Traffic Classification Data Item
Proposed Standard- B. Cheng
- D. Wiggins
- L. Berger
- D. Fedyk
- January 2026
- IETF publication
- Routing Area
Abstract
This document defines a new Data Item for the Dynamic Link Exchange Protocol (DLEP) to support traffic classification. Traffic classification information identifies traffic flows based on frame/packet content such as a destination address. The Data Item is defined in an extensible and reusable fashion. Its use will be mandated in other documents defining specific DLEP extensions. This document also introduces DLEP Sub-Data Items and defines two new Sub-Data Items to support Diffserv and Ethernet traffic classification.
Abstract
This document defines a new Data Item for the Dynamic Link Exchange Protocol (DLEP) to support traffic classification. Traffic classification information identifies traffic flows based on frame/packet content such as a destination address. The Data Item is defined in an extensible and reusable fashion. Its use will be mandated in other documents defining specific DLEP extensions. This document also introduces DLEP Sub-Data Items and defines two new Sub-Data Items to support Diffserv and Ethernet traffic classification.
RFC 9895: Dynamic Link Exchange Protocol (DLEP) IEEE 802.1Q Aware Credit Window Extension
Proposed Standard- D. Wiggins
- L. Berger
- D. Eastlake 3rd
- January 2026
- IETF publication
- Routing Area
Abstract
This document defines an extension to the Dynamic Link Exchange Protocol (DLEP) that enables an Ethernet IEEE 802.1Q aware credit window scheme for destination-specific and shared flow control.
Abstract
This document defines an extension to the Dynamic Link Exchange Protocol (DLEP) that enables an Ethernet IEEE 802.1Q aware credit window scheme for destination-specific and shared flow control.
RFC 9784: Virtual Ethernet Segments for EVPN and Provider Backbone Bridge EVPN
Proposed Standard- A. Sajassi
- P. Brissette
- R. Schell
- J. Drake
- J. Rabadan
- June 2025
- IETF publication
- Routing Area
Abstract
Ethernet VPN (EVPN) and Provider Backbone Bridge EVPN (PBB-EVPN) introduce a comprehensive suite of solutions for delivering Ethernet services over MPLS/IP networks. These solutions offer advanced multihoming capabilities. Specifically, they support Single-Active and All-Active redundancy modes for an Ethernet Segment (ES), which is defined as a collection of physical links connecting a multihomed device or network to a set of Provider Edge (PE) devices. This document extends the concept of an ES by allowing an ES to be associated with a set of Ethernet Virtual Circuits (EVCs), such as VLANs, or other entities, including MPLS Label Switched Paths (LSPs) or pseudowires (PWs). This extended concept is referred to as virtual Ethernet Segments (vESes). This document lists the requirements and specifies the necessary extensions to support vES in both EVPN and PBB-EVPN.
Abstract
Ethernet VPN (EVPN) and Provider Backbone Bridge EVPN (PBB-EVPN) introduce a comprehensive suite of solutions for delivering Ethernet services over MPLS/IP networks. These solutions offer advanced multihoming capabilities. Specifically, they support Single-Active and All-Active redundancy modes for an Ethernet Segment (ES), which is defined as a collection of physical links connecting a multihomed device or network to a set of Provider Edge (PE) devices. This document extends the concept of an ES by allowing an ES to be associated with a set of Ethernet Virtual Circuits (EVCs), such as VLANs, or other entities, including MPLS Label Switched Paths (LSPs) or pseudowires (PWs). This extended concept is referred to as virtual Ethernet Segments (vESes). This document lists the requirements and specifies the necessary extensions to support vES in both EVPN and PBB-EVPN.