RFC 9047

Propagation of ARP/ND Flags in an Ethernet Virtual Private Network (EVPN)

📅 published June 2021, from ietf

Abstract ✨

Okay bestie, so this RFC 🦋 is basically the spec for an Extended Community that rides along with an EVPN MAC/IP Advertisement route. Its whole job is carrying ARP/ND info so an EVPN PE running a proxy-ARP/ND function (in broadcast domains or on IRB interfaces) can answer ARP Requests and Neighbor Solicitation messages with the correct answer. Main character energy 👑

Status of This Memo 📜

This is an Internet Standards Track document, so it's the real deal 💅

It's a product of the Internet Engineering Task Force (IETF) 🌸 and it represents the consensus of the IETF community. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). If you want more on Internet Standards, check out Section 2 of RFC 7841.

For the current status, any errata, and how to send feedback, go to https://www.rfc-editor.org/info/rfc9047 🔗

Copyright (c) 2021 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) as they stand on the publication date. Read those carefully, because they spell out your rights and restrictions for this document. Code Components pulled out of this document have to include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as described in the Simplified BSD License 🙈

Table of Contents 🗂️

1.  Introduction
  1.1.  Terminology and Conventions
2.  The EVPN ARP/ND Extended Community
3.  Use of the EVPN ARP/ND Extended Community
  3.1.  Transmission of the EVPN ARP/ND Extended Community
  3.2.  Reception of the EVPN ARP/ND Extended Community
4.  Security Considerations
5.  IANA Considerations
6.  References
  6.1.  Normative References
  6.2.  Informative References
Acknowledgments
Authors' Addresses

1. Introduction 🌷

Okay so an EVPN MAC/IP Advertisement route can optionally carry IPv4 or IPv6 addresses tied to a MAC address. Remote PE routers can use that info to fill up their ARP or ND tables on IRB interfaces, or their proxy-ARP/ND tables in BDs. Then the PEs can reply locally (acting as an ARP/ND proxy, as per [RFC7432]) to IPv4 ARP Requests and IPv6 Neighbor Solicitation messages, which cuts down on or even stops the flooding that address resolution normally causes. It's giving efficiency ✨

BUT, and this is a big but 😭, the info in the EVPN MAC/IP Advertisement route might not be enough for the remote PE to answer local ARP or ND requests. Say a PE learns an IPv6 address and MAC address combo as an ND entry through EVPN (we call that IPv6->MAC). The PE wouldn't know if that pair belongs to a router or a host, or if the address is an anycast address, because EVPN MAC/IP Advertisement routes don't carry that info. Not it 💀

So this document defines an Extended Community that gets advertised with an EVPN MAC/IP Advertisement route and carries the ARP/ND resolution info. That way an EVPN PE with a proxy-ARP/ND function can reply to ARP Requests or Neighbor Solicitations with the right answer. Specifically, the flags defined in [RFC4861] can now ride along with a MAC/IP Advertisement route, so an egress EVPN PE can send Neighbor Advertisement (NA) messages with the correct flag info 🦋

The flags live in the EVPN Address Resolution Protocol and Neighbor Discovery (ARP/ND) Extended Community. The following sections explain how it all works 💖

1.1. Terminology and Conventions 📚

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. (Only the all-caps ones count, so the lowercase ones are just regular words, bestie 🫶)

Here's the glossary:

  • EVPN: Ethernet Virtual Private Networks, as in [RFC7432]
  • BD: Broadcast Domain, also described in [RFC7432]
  • ARP: Address Resolution Protocol
  • ND: Neighbor Discovery protocol, specified in [RFC4861]
  • PE: Provider Edge router
  • CE: Customer Edge router
  • IRB: Integrated Routing and Bridging interface
  • Proxy-ARP/ND: A function on the EVPN PEs where received ARP Requests or NS messages get answered locally by the PE, without flooding the requests to remote PEs in the BD. To reply to ARP Requests or NS messages, the PE does a lookup on an ARP/ND table, which is a collection of IP->MAC entries the PE has learned 🧚
  • IP->MAC: An IP address and MAC address combo that represents a given host and gets added to an ARP table or ND table. This document uses IP->MAC generically for IPv4 and IPv6 addresses. When something is specific to IPv4, the document says IPv4->MAC, and IPv6->MAC is used when something only applies to IPv6 entries 🌈

