EVPN First Hop Security
draft-ietf-bess-evpn-first-hop-security-01
| Document | Type | Active Internet-Draft (bess WG) | |
|---|---|---|---|
| Authors | Ali Sajassi , Lukas Krattiger , Krishnaswamy Ananthamurthy , Jorge Rabadan , Wen Lin | ||
| Last updated | 2026-07-22 | ||
| Replaces | draft-sajassi-bess-evpn-first-hop-security | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Additional resources | Mailing list discussion | ||
| Stream | WG state | WG Document | |
| Document shepherd | (None) | ||
| IESG | IESG state | I-D Exists | |
| Consensus boilerplate | Unknown | ||
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-ietf-bess-evpn-first-hop-security-01
BESS Working Group A. Sajassi
Internet-Draft L. Krattiger
Intended status: Standards Track K. Ananthamurthy
Expires: 23 January 2027 Cisco
J. Rabadan
Nokia
W. Lin
Juniper Networks, Inc.
22 July 2026
EVPN First Hop Security
draft-ietf-bess-evpn-first-hop-security-01
Abstract
The Dynamic Host Configuration Protocol (DHCP) snoop database stores
valid IPv4-to-MAC and IPv6-to-MAC bindings by snooping on DHCP
messages. These bindings are used by security functions like Dynamic
Address Resolution Protocol 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 Ethernet VPN (EVPN)
procedures to distribute and synchronize the DHCP snoop database to
support FHS. Such synchronization is needed to support EVPN host
mobility and multihoming.
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
Status of This Memo
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/.
Sajassi, et al. Expires 23 January 2027 [Page 1]
Internet-Draft EVPN First Hop Security July 2026
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 23 January 2027.
Copyright Notice
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. DHCP Snoop Primer . . . . . . . . . . . . . . . . . . . . . . 6
3.1. DHCP Snoop binding entry . . . . . . . . . . . . . . . . 8
4. Synchronizing DHCP Snoop Database . . . . . . . . . . . . . . 8
4.1. DHCP Snoop Anchor PE . . . . . . . . . . . . . . . . . . 9
4.2. DHCP Message Synchronization . . . . . . . . . . . . . . 10
4.3. Bridged Service . . . . . . . . . . . . . . . . . . . . . 10
4.3.1. DHCP IP Address Allocation and Lease for Bridged
Service . . . . . . . . . . . . . . . . . . . . . . . 10
4.3.2. DHCP IP Address Renewal for Bridged Service . . . . . 12
4.4. IRB Service . . . . . . . . . . . . . . . . . . . . . . . 13
4.4.1. DHCP IP Address Allocation and Lease for IRB
Service . . . . . . . . . . . . . . . . . . . . . . . 13
4.4.2. DHCP IP Address Renewal for IRB Service . . . . . . . 14
4.5. DSR handling on non-ESI PEs . . . . . . . . . . . . . . . 15
5. DHCP Snoop Anchor Mobility . . . . . . . . . . . . . . . . . 15
6. Host Mobility and Age-Out . . . . . . . . . . . . . . . . . . 17
7. Race Conditions . . . . . . . . . . . . . . . . . . . . . . . 17
7.1. Inter-ES Mobility . . . . . . . . . . . . . . . . . . . . 17
7.2. Intra-ES Synchronization . . . . . . . . . . . . . . . . 18
8. BGP EVPN DSR . . . . . . . . . . . . . . . . . . . . . . . . 18
8.1. Create and Lease Time Handling . . . . . . . . . . . . . 20
9. Security Considerations . . . . . . . . . . . . . . . . . . . 20
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
Sajassi, et al. Expires 23 January 2027 [Page 2]
Internet-Draft EVPN First Hop Security July 2026
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
11.1. Normative References . . . . . . . . . . . . . . . . . . 20
11.2. Informative References . . . . . . . . . . . . . . . . . 21
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
1. Introduction
The 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).
FHS may be leveraged by Ethernet VPN (EVPN) [RFC7432] PEs operating
in bridge mode or in IRB mode (with distributed anycast default
gateway functionality [RFC9135]) in Data Center (DC), Enterprise,
and/or Service Provider (SP) networks to enhance the security of such
networks. This document proposes BGP extensions and new procedures
for EVPN to support FHS in the presence of EVPN multihoming and host
mobility by distributing DHCP snoop bindings among EVPN PEs
participating in that EVPN Broadcast Domain. These bindings need to
be distributed among multihoming PEs to synchronize DHCP snoop state
and among all PEs participating in the EVPN Broadcast Domain so that
host mobility procedures continue to operate correctly. I.e., when a
host moves from the current EVPN peer to a new EVPN peer, then the
new EVPN peer shall have the bindings so that it can continue
performing FHS without any interruption.
DAI and NDI use the DHCP snoop database to validate received ARP
messages and ND messages, respectively. Likewise, IPv4 Source Guard
and IPv6 Source Guard use this database to validate source IPv4 and
IPv6 addresses, respectively, before forwarding traffic. While FHS
mechanisms that rely on the DHCP snoop database are widely deployed
on access switches (without standard-based multihoming or host
mobility), there is a need to extend the application of FHS on EVPN
PEs supporting Network Virtualization Overlay (NVO) and running
multihoming (All-Active or Single-Active) with host mobility.
Unfortunately, the lack of DHCP snoop binding on EVPN PEs would lead
to failure of FHS (i.e., IP Source Guard, DAI, and NDI) when a host
is multi-homed to multiple PEs (e.g., All-Active or Single-Active)
and/or when a host moves from one PE to another PE. This is because
when the host is All-Active multi-homed among multiple PEs, DHCP
messages can arrive on different multihoming PEs without a single PE
(in the multihoming/redundancy group) seeing DHCP exchanges needed to
Sajassi, et al. Expires 23 January 2027 [Page 3]
Internet-Draft EVPN First Hop Security July 2026
build DHCP snoop database as described in Section 4. Since it is
possible that none of the PEs in the redundancy group observes the
complete DHCP exchange needed to build DHCP snoop database, then none
of the PEs in the group can establish the DHCP snoop binding, which
in turn, causes failure of FHS. Furthermore, when a host moves from
an old PE to a new PE, the new PE does not have the DHCP binding for
that host. Since the new PE would not have the DHCP snoop binding,
both IP Source Guard and DAI/NDI would start dropping packets
originating from that host, resulting in FHS failure, which in turn
results in service failure.
[RFC7513] proposes procedures that enable adding source address
validation on a device based on DHCP exchanges. Their approach
differs from that of ours in two ways. First, when the host moves
from one PE to another PE, [RFC7513] Section 7.1 offers a
probabilistic solution. Our approach provides a deterministic
solution by proactively sending DHCP snoop updates from one PE to
another so that the new PE would have the information it needs before
the host moves to it. Second, [RFC7513] Section 5 identifies the
need to distribute the DHCP snoop bindings but does not provide a
procedures for distribution. Our approach offers an extension to
EVPN protocol to distribute the DHCP snoop bindings.
2. Terminology
All-Active Redundancy Mode: When all PEs attached to an Ethernet
segment are allowed to forward known unicast traffic to/from that
Ethernet segment for a given VLAN, then the Ethernet segment is
defined to be operating in All-Active redundancy mode.
ASBR: Autonomous System Boundary Router.
Backup-DF (BDF): Backup-Designated Forwarder.
BD: Broadcast Domain.
DC: Data Center.
DF: Designated Forwarder. A DF is a PE device that is selected from
among a group of PE devices that participate in EVPN multihoming.
It is the role of DF PE to forward Broadcast, Unicast, and
Multicast (BUM) Layer 2 messages to the host that is multi-homed
to all the PEs. DF PE is selected on a per-EVI basis.
DHCP: Dynamic Host Configuration Protocol.
DHCP Client: A DHCP client is a host that gets an address assignment
from a DHCP server.
Sajassi, et al. Expires 23 January 2027 [Page 4]
Internet-Draft EVPN First Hop Security July 2026
DHCP Server: A server that assigns network addresses to its clients.
DHCP Snoop Anchor: A PE device that originates a DHCP Snoop Route.
It is this device that uses the DHCP Snoop bindings to do source
address validation for hosts that sit behind it.
DHCP Snoop Route (DSR): EVPN Route to sync DHCP Snoop binding.
DORA : Discover, Offer, Request, Acknowledge.
epoch: The epoch is 1st January 1970 at 00:00 UTC.
Ethernet Segment (ES): When a customer site (device or network) is
connected to one or more PEs via a set of Ethernet links, then
that set of links is referred to as an 'Ethernet segment'.
Ethernet Segment Identifier (ESI): A unique non-zero identifier that
identifies an Ethernet segment is called an Ethernet Segment
Identifier'.
Ethernet Tag: Used to represent a BD that is configured on a given
ES for the purposes of DF election and <EVI, BD> identification
for frames received from the CE. Note that any of the following
may be used to represent a BD: VIDs (including Q-in-Q tags),
configured IDs, VNIs (Virtual Extensible Local Area Network
(VXLAN) Network Identifiers), normalized VIDs, I-SIDs (Service
Instance Identifiers), etc., as long as the representation of the
BDs is configured consistently across the multihomed PEs attached
to that ES.
Ethernet Tag ID: Normalized network wide ID that is used to identify
a BD within an EVI and carried in EVPN routes.
EVI: An EVPN instance spanning the Provider Edge (PE) devices
participating in that EVPN. An EVI may be comprised of one BD
(VLAN-based, VLAN Bundle, or Port-based services) or multiple BDs
(VLAN-aware Bundle or Port-based VLAN-Aware services).
IRB: Integrated Routing and Bridging interface, with EVPN procedures
described in [RFC9135]
MAC-VRF: A Virtual Routing and Forwarding table for Media Access
Control (MAC) addresses on a PE.
Non-DF (NDF): Non-Designated Forwarder.
NVO: Network Virtualization Overlay as described in [RFC8365]
Sajassi, et al. Expires 23 January 2027 [Page 5]
Internet-Draft EVPN First Hop Security July 2026
PE: Provider Edge device.
Single-Active Redundancy Mode: When only a single PE, among all the
PEs attached to an Ethernet segment, is allowed to forward traffic
to/from that Ethernet segment for a given VLAN, then the Ethernet
segment is defined to be operating in Single-Active redundancy
mode.
SP: Service Provider.
UTC: Coordinated Universal Time.
VID: VLAN Identifier.
3. DHCP Snoop Primer
Understanding basic DHCP operation is paramount to understand the
DHCP snooping operation on a non-distributed switch where no
synchronization is needed. DHCP snooping is based on snooping of
DHCP handshake between the host and the DHCP server. The handshake
consists of four messages, sometimes known as the DORA exchange
(Figure 1) which is described in [RFC2131].
Sajassi, et al. Expires 23 January 2027 [Page 6]
Internet-Draft EVPN First Hop Security July 2026
---------------------------------------------
| |
| |
| |
| 1. Discover |
| -----------------------------> |
| | 2. Offer | |
| | <------------------------- | |
| | | 3. Request | | |
| | | ---------------------> | | |
| | | | 4. Ack | | | |
| | | | <----------------- | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
---------------------------------------------
| SW1 | | SW2 |
--------- ---------
| |
| |
| |
DHCP Client (Host) DHCP Server
Figure 1: Typical DHCP DORA Exchange
1. Discover (DHCPDISCOVER): Initial DHCP message sent by the host
(or the DHCP client) to discover DHCP server(s) in the network.
2. Offer (DHCPOFFER): Once a DHCP server receives the Discover
message, it responds with an offer of an IP address that can be
assigned to the host. There can be multiple DHCP servers in the
network and hence multiple servers can respond to the Discover
message by sending their own Offer message.
3. Request (DHCPREQUEST): Once the host receives one or more of the
above offers, it sends a request to one of the DHCP servers
confirming that it has accepted its offer.
4. Acknowledge (DHCPACK): The DHCP server sends the last DHCP
message for which the Request message was sent. The message is
sent to indicate the completion of the IP assignment mechanism.
Sajassi, et al. Expires 23 January 2027 [Page 7]
Internet-Draft EVPN First Hop Security July 2026
3.1. DHCP Snoop binding entry
DHCP snoop binding is created using DHCPREQUEST and DHCPACK messages.
Section 2 of [RFC2131] defines the DHCP message fields and the
following are some of the key fields to understand the exchange of
DHCPREQUEST and DHCPACK messages.
* 'ciaddr': Client IP address; only filled in if client is in BOUND,
RENEW or REBINDING state and can respond to ARP requests.
* 'giaddr': Relay agent IP address, used in booting via a relay
agent.
* 'yiaddr': 'your' (client) IP address.
DHCP client-server interaction is defined in section 3 of [RFC2131],
which are
1. Client-server interaction - allocating a network address.
2. Client-server interaction - reusing a previously allocated
network address
When a host is connected to a single switch (e.g., SW1), both
DHCPREQUEST and DHCPACK messages pass through the same switch. Thus,
the switch (SW1 in this case) can build and validate its state for
DHCP snoop for that host. If SW1 relies on just a single DHCP
message (such as DHCPACK that contains all the needed info) instead
of both DHCPREQUEST and DHCPACK to build its DHCP snoop state, then
it exposes itself to security risks and hijacking MAC/IP binding when
a rogue DHCPACK is received.
4. Synchronizing DHCP Snoop Database
Considering the distributed nature of EVPN application in providing
distributed bridge and distributed host gateway functions over a DC,
Enterprise, and/or SP network, the synchronization challenges of
providing FHS over such a distributed system need to be addressed.
The two main challenges are the synchronization of the DHCP snoop
database (used in FHS) for both EVPN multihoming and EVPN host
mobility.
The synchronization procedures needed in EVPN to address these two
challenges are depend on the type of EVPN service being provided -
i.e., bridge service vs. Integrated Routing and Bridging (IRB)
service. Therefore, we organize the synchronization procedures
needed based on the EVPN services in the following subsections.
Sajassi, et al. Expires 23 January 2027 [Page 8]
Internet-Draft EVPN First Hop Security July 2026
EVPN single-homing is analogous to the scenario described in
Section 3, where a host is connected to a single switch. If it
wasn't for EVPN host mobility, then the existing DHCP snoop
procedures could be leveraged as is. However, additional extensions
are needed for EVPN host mobility and EVPN multihoming will be
described in the following subsections.
The solution described here addresses both the multihoming and the
host mobility issues of FHS by distributing DHCP snoop bindings among
the EVPN peers. A new EVPN route is proposed DHCP Snoop Route (DSR),
is proposed to carry the DHCP snoop binding information and detailed
in Section 8.
4.1. DHCP Snoop Anchor PE
The PE attached to the host observes completion of DHCPREQUEST and
DHCPACK exchange between a DHCP Client (host) and a DHCP server, we
refer to this PE as the DHCP Snoop Anchor PE.
--------------------------------------------------------
| EVPN Network |
| |
| |
--------------------------------------------------------
| PE1 | | PE2 | | PE3 | | PE4 |
------- ------- ------- -------
| \\ /
| \\ /
| \\ /
| |
DHCP Server DHCP Client
Figure 2: Single-Homed and Multi-Homed hosts.
DHCP Snoop Anchor PE (e.g., PE2) originates the DSR. When a remote
BGP peer receives the DSR (e.g., PE4), it imports locally and updates
its DHCP snoop database. With this information, if the host moved to
a new PE (e.g., PE4), the new PE would already have the DSR update
from the old PE. As a result, the DHCP Snoop procedures running on
the new PE would successfully validate the host and immediately start
accepting that host's messages.
* For initial IP address assignment, both DHCPREQUEST and DHCPACK
need to be received by the same multihoming PE in order for that
PE to become DHCP Snoop Anchor PE and to originate DSR
Sajassi, et al. Expires 23 January 2027 [Page 9]
Internet-Draft EVPN First Hop Security July 2026
* For subsequent IP address renewal, only the DHCPACK need to be
received by one of the multihoming PEs in order for that PE to
become DHCP Snoop Anchor PE and to originate DSR
4.2. DHCP Message Synchronization
The synchronization procedures for DHCP snoop bindings avoids
synchronization of DHCPREQUEST and DHCPACK message among the PEs and
instead for the most part relies on a single PE to receive
DHCPREQUEST and DHCPACK message exchanges for initial IP address
assignment and only the DHCPACK for subsequent IP address renewal.
After the completion of such exchange, it will distribute the DHCP
snoop binding to the PEs participating in that EVPN Broadcast Domain.
The following sections describe the DHCP snoop procedures and
associated synchronization needed for EVPN All-Active multihoming and
host mobility for DHCP initial IP address allocation/lease and IP
address renewal when EVPN PEs participate in a bridged and IRB
service.
4.3. Bridged Service
When EVPN bridged service is used with DHCP snooping, it is assumed
that both DHCP clients and servers reside in the same subnet (same
bridge domain and EVI). If DHCP servers reside in a subnet different
than one of the DHCP clients, then EVPN IRB service along with DHCP
relay function ne to be deployed, which will be described in
Section 4.4.
Just as in the use-case of FHS application in traditional switches,
we assume that the PE interfaces on which DHCP information is
exchanged with the DHCP server is secure and the DHCP server itself
is not compromised.
4.3.1. DHCP IP Address Allocation and Lease for Bridged Service
In this section, we describe how a DHCP Snoop Anchor PE for DHCP
snoop is selected among PEs participating in an EVPN multihoming for
a given BD. Furthermore, we explain why we don't need
synchronization for individual DHCPREQUEST and DHCPACK messages among
these multihoming PEs for DHCP Snoop Anchor PE selection, but rather
we need to synchronize the final DHCP snoop state among the PEs
participating in that EVI after verification of DHCPREQUEST and
DHCPACK exchange and the DHCP Snoop Anchor PE selection. The
synchronization of the final DHCP snoop state is achieved when the
DHCP Snoop Anchor PE distributes this information is via DSR.
Sajassi, et al. Expires 23 January 2027 [Page 10]
Internet-Draft EVPN First Hop Security July 2026
When a DHCP client is multi-homed to two or more PEs on the same
Ethernet Segment operating in All-Active mode, DORA messages can
arrive at different PEs. However, only one PE in the multihoming
redundancy group receives both DHCPREQUEST and DHCPACK messages and
thus designates itself as DHCP Snoop Anchor PE. The behavior in the
case of Single-Active multihoming applies to other multihoming modes,
such as port-active [I-D.ietf-bess-evpn-mh-pa] or single-flow active
[I-D.ietf-bess-evpn-l2gw-proto] multihoming, DHCPREQUEST and DHCPACK
messages can only arrive at a single PE in the redundancy group,
which is the active PE for that ESI/EVI, hence and thus the DHCP
Snoop Anchor PE for DHCP snoop.
1. A DHCP client initiates a DORA exchange by sending a DHCPDISCOVER
broadcast message. Because of All-Active multihoming, this
broadcast message arrives at only one PE in the redundancy group
(e.g., PE2), which forwards it to all the other participating PEs
for that BD, including PE1, PE3 and PE4.
2. Each DHCP server for that subnet replies with a DHCPOFFER, while
DHCPOFFER may be broadcast or unicast in the following cases.
* Broadcast: If DHCPDISCOVER has 'ciaddr' and 'giaddr' set to
ZERO with Broadcast bit option.
* Unicast: If DHCPDISCOVER has 'ciaddr' and 'giaddr' set to ZERO
without the Broadcast bit option, then the client's hardware
address and 'yiaddr' address are used.
Since client MAC is not learned in the EVPN network before the
client obtains the IP address, even if DHCPOFFER is unicast, it
will be sent as an unknown unicast (from PE1's perspective).
Effectively, PE (e.g., PE1) attached to the DHCP server sends
this broadcast/unknown unicast message to all other PEs in that
BD/EVI and thus all the multihoming PEs for that DHCP client
(e.g., PE2 and PE3) receive the DHCPOFFER broadcast/unknown
unicast message and the DF PE (e.g., PE3) forwards the message to
the DHCP client.
3. The DHCP client responds with a DHCPREQUEST message of type
broadcast and gets hashed to PE2 again. PE2 creates incomplete
DHCP snoop binding entry and forwards this broadcast message to
all other PEs in that BD, including PE1. PE1 delivers this
broadcast message to the DHCP server.
4. DHCP server responds with DHCPACK. Since 'ciaddr' and 'giaddr'
are ZERO during initial setup, the client does not yet have the
'yiaddr' address. DHCPACK will be sent as broadcast PE (e.g.,
PE1) attached to the DHCP server sends this broadcast message to
Sajassi, et al. Expires 23 January 2027 [Page 11]
Internet-Draft EVPN First Hop Security July 2026
all other PEs in that BD/EVI and thus all the multihoming PEs for
that DHCP client (e.g., PE2 and PE3) receive the DHCPACK
broadcast message and the DF PE (e.g., PE3) forwards the message
to the DHCP client. PE2 received the DHCPREQUEST earlier on its
local attachment circuit, and with DHCPACK, it creates the
complete DHCP snoop binding, becomes the DHCP Snoop Anchor, and
originates the DSR.
As the above example illustrates, only one PE in the redundancy group
(e.g., PE2) receives DHCPREQUEST on its local attachment circuit and
DHCPACK messages. After verification of this exchange, it creates a
DHCP snoop state and designates itself as the DHCP Snoop Anchor for
that client. Next, the DHCP Snoop Anchor PE sends an EVPN DSR with
the snooped MAC/IP binding, lease time, and other pertinent
information to all PEs in that BD, including multihoming PEs in the
same redundancy group.
When multihoming PEs in the same redundancy group receive this DSR
message from the DHCP Snoop Anchor PE, they register the DHCP snoop
state for that host sitting behind that ESI. Therefore, from this
time forward, when ARP/ND message (or data traffic) is received from
that host, the host MAC address is learned and advertised in EVPN
MAC/IP RT-2 is in the EVPN network and the traffic is forwarded
accordingly.
4.3.2. DHCP IP Address Renewal for Bridged Service
A DHCP client sends DHCPREQUEST to renew the lease, which can be
unicast or broadcast. The client sets 'yiaddr' address as it already
knows the address. If DHCPREQUEST is a broadcast message then the
procedures defined in Section 4.3.1 will apply. If DHCPREQUEST is a
unicast, because of All-Active multihoming, DHCPREQUEST unicast
message arrives at only one of the PEs in the redundancy group (e.g.,
PE2), which forwards it to DHCP server.
DHCP server responds with DHCPACK. Since Client had set 'yiaddr'
address in DHCPREQUEST, DHCPACK will be a unicast and either PE2 or
PE3 will receive the DHCPACK.
* If PE2 receives the DHCPACK which is the DHCP Snoop Anchor PE
then, lease time will be updated and DSR update will be sent with
the new lease time. All other PEs including the multihomed PEs
will receive and update the lease time in the snoop entry that
they have created with the previous DSR update.
* If PE3 receives the DHCPACK which is not the DHCP Snoop Anchor PE
and determines that it has received the snoop entry from the
multihomed PE ( e.g., PE2), which is the DHCP Snoop Anchor then it
Sajassi, et al. Expires 23 January 2027 [Page 12]
Internet-Draft EVPN First Hop Security July 2026
claims itself as a DHCP Snoop Anchor and advertises DSR updates
with a MAC Mobility extended community attribute with a sequence
number one greater than the sequence number in the MAC Mobility
extended community attribute of the received DSR. Suppose the
snoop entry does not have the MAC Mobility extended community
attribute; the value of the sequence number in the received DSR is
assumed to be 0 for the purpose of this processing.
* PE2, which is the previous DHCP Snoop Anchor, receives DSR with a
higher sequence number from its ESI peer PE3, determines that ESI
peer has claimed the DHCP Snoop Anchor and withdraws the
previously advertised DSR. Note that when MAC/IP routes are
received from the same ESI, no mobility event is triggered
irrespective of the sequence number. But for MAC/IP routes, the
ES peer will not withdraw its own MAC/IP route, so the case for
the DSR is different indeed.
4.4. IRB Service
When EVPN IRB service is used with DHCP snooping, if both DHCP
clients and servers reside in the same subnet (same bridge domain and
EVI), then the procedures defined in Section 4.3 will apply. If DHCP
servers reside in a subnet different than one of the DHCP clients,
then EVPN IRB service and DHCP relay function MUST be deployed. The
solution described here addresses the multihoming and host mobility
issues by distributing DHCP snoop bindings among the EVPN peers.
4.4.1. DHCP IP Address Allocation and Lease for IRB Service
A DHCP client initiates a DORA exchange by sending a DHCPDISCOVER
broadcast message. Because of All-Active multihoming, this broadcast
message arrives at only one PE in the redundancy group (e.g., PE2),
which forwards it to the DHCP server defined in the relay config.
The source IP address used in the relay message will be a unique IP
configured on multihomed PEs such that the DHCP server response is
delivered to the PE, which initiates the DHCP relay message.
There could be multiple DHCP relays configured with different
servers. Each DHCP server can reply with a DHCPOFFER broadcast
message and sent by unicast to the PE, which originated the
DHCPDISCOVER relay message, which broadcasts on its local interfaces.
The DHCP client responds with a DHCPREQUEST message of type broadcast
and is load-balanced to PE2 again. PE2 creates an incomplete DHCP
snoop binding entry and forwards this broadcast message via the DHCP
relay.
Sajassi, et al. Expires 23 January 2027 [Page 13]
Internet-Draft EVPN First Hop Security July 2026
DHCP server responds with a DHCPACK message, which sent by unicast to
the PE (e.g., PE2), which originated the DHCPREQUEST relay message.
PE will broadcast this message on its local interfaces.
As the above example illustrates, only one PE in the redundancy group
(e.g., PE2) receives DHCPREQUEST on its local attachment circuit and
DHCPACK messages. After verification of this exchange, it creates a
DHCP snoop state and designates itself as the DHCP Snoop Anchor for
that client. Next, the DHCP Snoop Anchor PE sends an EVPN DSR with
the snooped MAC/IP binding, lease time, and other pertinent
information to all PEs in that BD, including multihoming PEs in the
same redundancy group.
When multihoming PEs in the same redundancy group receive this DSR
message from the DHCP Snoop Anchor PE, they register the DHCP snoop
state for that host sitting behind that ESI. Therefore, from this
time forward, when an ARP/ND message (or data traffic) is received
from that host, the host MAC address is learned and advertised in
EVPN MAC/IP RT-2 in the EVPN network, and the traffic is forwarded
accordingly.
4.4.2. DHCP IP Address Renewal for IRB Service
A DHCP client sends a DHCPREQUEST to renew the lease. Because of
All-Active multihoming, the DHCPREQUEST unicast message arrives at
only one of the PEs in the redundancy group, which forwards it to the
DHCP server defined in the relay config.
Suppose DHCPREQUEST arrives on PE2, which forwards it to the DHCP
server defined in the relay config. If PE2 is the DHCP Snoop Anchor
PE, then after receiving the DHCPACK, the DHCP snoop entry lease time
will be updated, and a DSR update will be sent with the new lease
time. All other PEs, including the multihomed PEs, will receive and
update the lease time in the snoop entry created with the previous
DSR update.
Suppose DHCPREQUEST arrives on PE3, which forwards it to the DHCP
server defined in the relay config. If PE3 is not the DHCP Snoop
Anchor PE, then after receiving the DHCPACK, it determines that it
has received the snoop entry from the multihomed PE, which is the
DHCP Snoop Anchor ( e.g., PE2), then it claims itself as a DHCP Snoop
Anchor.
* DHCP snoop entry lease time will be updated.
* DSR update will be sent with the new lease time with a MAC
Mobility extended community attribute with a sequence number one
greater than the sequence number in the MAC Mobility extended
Sajassi, et al. Expires 23 January 2027 [Page 14]
Internet-Draft EVPN First Hop Security July 2026
community attribute of the received DSR. Suppose the snoop entry
does not have the MAC Mobility extended community attribute; the
value of the sequence number in the received DSR is assumed to be
0 for the purpose of this processing.
* PE2, the previous DHCP Snoop Anchor, receives DSR with a higher
sequence number from its multihomed PE3, determines that
multihomed PE3 has claimed the DHCP Snoop Anchor, and withdraws
the previously advertised DSR. Note that no mobility event is
triggered when MAC/IP routes are received from the same ESI,
irrespective of the sequence number. But for MAC/IP routes, the
ES peer will not withdraw its own MAC/IP route, so the case for
the DSR is different indeed.
* All other PEs will receive and update the lease time in the snoop
entry that they have created with the previous DSR update.
4.5. DSR handling on non-ESI PEs
When other PEs ( e.g., PE4) in the same BD receive this DSR message
advertised by the DHCP Snoop Anchor PE, they also register and
synchronize the DHCP snoop state for that host with that of the DHCP
Snoop Anchor PE.
Contrary to EVPN MAC/IP Advertisement Routes (RT-2), EVPN DSR (RT-x)
does not need to use EVPN Ethernet AD per ES Route (RT-1) for route
resolution as described in section 9.2.2 of
[I-D.ietf-bess-rfc7432bis] because DSR is only used for DHCP snoop
state and not traffic forwarding. It is better to maintain the last
state of DHCP snoop for a given MAC/IP binding than to have no state
at all. Furthermore, there is no impact on traffic forwarding in the
case of DSR, whereas if route resolution based on RT-1 is not
performed for RT-2, traffic destined to that MAC can be blackholed
till it is learned again at the remote PEs.
5. DHCP Snoop Anchor Mobility
The host move will be detected via the data plane or GARP/RARP when
the host moves from DHCP Snoop Anchor PE to remote PE. Since DHCP
snoop entry was synced via the DSR from DHCP Snoop Anchor on remote
PE, the EVPN mobility procedures will be initiated as defined in
[RFC7432]. After completion of the mobility procedures, the DHCP
Snoop Anchor will be moved to the remote PE, where the host is moved.
A duplicate-wait-timer with a default value of 30 sec will be started
to identify the duplicate case. After the duplicate-wait-timer
expires, the DHCP Snoop Anchor will be moved if MAC/IP in the DSR is
learned locally. If not, then DHCP Snoop Anchor will not be moved.
Subsequent Host mobility will again start the duplicate-wait-timer.
Sajassi, et al. Expires 23 January 2027 [Page 15]
Internet-Draft EVPN First Hop Security July 2026
If DHCP Snoop Anchor is moved from a remote location to a local one,
the MAC Mobility extended community attribute defined [RFC7432] will
be used for the DSR. Every DHCP Snoop Anchor mobility event for a
given DSR will contain a sequence number that is set using the
following rules:
1. A PE advertising given DSR for the first time advertises it with
no MAC Mobility extended community attribute.
2. A PE detecting a locally attached DSR for which it had previously
received a DSR with a different Ethernet segment identifier
advertises the DSR tagged with a MAC Mobility extended community
attribute with a sequence number one greater than the sequence
number in the MAC Mobility extended community attribute of the
received DSR. In the case of the first mobility event for a
given DSR, where the received DSR does not carry a MAC Mobility
extended community attribute, the value of the sequence number in
the received DSR is assumed to be 0 for the purpose of this
processing.
3. A PE detecting a locally attached DSR for which it had previously
received a DSR with the same non-zero Ethernet segment identifier
advertises it with the following:
* No MAC Mobility extended community attribute if the received
DSR did not carry said attribute.
* a MAC Mobility extended community attribute with the sequence
number equal to the highest of the sequence number(s) in the
received DHCP Snoop Route (s) if the received route(s) is
(are) tagged with a MAC Mobility extended community attribute.
4. A PE detecting a locally attached DSR for which it had previously
received a DSR with the same zero Ethernet segment identifier
(single-homed scenarios) advertises it with a MAC Mobility
extended community attribute with the sequence number
appropriately set. In the case of single-homed scenarios, there
is no need for an ESI comparison. ESI comparison is made for
multihoming to prevent false detection of DSR moves among the PEs
attached to the same multihomed site.
A PE receiving a DSR for a MAC/IP address with a different Ethernet
segment identifier and a higher sequence number than that which it
had previously advertised withdraws its DSR. If two (or more) PEs
advertise the same DSR with the same sequence number but different
Ethernet segment identifiers, a PE that receives these routes selects
the route advertised by the PE with the lowest IP address, which is
the best route. If the PE is the originator of the DSR and it
Sajassi, et al. Expires 23 January 2027 [Page 16]
Internet-Draft EVPN First Hop Security July 2026
receives the same DSR with the same sequence number that it
generated, it will compare its IP address with the IP address of the
remote PE and will select the lowest IP. If its route is not the
best one, it will withdraw the route.
Previous DHCP Snoop Anchor PE receiving DSR from remote check whether
the MAC/IP is learned remotely; if so, it will withdraw the local DSR
and use the remote DSR. If MAC/IP is learned locally, then it will
increment the sequence number by ONE, than the received sequence
number.
6. Host Mobility and Age-Out
When using the DSR, the baseline host mobility procedures in EVPN are
not affected. When the host moves from one PE to another and both
PEs have the same BD, the new PE would already have the remote DHCP
Snoop Entry. As a result, it would accept the incoming ARP/ND
messages. Once it learns the new host, the new PE can send a new
MAC/IP update.
When the host ages out, the PE would withdraw the EVPN MAC/IP
advertisement route without without withdrawing the DSR. If the DHCP
Lease expiration timer is running on the PE, then the PE does not
send a withdrawal of the DSR. Once the Lease expires, the PE can
withdraw the DSR as well.
7. Race Conditions
7.1. Inter-ES Mobility
A race-condition can happen when the host moves from one PE device
(say PE1) to another PE device (say PE2). Let us say that as soon as
DHCPREQUEST is validated on PE1 and PE1 advertises the DSR to other
PE devices. The host moves from PE1 to PE2. Upon moving, the host
generates a GARP (Gratuitous ARP) message. The GARP message MAY
arrive sooner on PE2 than the DSR. In other words, PE2 receives the
GARP before it has populated its DHCP binding and thus discards GARP.
We can address the above race-condition by storing an ARP entry
associated with the GARP message and a flag indicating that we should
keep the entry for T seconds. If DSR arrives within T, then the flag
is removed and ARP entry is made permanent. Otherwise, we delete the
ARP entry after the expiration of T seconds. In other words, the ARP
entry is created, but it stays inactive until the DSR arrives and
activates the ARP entry.
Sajassi, et al. Expires 23 January 2027 [Page 17]
Internet-Draft EVPN First Hop Security July 2026
7.2. Intra-ES Synchronization
A similar race-condition can occur when multiple PEs are connected to
the same Ethernet-Segment. Let us say, that upon successfully
getting the DHCP handshake done, the host generates an ARP message.
The ARP message MAY reach PE2, which is different from PE1, which has
the Snoop DB binding. However, they are in the same Ethernet
Segment. In other words, PE2 receives the GARP before it has
populated its DHCP binding and thus discards the ARP.
Once again, we can address the above race-condition by storing an ARP
entry associated with the ARP message and a flag indicating that it
will be kept for T seconds. If DSR arrives within T, the flag is
removed and ARP entry is made permanent. Otherwise, the ARP entry is
deleted after the expiration of T seconds.
8. BGP EVPN DSR
The BGP EVPN NLRI as defined in [RFC7432] is shown below:
+-----------------------------------+
| Route Type (1 octet) |
+-----------------------------------+
| Length (1 octet) |
+-----------------------------------+
| Route Type specific (variable) |
+-----------------------------------+
Figure 3: BGP EVPN NLRI
We propose a new EVPN route type called DHCP Snoop Route with the
following format:
Sajassi, et al. Expires 23 January 2027 [Page 18]
Internet-Draft EVPN First Hop Security July 2026
+---------------------------------------+
| RD (8 octets) |
+---------------------------------------+
|Ethernet Segment Identifier (10 octets)|
+---------------------------------------+
| Ethernet Tag ID (4 octets) |
+---------------------------------------+
| MAC Address Length (1 octet) |
+---------------------------------------+
| MAC Address (6 octets) |
+---------------------------------------+
| IP Address Length (1 octet) |
+---------------------------------------+
| IP Address (4 or 16 octets) |
+---------------------------------------+
| Create Lease Time in sec (8 octets) |
+---------------------------------------+
| Lease Time in sec (4 octets) |
+---------------------------------------+
Figure 4: EVPN DSR
* The Route Distinguisher (RD) and Ethernet Tag ID MUST be used as
defined in [RFC7432] and [RFC8365]. In particular, the RD is
unique per MAC-VRF.
* Ethernet Segment Identifier (ESI) is a unique non-zero identifier
that identifies an Ethernet segment. The ESI format is described
in [RFC7432].
* The MAC Address and the IP Address fields are the MAC address and
IP address of the host respectively. The MAC Address length (in
bits) field specifies the host's MAC address length. The IP
address Length (in bits) field specifies the host's IP address
length.
* Create-Time is the value when DHCP entry is created, it also gets
updated when DHCP Lease renewal happens. The value is calculated
from epoch time -1st January 1970 UTC I,e how many seconds elapsed
from epoch.
* Lease-Time is the value of lease time remaining for the DHCP snoop
entry in seconds.
Sajassi, et al. Expires 23 January 2027 [Page 19]
Internet-Draft EVPN First Hop Security July 2026
* For the purpose of BGP route key processing, only the Ethernet Tag
ID, MAC Address Length, MAC Address, IP Address Length, and IP
Address fields are considered to be part of the prefix in the
NLRI.
* The BGP advertisement for the DSR MUST also carry the Route Target
(RT) associated with the BD.
8.1. Create and Lease Time Handling
DHCP Snoop Anchor PE originates the DSR when the DORA exchange is
complete. DHCP snoop database entry will maintain the create time
and lease time. When DHCP lease renewal is complete, the create time
and lease time are updated. The Create time will be in seconds. For
example, the Create time on January 1, 2022 12:00:01 A.M will be
represented in seconds a 1640995201.
All EVPN peers will be expected to synchronize the timestamp using
NTP such that Create time will be interpreted correctly.
The PE router will calculate the lease time as follows.
Lease Time = Received Lease time - (Current time - Create time)
There are no lease time calculations in transit BGP EVPN peers like
route reflectors of ASBRs.
9. Security Considerations
Security considerations discussed in [RFC7432] and [RFC8365] apply to
this document as well.
10. IANA Considerations
This document defines a new EVPN route type called DHCP Snoop Route
and request the following registration in the EVPN Route Type
registry:
Value : 12
Description: DHCP Snoop Route
11. References
11.1. Normative References
Sajassi, et al. Expires 23 January 2027 [Page 20]
Internet-Draft EVPN First Hop Security July 2026
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol",
RFC 2131, DOI 10.17487/RFC2131, March 1997,
<https://www.rfc-editor.org/info/rfc2131>.
[RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A.,
Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based
Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February
2015, <https://www.rfc-editor.org/info/rfc7432>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
11.2. Informative References
[I-D.ietf-bess-evpn-l2gw-proto]
Burdet, L. A., Brissette, P., Sajassi, A., Maheshwari, P.,
and I. Bhatt, "EVPN Multi-Homing Mechanism for Layer-2
Gateway Protocols", Work in Progress, Internet-Draft,
draft-ietf-bess-evpn-l2gw-proto-06, 17 October 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-bess-
evpn-l2gw-proto-06>.
[I-D.ietf-bess-evpn-mh-pa]
Brissette, P., Burdet, L. A., Wen, B., Leyton, E., and J.
Rabadan, "EVPN Port-Active Redundancy Mode", Work in
Progress, Internet-Draft, draft-ietf-bess-evpn-mh-pa-13, 5
December 2024, <https://datatracker.ietf.org/doc/html/
draft-ietf-bess-evpn-mh-pa-13>.
[I-D.ietf-bess-rfc7432bis]
Sajassi, A., Burdet, L. A., Drake, J., and J. Rabadan,
"BGP MPLS-Based Ethernet VPN", Work in Progress, Internet-
Draft, draft-ietf-bess-rfc7432bis-14, 2 March 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-bess-
rfc7432bis-14>.
[RFC7513] Bi, J., Wu, J., Yao, G., and F. Baker, "Source Address
Validation Improvement (SAVI) Solution for DHCP",
RFC 7513, DOI 10.17487/RFC7513, May 2015,
<https://www.rfc-editor.org/info/rfc7513>.
Sajassi, et al. Expires 23 January 2027 [Page 21]
Internet-Draft EVPN First Hop Security July 2026
[RFC8365] Sajassi, A., Ed., Drake, J., Ed., Bitar, N., Shekhar, R.,
Uttaro, J., and W. Henderickx, "A Network Virtualization
Overlay Solution Using Ethernet VPN (EVPN)", RFC 8365,
DOI 10.17487/RFC8365, March 2018,
<https://www.rfc-editor.org/info/rfc8365>.
[RFC9135] Sajassi, A., Salam, S., Thoria, S., Drake, J., and J.
Rabadan, "Integrated Routing and Bridging in Ethernet VPN
(EVPN)", RFC 9135, DOI 10.17487/RFC9135, October 2021,
<https://www.rfc-editor.org/info/rfc9135>.
Contributors
In addition to the authors listed on the front page, the following
coauthors have also contributed to this document:
Samir Thoria
Authors' Addresses
Ali Sajassi
Cisco
170 W. Tasman Drive
San Jose, CA 95134
United States of America
Email: sajassi@cisco.com
Lukas Krattiger
Cisco
170 W. Tasman Drive
San Jose, CA 95134
United States of America
Email: lkrattig@cisco.com
Krishnaswamy Ananthamurthy
Cisco
170 W. Tasman Drive
San Jose, CA 95134
United States of America
Email: kriswamy@cisco.com
Sajassi, et al. Expires 23 January 2027 [Page 22]
Internet-Draft EVPN First Hop Security July 2026
Jorge Rabadan
Nokia
520 Almanor Avenue
Sunnyvale, CA 94085
United States of America
Email: jorge.rabadan@nokia.com
Wen Lin
Juniper Networks, Inc.
10 Technology Park Drive
Westford, Massachusetts 01886
United States of America
Email: wlin@juniper.net
Sajassi, et al. Expires 23 January 2027 [Page 23]