Skip to main content

Operational Aspects of Proxy-ARP/ND in EVPN Networks
draft-ietf-bess-evpn-proxy-arp-nd-09

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft that was ultimately published as RFC 9161.
Authors Jorge Rabadan , Senthil Sathappan , Kiran Nagaraj , Greg Hankins , Thomas King
Last updated 2020-12-15 (Latest revision 2020-10-12)
Replaces draft-snr-bess-evpn-proxy-arp-nd
RFC stream Internet Engineering Task Force (IETF)
Formats
Reviews
Additional resources Mailing list discussion
Stream WG state Submitted to IESG for Publication
Document shepherd Matthew Bocci
Shepherd write-up Show Last changed 2019-07-09
IESG IESG state Became RFC 9161 (Proposed Standard)
Consensus boilerplate Yes
Telechat date (None)
Responsible AD Martin Vigoureux
Send notices to Matthew Bocci <matthew.bocci@nokia.com>
IANA IANA review state IANA OK - No Actions Needed
draft-ietf-bess-evpn-proxy-arp-nd-09
"All Static Provisioning with Proxy-ARP/ND"
   is the predominant scenario for IXPs.

   In addition to the "All Static Provisioning" behavior, in IXP
   networks it is recommended to configure the Reply Sub-Function to
   'discard' ARP-Requests/NS messages with unrecognized options.

   At IXPs, customers usually follow a certain operational life-cycle.
   For each step of the operational life-cycle specific operational
   procedures are executed.

   The following describes the operational procedures that are needed to
   guarantee port security throughout the life-cycle of a customer with
   focus on EVPN features:

   1.  A new customer is connected the first time to the IXP:

       Before the connection between the customer router and the IXP-LAN
       is activated, the MAC of the router is white-listed on the IXP's
       switch port.  All other MAC addresses are blocked.  Pre-defined
       IPv4 and IPv6 addresses of the IXP's peering network space are
       configured at the customer router.  The IP->MAC static entries
       (IPv4 and IPv6) are configured in the management system of the
       IXP for the customer's port in order to support Proxy-ARP/ND.

       In case a customer uses multiple ports aggregated to a single
       logical port (LAG) some vendors randomly select the MAC address
       of the LAG from the different MAC addresses assigned to the
       ports.  In this case the static entry will be used associated to
       a list of allowed MACs.

   2.  Replacement of customer router:

       If a customer router is about to be replaced, the new MAC
       address(es) must be installed in the management system besides
       the MAC address(es) of the currently connected router.  This
       allows the customer to replace the router without any active
       involvement of the IXP operator.  For this, static entries are
       also used.  After the replacement takes place, the MAC
       address(es) of the replaced router can be removed.

Rabadan, et al.          Expires April 12, 2021                [Page 19]
Internet-Draft              EVPN Proxy-ARP/ND               October 2020

   3.  Decommissioning a customer router

       If a customer router is decommissioned, the router is
       disconnected from the IXP PE.  Right after that, the MAC
       address(es) of the router and IP->MAC bindings can be removed
       from the management system.

6.6.  Deployment Scenarios in DCs

   DCs normally have different requirements than IXPs in terms of Proxy-
   ARP/ND.  Some differences are listed below:

   a.  The required mobility in virtualized DCs makes the "Dynamic
       Learning" or "Hybrid Dynamic and Static Provisioning" models more
       appropriate than the "All Static Provisioning" model.

   b.  IPv6 'anycast' may be required in DCs, while it is not a
       requirement in IXP networks.  Therefore if the DC needs IPv6
       'anycast' it will be explicitly enabled in the Proxy-ND function,
       hence the Proxy-ND sub-functions modified accordingly.  For
       instance, if IPv6 'anycast' is enabled in the Proxy-ND function,
       Duplicate IP Detection must be disabled.

   c.  DCs may require special options on ARP/ND as opposed to the
       Address Resolution function, which is the only one typically
       required in IXPs.  Based on that, the Reply Sub-function may be
       modified to forward or discard unknown options.