Familiarity with the terminology in [RFC4861] and [RFC7432] is expected, so go brush up if you need to 💅

2. The EVPN ARP/ND Extended Community 💎

This document defines a transitive EVPN Extended Community with a Type field value of 0x06 and a Sub-Type of 0x08, as allocated by IANA ✨ It gets advertised along with EVPN MAC/IP Advertisement routes that carry an IPv4 or IPv6 address.

Here's the layout 🎀

  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Type=0x06     | Sub-Type=0x08 |Flags (1 octet)| Reserved=0    |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                       Reserved=0                              |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

And the Flags field 🚩

  0 1 2 3 4 5 6 7
 +-+-+-+-+-+-+-+-+
 |       |I| |O|R|
 +-+-+-+-+-+-+-+-+

The following flags are defined in the Flags field, which is the third octet of the Extended Community:

  • R: Router flag (corresponds to Bit 23 of the Extended Community)

Bit 7 of the Flags field is the "Router flag" 👑 When it's set, the R flag says the IPv6->MAC pair advertised in the MAC/IP Advertisement route (along with the Extended Community) belongs to an IPv6 router. If the R flag is zero, the IPv6->MAC pair belongs to a host. The receiving PE that implements the ND function uses this info in Neighbor Advertisement messages for the associated IPv6 address. This flag has no meaning for ARP IPv4->MAC entries, so it MUST be ignored when the Extended Community is received with an EVPN MAC/IP Advertisement route for an IPv4->MAC pair. (Ignore it, no cap, it's not your problem for IPv4 🙈)

  • O: Override flag (corresponds to Bit 22 of the Extended Community)

Bit 6 of the Flags field is the "Override flag" 🔥 An egress PE normally advertises IPv6->MAC pairs with the O flag set. The PE only sends an IPv6->MAC pair with the O flag = 0 when IPv6 "anycast" is enabled in the BD or interface. The ingress PE installs the ND entry with the received O flag and always uses that O flag value when replying to a Neighbor Solicitation for the IPv6 address. Just like the Router flag, the Override flag has no meaning for ARP IPv4->MAC entries, so it MUST be ignored when the Extended Community is received with an EVPN MAC/IP Advertisement route for an IPv4->MAC pair. Same energy as R, bestie 💜

  • I: Immutable ARP/ND Binding flag (corresponds to Bit 20 of the Extended Community)

Bit 4 of the Flags field is the "Immutable ARP/ND Binding flag" 🧚 When it's set, the egress PE is saying the IP->MAC pair sent in an EVPN MAC/IP Advertisement route (along with the Extended Community) is a configured ARP/ND entry. In that case, the IP address in the EVPN MAC/IP Advertisement route can only be bound to the MAC address specified in that same route. It can't be bound to any other MAC addresses received in a different route that doesn't have the I flag set. Locked in 🔒

Bits 0-3 and 5 aren't assigned by this document. They MUST be set to zero and ignored on receipt. (Zero them, ignore them, move on ✨)

The reserved fields are set to 0 and ignored by the receiver 🌸

3. Use of the EVPN ARP/ND Extended Community 🌟

This section describes the procedures for advertising and processing the EVPN ARP/ND Extended Community. Throughout these procedures, a "PE" has to be read as a "PE that supports the proxy-ARP/ND (introduced by [RFC7432]) and implements the propagation of the ARP/ND flags that this document specifies" 🎀

3.1. Transmission of the EVPN ARP/ND Extended Community 📤

