Skip to main content

Propagation of IPv6 Neighbor Advertisement Flags in EVPN
draft-snr-bess-evpn-na-flags-02

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Replaced".
Expired & archived
Authors Jorge Rabadan , Senthil Sathappan , Kiran Nagaraj
Last updated 2016-01-07 (Latest revision 2015-07-06)
Replaced by draft-ietf-bess-evpn-na-flags, draft-ietf-bess-evpn-na-flags, RFC 9047
RFC stream (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state Expired
Telechat date (None)
Responsible AD (None)
Send notices to (None)

This Internet-Draft is no longer active. A copy of the expired Internet-Draft is available in these formats:

Abstract

The MAC/IP Advertisement route specified in [RFC7432] can optionally carry IPv4 and IPv6 addresses associated with a MAC address. Remote PEs can use this information to reply locally (act as proxy) to IPv4 ARP requests and IPv6 Neighbor Solicitation messages and reduce/suppress the flooding produced by the Address Resolution procedure. However, if the Neighbor information is learnt via EVPN, the PE would not know if a particular IPv6->MAC pair belongs to a host, a router or a host with an anycast address as this information is not carried in the MAC/IP route advertisements. This document proposes an OPTIONAL advertisement of the Flags defined in [RFC4861] along with the EVPN MAC/IP Advertisement routes, so that an EVPN PE implementing a proxy-ND function can reply to Neighbor Solicitations with the correct Flag information in Neighbor Advertisements.

Authors

Jorge Rabadan
Senthil Sathappan
Kiran Nagaraj

(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)