| Internet-Draft | EVPN Route Type Experimental | March 2026 |
| Tantsura & Talaulikar | Expires 21 September 2026 | [Page] |
This document reserves codepoints in the EVPN Route Type registry for experimental use to enable implementations to carry out development and test of new EVPN features. It updates RFC7432 to modify the registration policy for the EVPN Route Type registry.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 21 September 2026.¶
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
Ethernet VPN (EVPN) [RFC7432] uses BGP for the distribution of reachability and membership information. EVPN network layer reachability information (NLRI) is carried in BGP using the EVPN SAFI (70) and includes a one-octet Route Type field that identifies the type of EVPN route (e.g., Ethernet Auto-Discovery, MAC/IP Advertisement, Inclusive Multicast Ethernet Tag, etc.). The EVPN Route Type registry [IANA-EVPN-ROUTE] is maintained by IANA and was created by [RFC7432].¶
New EVPN route types are assigned through the "RFC Required" registration procedure. There is currently no reserved range in the EVPN Route Type registry for experimental use. Implementors and deployers who wish to experiment with new route types, without requesting an IANA assignment, have no designated codepoint space and risk conflicting with assignments via other specifications being developed in parallel.¶
This document reserves codepoint space in the EVPN Route Type registry [IANA-EVPN] for experimental use. This approach aligns this registry with the practice of providing a clear, bounded space for experimental use to avoid conflicts and to discourage the practice of taking up codepoints without formal allocations in early development phases of implementations.¶
This document updates [RFC7432] as it modifies the registration policy for the EVPN Route Type registry by carving out space for experimental use.¶
IANA is requested to modify the registration policy of the "EVPN Route Types" registry [IANA-EVPN-ROUTES] in the "Ethernet VPN (EVPN)" registry group [IANA-EVPN] by carving out the range of values 224 to 255 for Experimental Use [RFC8126]. The registration policy for the rest of the space from 0 to 223 remains RFC Required as defined in [RFC7432].¶
IANA is requested to add this document as a reference for this registry along with [RFC7432]. As specified in [RFC8126], IANA is not required to maintain any record of allocations in the experimental codepoint space. Table 1 describes the entry in the registry for the experimental range.¶
| Value | Description | Reference |
| 224-255 | Experimental Use (not assigned by IANA) | This document |
Reserving a range of EVPN Route Types for experimental use does not introduce new security issues beyond those already present in EVPN [RFC7432]. Implementations that process EVPN NLRI with route types in the reserved range (224-255) should apply the same validation and policy controls as for other route types. Deployments using experimental route types should ensure that only trusted peers exchange such NLRI, and that the semantics of the route type are agreed upon within the deployment to avoid misinterpretation.¶