So when an IP->MAC entry is not learned via EVPN, a PE may still learn IP->MAC pairs in a few ways. It can pick them up in the management plane (which creates static entries in the ARP/ND or proxy-ARP/ND table), or by snooping ARP or NA messages coming from the CE (which creates dynamic entries). Those static and dynamic IP->MAC entries get advertised in EVPN MAC/IP Advertisement routes that use the EVPN ARP/ND Extended Community, like this 🦋

  • Advertised MAC/IP Advertisement routes for IPv6->MAC entries MUST include one (and only one) ARP/ND Extended Community with the R and O flag values associated with the entry. Those flag values are either learned dynamically (from NA messages) or configured, in the case of static entries.
  • MAC/IP Advertisement routes for IPv4->MAC entries MAY include one ARP/ND Extended Community. If the EVPN ARP/ND Extended Community is advertised along with an EVPN IPv4/MAC Advertisement route, the R and O flags SHOULD be set to zero. (Totally optional for IPv4, but if you do send it, keep those R and O flags at zero 💅)
  • If an IP->MAC pair is static (it has been configured), the corresponding MAC/IP Advertisement route MUST be sent along with an ARP/ND Extended Community with the I flag set 🔒
  • This Extended Community doesn't change the procedures described in [RFC7432]. Specifically, the procedures for advertising the MAC Mobility Extended Community along with the MAC/IP Advertisement route are not changed. Nothing about the old playbook gets rewritten, periodt 💜

Part 1 wraps up here, bestie 🧚 Next up in part 2 we've got the reception side, then Security, IANA, References and the rest of the crew ✨

3.2. Reception of the EVPN ARP/ND Extended Community ✨

okay so, on top of everything in [RFC7432] 💅, a PE that gets a MAC/IP Advertisement route handles the EVPN ARP/ND Extended Community like this:

  • One at a time, bestie 🎀: Only one EVPN ARP/ND Extended Community is expected along with an EVPN MAC/IP Advertisement route. If more than one shows up, the PE MUST consider only the first one on the list for processing purposes and MUST NOT propagate the rest of the ARP/ND Extended Communities.
  • The flags depend on having an IP 🧚: The R, O, and I flags MUST be ignored if they are advertised along with an EVPN MAC/IP Advertisement route that does not contain an IP (IPv4 or IPv6) address. Otherwise, they are processed as follows.
    • R and O flag processing 🌸:
      • If the EVPN MAC/IP Advertisement route contains an IPv6 address and the EVPN ARP/ND Extended Community, the PE MUST add the R and O flag values to the ND entry in the ND or proxy-ND table and propagate the value of the R and O flags from the ARP/ND Extended Community to the Neighbor Advertisements when replying to a solicitation for the IPv6 address.
      • If no EVPN ARP/ND Extended Community is received along with the route, the PE will add the default R and O flags to the entry. The default R flag SHOULD be an administrative choice. The default O flag SHOULD be 1.
      • A PE MUST ignore the received R and O flags for an EVPN MAC/IP Advertisement route that contains an IPv4->MAC pair.
    • I flag processing 🔥:
      • A PE receiving an EVPN MAC/IP Advertisement route containing an IP->MAC and the I flag set SHOULD install the IP->MAC entry in the ARP/ND or proxy-ARP/ND table as an "immutable binding". This immutable binding entry will override an existing non-immutable binding for the same IP->MAC. The absence of the EVPN ARP/ND Extended Community in a MAC/IP Advertisement route indicates that the IP->MAC entry is not an "immutable binding".
      • Receiving multiple EVPN MAC/IP Advertisement routes with the I flag set to 1 for the same IP but a different MAC address is considered a misconfiguration or a transient error condition. If this happens in the network, a PE receiving multiple routes (with the I flag set to 1 for the same IP and a different MAC address) SHOULD update the IP->MAC entry with the latest received information. Note that if a configured IP1->MAC1 changes to point to a new MAC address, i.e., IP1->MAC2, the EVPN MAC/IP Advertisement route for IP1->MAC1 will be withdrawn before the EVPN MAC/IP Advertisement route for IP1->MAC2 is advertised.
      • A PE originating an EVPN MAC/IP Advertisement route for IP1->MAC1 with the I flag set to 1 MAY also originate the route with the "Sticky/static flag" set (in the MAC Mobility Extended Community). In such a case, the IP1->MAC1 binding is not only immutable but it cannot move as well. Even so, if an update for the same immutable and static IP1->MAC1 is received from a different PE, one of the two routes will be selected. This is analogous to the case described in Section 15.2 of [RFC7432] when two MAC/IP routes with the static flag set are received, and the PE likewise MUST alert the operator of such a situation.