7.  Security Considerations

   The procedures in this document reduce the amount of ARP/ND message
   flooding, which in itself provides a protection to "slow path"
   software processors of routers and Tenant Systems in large BDs.  The
   ARP/ND requests that are replied by the Proxy-ARP/ND function (hence
   not flooded) are normally targeted to existing hosts in the BD.  ARP/
   ND requests targeted to absent hosts are still normally flooded,
   however the suppression of Unknown ARP-Requests and NS messages
   described in Section 4.5. can provide an additional level of security
   against ARP-Requests/NS messages issued to non-existing hosts.

   The solution also provides protection against Denial Of Service
   attacks that use ARP/ND-spoofing as a first step.  The Duplicate IP
   Detection and the use of an AS-MAC as explained in Section 4.6 will
   definitely protect the BD against ARP/ND spoofing.

   When EVPN and its associated Proxy-ARP/ND function are used in IXP
   networks, they provide ARP/ND security and mitigation.  IXPs MUST
   still employ additional security mechanisms that protect the peering

Rabadan, et al.          Expires April 12, 2021                [Page 20]
Internet-Draft              EVPN Proxy-ARP/ND               October 2020

   network and SHOULD follow established BCPs such as the ones described
   in [Euro-IX-BCP].

   For example, IXPs should disable all unneeded control protocols, and
   block unwanted protocols from CEs so that only IPv4, ARP and IPv6
   Ethertypes are permitted on the peering network.  In addition, port
   security features and ACLs can provide an additional level of
   security.

8.  IANA Considerations

   No IANA considerations.

9.  Acknowledgments

   The authors want to thank Ranganathan Boovaraghavan, Sriram
   Venkateswaran, Manish Krishnan, Seshagiri Venugopal, Tony Przygienda,
   Robert Raszuk and Iftekhar Hussain for their review and
   contributions.  Thank you to Oliver Knapp as well, for his detailed
   review.

10.  Contributors

   In addition to the authors listed on the front page, the following
   co-authors have also contributed to this document:

   Wim Henderickx
   Nokia

   Daniel Melzer
   DE-CIX Management GmbH

   Erik Nordmark
   Zededa

11.  References

11.1.  Normative References

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

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

Rabadan, et al.          Expires April 12, 2021                [Page 21]
Internet-Draft              EVPN Proxy-ARP/ND               October 2020

   [RFC0826]  Plummer, D., "An Ethernet Address Resolution Protocol: Or
              Converting Network Protocol Addresses to 48.bit Ethernet
              Address for Transmission on Ethernet Hardware", STD 37,
              RFC 826, DOI 10.17487/RFC0826, November 1982,
              <https://www.rfc-editor.org/info/rfc826>.

   [RFC6820]  Narten, T., Karir, M., and I. Foo, "Address Resolution
              Problems in Large Data Center Networks", RFC 6820,
              DOI 10.17487/RFC6820, January 2013,
              <https://www.rfc-editor.org/info/rfc6820>.

   [RFC3971]  Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander,
              "SEcure Neighbor Discovery (SEND)", RFC 3971,
              DOI 10.17487/RFC3971, March 2005,
              <https://www.rfc-editor.org/info/rfc3971>.

   [RFC5227]  Cheshire, S., "IPv4 Address Conflict Detection", RFC 5227,
              DOI 10.17487/RFC5227, July 2008,
              <https://www.rfc-editor.org/info/rfc5227>.

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

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

   [I-D.ietf-bess-evpn-na-flags]
              Rabadan, J., Sathappan, S., Nagaraj, K., and W. Lin,
              "Propagation of ARP/ND Flags in EVPN", draft-ietf-bess-
              evpn-na-flags-07 (work in progress), October 2020.

11.2.  Informative References

   [ARP-Sponge]
              N., W. M. A. S., "Effects of IPv4 and IPv6 address
              resolution on AMS-IX and the ARP Sponge", July 2009.

   [Euro-IX-BCP]
              Euro-IX, "European Internet Exchange Association Best
              Practises".

Rabadan, et al.          Expires April 12, 2021                [Page 22]
Internet-Draft              EVPN Proxy-ARP/ND               October 2020

Authors' Addresses

   Jorge Rabadan (editor)
   Nokia
   777 Middlefield Road
   Mountain View, CA  94043
   USA

   Email: jorge.rabadan@nokia.com

   Senthil Sathappan
   Nokia
   701 E. Middlefield Road
   Mountain View, CA 94043 USA

   Email: senthil.sathappan@nokia.com

   Kiran Nagaraj
   Nokia
   701 E. Middlefield Road
   Mountain View, CA 94043 USA

   Email: kiran.nagaraj@nokia.com

   Greg Hankins
   Nokia

   Email: greg.hankins@nokia.com

   Thomas King
   DE-CIX Management GmbH

   Email: thomas.king@de-cix.net

Rabadan, et al.          Expires April 12, 2021                [Page 23]