%% You should probably cite draft-ietf-bess-evpn-na-flags instead of this I-D. @techreport{snr-bess-evpn-na-flags-00, number = {draft-snr-bess-evpn-na-flags-00}, type = {Internet-Draft}, institution = {Internet Engineering Task Force}, publisher = {Internet Engineering Task Force}, note = {Work in Progress}, url = {https://datatracker.ietf.org/doc/draft-snr-bess-evpn-na-flags/00/}, author = {Jorge Rabadan and Senthil Sathappan and Kiran Nagaraj}, title = {{Propagation of IPv6 Neighbor Advertisement Flags in EVPN}}, pagetotal = 6, year = 2015, month = mar, day = 8, 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-\textgreater{}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.}, }