In a situation where a host (with an IP->MAC that is configured as immutable binding in the attached PE) is allowed to move between PEs (that is, the associated MAC is non-static), PEs can receive multiple MAC/IP Advertisement routes for the same IP->MAC. In such situations, MAC mobility procedures as in [RFC7432] dictate the reachability of the MAC.

Here's an example of the I flag in action 🦋. Picture PE1, PE2, and PE3, all attached to the same BD. PE1 originates an EVPN MAC/IP Advertisement route for IP1->MAC1 with the I flag set to 1 later on, and PE2 also originates an EVPN MAC/IP Advertisement route for IP1->MAC1 with a higher sequence number and the I flag set to 1. Then all the EVPN PEs attached to the same BD SHOULD retain their IP1->MAC1 ARP/ND binding but update MAC1's forwarding destination to PE2. Now, for some reason, if PE3 originates an EVPN MAC/IP Advertisement route for IP1->MAC2 with the I flag set to 0 (even with a higher sequence number), then the EVPN PEs in the BD will not update their IP1->MAC1 ARP/ND bindings since IP1 is bound to MAC1 (MAC2 SHOULD still be programmed in the Layer 2 BDs). This is considered a misconfiguration in PE3. 🙈

When the I flag is set to 1, a given IP is assumed to be always bound to the same MAC address; therefore, the mobility procedures described in [EXTENDED-MOBILITY] for "Host IP move to a new MAC" will not apply.

4. Security Considerations 🔒

The same security considerations described in [RFC7432] apply to this document. In general, it is worth noting that the use of proxy-ARP/ND in EVPN BDs may add some security risks. Attackers can make use of ARP/ND messages to create state in all the PEs attached to the same BD as the attacker and exhaust resources in those PEs. Therefore, additional security mechanisms may be needed. Some examples of such additional security mechanisms are limiting the number of proxy-ARP/ND entries per BD and/or per port or closely monitoring the rate at which hosts create dynamic proxy-ARP/ND entries.

⚠️ Okay, this part is serious, bestie. Attackers can use ARP/ND messages to create state in every PE in the same BD and exhaust their resources. So extra security mechanisms may be needed. 😭

In addition, this document adds pieces of information that impact the way ARP/ND entries are installed in ARP/ND and/or proxy-ARP/ND tables and, therefore, impacts the resolution protocols for IPv4 and IPv6 addresses. For instance, if a given IPv6->MAC binding is configured with the wrong R or O flags (intentionally or not) on a given PE, the rest of the PEs attached to the same BD will install the wrong information for the IPv6->MAC. This will cause all the PEs in the BD to reply to Neighbor Solicitations for the IPv6 with NA messages containing the wrong R and O flags. For example, as specified in [RFC4861], the receiver of an NA message with O not set will not update its existing cache entry for the IP->MAC; hence, the communication between the owner of the IP address and the receiver of the NA message with the wrong O flag will fail. Similarly, the receiver of an NA message with the wrong R flag may update its Default Router List by incorrectly adding or removing an entry, which could, for example, lead to sending traffic to a node that is not a router, causing the traffic to be dropped.

The I flag, or Immutable ARP/ND Binding flag, is a useful security tool 🛡️, allowing an operator to ensure a given IP address is always bound to the same MAC and that information is distributed to all the PEs attached to the same BD. ARP/ND spoofing attacks, in which a malicious host injects Gratuitous ARPs or unsolicited NAs for that IP address with a different MAC address, will not succeed in programming the ARP/ND and proxy-ARP/ND tables and therefore the spoofer will not receive the traffic. Iconic behaviour from the I flag, no cap 💅.

5. IANA Considerations 📋

IANA has changed the name for Sub-Type Value 0x08 in the "EVPN Extended Community Sub-Types" registry [IANA-BGP-EXT-COMM] to the following:

     +================+===========================+===========+
     | Sub-Type Value | Name                      | Reference |
     +================+===========================+===========+
     | 0x08           | ARP/ND Extended Community | RFC 9047  |
     +----------------+---------------------------+-----------+

       Table 1: Updated Value in the "EVPN Extended Community
                        Sub-Types" Registry

IANA has created the "ARP/ND Extended Community Flags" registry, where the following initial allocations have been made:

  +===============+===================================+===========+
  | Flag Position | Name                              | Reference |
  +===============+===================================+===========+
  | 0-3           | Unassigned                        |           |
  +---------------+-----------------------------------+-----------+
  | 4             | Immutable ARP/ND Binding Flag (I) | RFC 9047  |
  +---------------+-----------------------------------+-----------+
  | 5             | Unassigned                        |           |
  +---------------+-----------------------------------+-----------+
  | 6             | Override Flag (O)                 | RFC 9047  |
  +---------------+-----------------------------------+-----------+
  | 7             | Router Flag (R)                   | RFC 9047  |
  +---------------+-----------------------------------+-----------+

      Table 2: Initial Values of the "ARP/ND Extended Community
                           Flags" Registry

The registration policy for this registry is Standards Action [RFC8126]. This registry is located in the "Border Gateway Protocol (BGP) Extended Communities" registry [IANA-BGP-EXT-COMM].

Note that the flag position 5 is left unassigned and not used in this specification since it was previously requested by [EVPN-IP-MAC-PROXY]. 🌈

6. References 📚

6.1. Normative References

[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>.

[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, DOI 10.17487/RFC4861, September 2007, <https://www.rfc-editor.org/info/rfc4861>.

[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>.

6.2. Informative References

[EVPN-IP-MAC-PROXY] Bickhart, R., Lin, W., Drake, J., Rabadan, J., and A. Lo, "Proxy IP->MAC Advertisement in EVPNs", Work in Progress, Internet-Draft, draft-rbickhart-evpn-ip-mac-proxy-adv-01, 24 January 2020, <https://tools.ietf.org/html/draft-rbickhart-evpn-ip-mac-proxy-adv-01>.

[EXTENDED-MOBILITY] Malhotra, N., Ed., Sajassi, A., Pattekar, A., Lingala, A., Rabadan, J., and J. Drake, "Extended Mobility Procedures for EVPN-IRB", Work in Progress, Internet-Draft, draft-ietf-bess-evpn-irb-extended-mobility-05, 15 March 2021, <https://tools.ietf.org/html/draft-ietf-bess-evpn-irb-extended-mobility-05>.

[IANA-BGP-EXT-COMM] IANA, "Border Gateway Protocol (BGP) Extended Communities", <https://www.iana.org/assignments/bgp-extended-communities>.

[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.

Acknowledgments 🫶

The authors would like to thank Ali Sajassi for his feedback. 💜

Authors' Addresses ✨

Okay bestie, the cast list! 🎀 These are the Nokia and Juniper folks who wrote this thing, and Jorge is the editor, so he's basically the director 🎬. Here's where to find them:

Jorge Rabadan (editor) 💖

Jorge Rabadan (editor)
Nokia
777 Middlefield Road
Mountain View, CA 94043
United States of America

Email: jorge.rabadan@nokia.com

Senthil Sathappan 🦋

Senthil Sathappan
Nokia
701 E. Middlefield Road
Mountain View, CA 94043
United States of America

Email: senthil.sathappan@nokia.com

Kiran Nagaraj 🌸

Kiran Nagaraj
Nokia
701 E. Middlefield Road
Mountain View, CA 94043
United States of America

Email: kiran.nagaraj@nokia.com

Wen Lin 🧚 (from Juniper Networks, no mailing address listed, just the email!)

Wen Lin
Juniper Networks

Email: wlin@juniper.net

Iconic squad, no cap 👑🫶

📦 where this page comes from