draft-ietf-bess-evpn-na-flags-05.txt   draft-ietf-bess-evpn-na-flags-06.txt 
BESS Workgroup J. Rabadan, Ed. BESS Workgroup J. Rabadan, Ed.
Internet-Draft S. Sathappan Internet-Draft S. Sathappan
Intended status: Standards Track K. Nagaraj Intended status: Standards Track K. Nagaraj
Expires: January 28, 2021 Nokia Expires: March 14, 2021 Nokia
W. Lin W. Lin
Juniper Juniper
July 27, 2020 September 10, 2020
Propagation of ARP/ND Flags in EVPN Propagation of ARP/ND Flags in EVPN
draft-ietf-bess-evpn-na-flags-05 draft-ietf-bess-evpn-na-flags-06
Abstract Abstract
An EVPN MAC/IP Advertisement route can optionally carry an IPv4 or This document defines an Extended Community that is advertised along
IPv6 addresses associated with a MAC address. Remote PEs can use with an EVPN MAC/IP Advertisement route and carries information
this information to populate their ARP/ND tables on IRB interfaces or relevant to the ARP/ND resolution, so that an EVPN PE implementing a
their proxy-ARP/ND tables in Broadcast Domains (BD). PEs can then proxy-ARP/ND function can reply to ARP Requests or Neighbor
reply locally (act as an ARP/ND proxy) to IPv4 ARP requests and IPv6 Solicitations with the correct information.
Neighbor Solicitation messages and reduce/suppress the flooding
produced by the Address Resolution procedure. However, the
information conveyed in the MAC/IP route may not be enough for the
remote PE to reply to local ARP or ND requests. For example, if a PE
learns an IPv6->MAC ND entry via EVPN, the PE would not know if that
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 EVPN
MAC/IP Advertisement routes. Similarly, other information relevant
to the IP->MAC ARP/ND entries may be needed. This document defines
an Extended Community that is advertised along with an EVPN MAC/IP
Advertisement route and carries information relevant to the ARP/ND
resolution, so that an EVPN PE implementing a proxy-ARP/ND function
can reply to ARP Requests or Neighbor Solicitations with the correct
information.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 28, 2021.
This Internet-Draft will expire on March 14, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Terminology and Conventions . . . . . . . . . . . . . . . 3 1.1. Terminology and Conventions . . . . . . . . . . . . . . . 3
2. The EVPN ARP/ND Extended Community . . . . . . . . . . . . . 4 2. The EVPN ARP/ND Extended Community . . . . . . . . . . . . . 3
3. Use of the EVPN ARP/ND Extended Community . . . . . . . . . . 5 3. Use of the EVPN ARP/ND Extended Community . . . . . . . . . . 5
3.1. Transmission of the EVPN ARP/ND Extended Community . . . 5 3.1. Transmission of the EVPN ARP/ND Extended Community . . . 5
3.2. Reception of the EVPN ARP/ND Extended Community . . . . . 6 3.2. Reception of the EVPN ARP/ND Extended Community . . . . . 6
4. Security Considerations . . . . . . . . . . . . . . . . . . . 7 4. Security Considerations . . . . . . . . . . . . . . . . . . . 7
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
7.1. Normative References . . . . . . . . . . . . . . . . . . 9 7.1. Normative References . . . . . . . . . . . . . . . . . . 9
7.2. Informative References . . . . . . . . . . . . . . . . . 9 7.2. Informative References . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction 1. Introduction
An EVPN MAC/IP Advertisement route can optionally carry an IPv4 or An Ethernet Virtual Private Network (EVPN) MAC/IP Advertisement route
IPv6 addresses associated with a MAC address. Remote PEs can use can optionally carry IPv4 or IPv6 addresses associated with a MAC
this information to populate their ARP/ND tables on IRB interfaces or address. Remote Provider Edge (PE) routers can use this information
their proxy-ARP/ND tables in Broadcast Domains (BD). PEs can then to populate their Address Resolution Protocol (ARP) or Neighbor
reply locally (act as an ARP/ND proxy, as per [RFC7432]) to IPv4 ARP Discovery (ND) tables on Integrated Routing and Bridging (IRB)
requests and IPv6 Neighbor Solicitation messages and reduce/suppress interfaces or their proxy-ARP/ND tables in Broadcast Domains (BD).
the flooding produced by the Address Resolution procedure. However, PEs can then reply locally (act as an ARP/ND proxy, as per [RFC7432])
the information conveyed in the EVPN MAC/IP Advertisement route may to IPv4 ARP requests and IPv6 Neighbor Solicitation messages and
not be enough for the remote PE to reply to local ARP or ND requests. reduce/suppress the flooding produced by the Address Resolution
For example, if a PE learns an IPv6->MAC ND entry via EVPN, the PE procedure. However, the information conveyed in the EVPN MAC/IP
would not know if that particular IPv6->MAC pair belongs to a host, a Advertisement route may not be enough for the remote PE to reply to
router or a host with an anycast address, as this information is not local ARP or ND requests. For example, if a PE learns an IPv6->MAC
carried in the EVPN MAC/IP Advertisement routes. Similarly, other ND entry via EVPN, the PE would not know if that particular IPv6->MAC
information relevant to the host advertised in the MAC/IP pair belongs to a router or a host, and if that address is an anycast
Advertisement route may be needed. address, as this information is not carried in the EVPN MAC/IP
Advertisement routes. Similarly, other information relevant to the
host advertised in the MAC/IP Advertisement route may be needed.
This document defines an Extended Community that is advertised along This document defines an Extended Community that is advertised along
with an EVPN MAC/IP Advertisement route and carries information with an EVPN MAC/IP Advertisement route and carries information
relevant to the ARP/ND resolution, so that an EVPN PE implementing a relevant to the ARP/ND resolution, so that an EVPN PE implementing a
proxy-ARP/ND function can reply to ARP Requests or Neighbor proxy-ARP/ND function can reply to ARP Requests or Neighbor
Solicitations with the correct information. In particular, the Flags Solicitations with the correct information. In particular, the Flags
defined in [RFC4861] can now be conveyed along with a MAC/IP defined in [RFC4861] can now be conveyed along with a MAC/IP
Advertisement route, so that an egress EVPN PE can issue Neighbor Advertisement route, so that an egress EVPN PE can issue Neighbor
Advertisement messages with the correct Flag information. Advertisement messages with the correct Flag information.
skipping to change at page 3, line 32 skipping to change at page 3, line 21
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
EVPN: Ethernet Virtual Private Networks, as in [RFC7432]. EVPN: Ethernet Virtual Private Networks, as in [RFC7432].
BD: Broadcast Domain, also described in [RFC7432]. BD: Broadcast Domain, also described in [RFC7432].
ARP: refers to the Address Resolution Protocol. ARP: Address Resolution Protocol.
ND: refers to the Neighbor Discovery protocol. ND: Neighbor Discovery protocol, specified in [RFC4861].
Proxy-ARP/ND: refers to a function on the EVPN PEs by which received PE: Provider Edge router.
Address Resolution Protocol (ARP) Requests or Neighbor Solicitation
(NS) messages are replied locally by the PE, without the need to
flood the requests to remote PEs in the BD. In order to reply to ARP
Requests or NS messages, the PE does a lookup on an ARP/ND table,
that is a collection of IP->MAC entries learned by the PE.
IP->MAC: refers to an IP address and MAC address combination that CE: Customer Edge router.
represents a given host and is added to an Address Resolution
Protocol table or Neighbor Discovery table. This document uses IRB: Integrated Routing and Bridging interface.
IP->MAC generically for IPv4 and IPv6 addresses. When something is
specific to IPv4, the document will use IPv4->MAC and likewise, Proxy-ARP/ND: function on the EVPN PEs by which received Address
IPv6->MAC will be used when something is specific to IPv6 entries Resolution Protocol (ARP) Requests or Neighbor Solicitation (NS)
only. messages are replied locally by the PE, without the need to flood the
requests to remote PEs in the BD. In order to reply to ARP Requests
or NS messages, the PE does a lookup on an ARP/ND table, that is a
collection of IP->MAC entries learned by the PE.
IP->MAC: an IP address and MAC address combination that represents a
given host and is added to an Address Resolution Protocol table or
Neighbor Discovery table. This document uses IP->MAC generically for
IPv4 and IPv6 addresses. When something is specific to IPv4, the
document will use IPv4->MAC and likewise, IPv6->MAC will be used when
something is specific to IPv6 entries only.
Familiarity with the terminology in [RFC7432] and [RFC4861] is Familiarity with the terminology in [RFC7432] and [RFC4861] is
expected. expected.
2. The EVPN ARP/ND Extended Community 2. The EVPN ARP/ND Extended Community
This document defines a new EVPN Extended Community (Type field value This document defines a new EVPN Extended Community (Type field value
of 0x06) with a Sub-Type of 0x08, as allocated by IANA. It is of 0x06) with a Sub-Type of 0x08, as allocated by IANA. It is
advertised along with EVPN MAC/IP Advertisement routes that carry an advertised along with EVPN MAC/IP Advertisement routes that carry an
IPv4 or IPv6 address. IPv4 or IPv6 address.
skipping to change at page 5, line 9 skipping to change at page 5, line 4
the PE will send an IPv6->MAC pair with the O Flag = 0. The ingress the PE will send an IPv6->MAC pair with the O Flag = 0. The ingress
PE will install the ND entry with the received O Flag and will use PE will install the ND entry with the received O Flag and will use
this information when replying to a Neighbor Solicitation for the this information when replying to a Neighbor Solicitation for the
IPv6 address. Similarly to the Router Flag, the Override Flag has no IPv6 address. Similarly to the Router Flag, the Override Flag has no
meaning for ARP IPv4->MAC entries and MUST be ignored when the meaning for ARP IPv4->MAC entries and MUST be ignored when the
Extended Community is received with an EVPN MAC/IP Advertisement Extended Community is received with an EVPN MAC/IP Advertisement
route for an IPv4->MAC pair. route for an IPv4->MAC pair.
I - Immutable ARP/ND Binding Flag (corresponds to Bit 20 of the I - Immutable ARP/ND Binding Flag (corresponds to Bit 20 of the
Extended Community) Extended Community)
Bit 4 of the Flags field is defined as the "Immutable ARP/ND Binding Bit 4 of the Flags field is defined as the "Immutable ARP/ND Binding
Flag". When set, the egress PE indicates that the IP->MAC pair sent Flag". When set, the egress PE indicates that the IP->MAC pair sent
in an EVPN MAC/IP Advertisement route along with the Extended in an EVPN MAC/IP Advertisement route (along with the Extended
Community is a configured ARP/ND entry, and the IP address in the Community) is a configured ARP/ND entry. The IP address in the EVPN
EVPN MAC/IP Advertisement route can only be bound together with the MAC/IP Advertisement route can only be bound together with the MAC
MAC address specified in the same route. address specified in the same route.
Bits 0-3 and 5 are not assigned by this document. Bits 0-3 and 5 are not assigned by this document. They MUST be set
to zero, and ignored on receipt.
3. Use of the EVPN ARP/ND Extended Community 3. Use of the EVPN ARP/ND Extended Community
This section describes the relevant procedures when advertising and This section describes the relevant procedures when advertising and
processing the EVPN ARP/ND Extended Community. In all the procedures processing the EVPN ARP/ND Extended Community. In all the procedures
below a "PE" must be interpreted as a "PE which supports the ND/ARP below a "PE" must be interpreted as a "PE which supports the ND/ARP
proxy function (introduced by [RFC7432]) and implements the proxy function (introduced by [RFC7432]) and implements the
propagation of the ARP/ND Flags that this document specifies". propagation of the ARP/ND Flags that this document specifies".
3.1. Transmission of the EVPN ARP/ND Extended Community 3.1. Transmission of the EVPN ARP/ND Extended Community
skipping to change at page 6, line 5 skipping to change at page 5, line 47
o MAC/IP Advertisement routes for IPv4->MAC entries MAY include the o MAC/IP Advertisement routes for IPv4->MAC entries MAY include the
ARP/ND Extended Community. If the EVPN ARP/ND Extended Community ARP/ND Extended Community. If the EVPN ARP/ND Extended Community
is advertised along with an EVPN IPv4/MAC Advertisement route, the is advertised along with an EVPN IPv4/MAC Advertisement route, the
R and O Flags SHOULD be set to zero. R and O Flags SHOULD be set to zero.
o If an IP->MAC pair is static (it has been configured) the o If an IP->MAC pair is static (it has been configured) the
corresponding MAC/IP Advertisement route MUST be sent along with corresponding MAC/IP Advertisement route MUST be sent along with
an ARP/ND Extended Community with the I Flag set. an ARP/ND Extended Community with the I Flag set.
o This Extended Community does not have any impact on the procedures o This Extended Community does not change the procedures described
described in [RFC7432], including the advertisement of the MAC in [RFC7432]. Specifically the procedures for advertising the MAC
Mobility Extended Community along with the MAC/IP Advertisement Mobility Extended Community along with the MAC/IP Advertisement
route. route are not changed.
3.2. Reception of the EVPN ARP/ND Extended Community 3.2. Reception of the EVPN ARP/ND Extended Community
In addition to the procedures specified in [RFC7432] a PE receiving a In addition to the procedures specified in [RFC7432] a PE receiving a
MAC/IP Advertisement route will process the EVPN ARP/ND Extended MAC/IP Advertisement route will process the EVPN ARP/ND Extended
Community as follows: Community as follows:
o 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.
o R and O Flags processing: o R and O Flags processing:
* If the EVPN MAC/IP Advertisement route contains an IPv6 address * 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 the EVPN ARP/ND Extended Community, the PE MUST add the R
and O Flags to the ND entry in the ND or proxy-ND table and use and O Flags to the ND entry in the ND or proxy-ND table and use
that information in Neighbor Advertisements when replying to a that information in Neighbor Advertisements when replying to a
Solicitation for the IPv6 address. Solicitation for the IPv6 address.
* If no EVPN ARP/ND Extended Community is received along with the * 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. route, the PE will add the default R and O Flags to the entry.
skipping to change at page 6, line 38 skipping to change at page 6, line 38
* A PE MUST ignore the received R and O Flags for an EVPN MAC/IP * A PE MUST ignore the received R and O Flags for an EVPN MAC/IP
Advertisement route that contains an IPv4->MAC pair. Advertisement route that contains an IPv4->MAC pair.
o I Flag processing: o I Flag processing:
* A PE receiving an EVPN MAC/IP Advertisement route containing an * 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 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". the ARP/ND or proxy-ARP/ND table as an "Immutable binding".
This Immutable binding entry will override an existing non- This Immutable binding entry will override an existing non-
immutable binding for the same IP->MAC. The absense of the immutable binding for the same IP->MAC. The absence of the
EVPN ARP/ND Extended Community in a MAC/IP Advertisment route EVPN ARP/ND Extended Community in a MAC/IP Advertisement route
indicates that the IP->MAC entry is not an "Immutable binding". indicates that the IP->MAC entry is not an "Immutable binding".
* 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.
* Receiving multiple EVPN MAC/IP Advertisement routes with I=1 * Receiving multiple EVPN MAC/IP Advertisement routes with I=1
for the same IP but different MAC is considered a for the same IP but different MAC is considered a
misconfiguration. misconfiguration.
* As an example, consider PE1, PE2 and PE3 are attached to the
same BD. PE1 originates an EVPN MAC/IP Advertisement route for
IP1->MAC1 with I=1; later on, PE2 also originates an EVPN MAC/
IP Advertisement route IP1->MAC1 with a higher sequence number
and I=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. If for some reason, PE3
originates an EVPN MAC/IP Advertisement route for IP1->MAC2
(even with a higher sequence number), then the EVPN PEs in the
BD SHOULD 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.
* A PE originating an EVPN MAC/IP Advertisement route for * A PE originating an EVPN MAC/IP Advertisement route for
IP1->MAC1 with I=1 MAY also originate the route with the Static IP1->MAC1 with I=1 MAY also originate the route with the Static
bit set (in the MAC Mobility Extended Community). In such a bit set (in the MAC Mobility Extended Community). In such a
case, the IP1->MAC1 binding is not only immutable but it cannot case, the IP1->MAC1 binding is not only immutable but it cannot
move as well. Even so, if an update for the same IP1->MAC1 move as well. Even so, if an update for the same IP1->MAC1
immutable and static, is received from a different PE, one of immutable and static, is received from a different PE, one of
the two routes will be selected, as in the [RFC7432] case where the two routes will be selected, as in the [RFC7432] case where
two MAC/IP routes with Static bit are received for the same MAC two MAC/IP routes with Static bit are received for the same MAC
from different PEs. from different PEs.
* The use of the Flag I=1 assumes that a given IP is always bound In a situation where a host (with an IP->MAC that is configured as
to the same MAC address, and therefore the mobility procedures Immutable binding in the attached PE) is allowed to move between PEs
described in [I-D.ietf-bess-evpn-irb-extended-mobility] for (that is, the associated MAC is non-static), PEs can receive multiple
"Host IP move to a new MAC" will not apply. MAC/IP advertisement routes for the same IP->MAC. In such
situations, MAC mobility procedures as in [RFC7432] dictate the
reachability of the MAC.
o The R, O and I Flags MUST be ignored if they are advertised along As an example of the use of the I Flag, consider PE1, PE2 and PE3 are
with an EVPN MAC/IP Advertisement route that does not contain an attached to the same BD. PE1 originates an EVPN MAC/IP Advertisement
IP (IPv4 or IPv6) address. route for IP1->MAC1 with I=1; later on, PE2 also originates an EVPN
MAC/IP Advertisement route IP1->MAC1 with a higher sequence number
and I=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. If for some reason, PE3 originates an EVPN MAC/
IP Advertisement route for IP1->MAC2 (even with a higher sequence
number), then the EVPN PEs in the BD SHOULD 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.
The use of the Flag I=1 assumes that a given IP is always bound to
the same MAC address, and therefore the mobility procedures described
in [I-D.ietf-bess-evpn-irb-extended-mobility] for "Host IP move to a
new MAC" will not apply.
4. Security Considerations 4. Security Considerations
The same security considerations described in [RFC7432] apply to this The same security considerations described in [RFC7432] apply to this
document. document.
In addition, this document adds pieces of information that impact on In addition, this document adds pieces of information that impact on
the way ARP/ND entries are installed in ARP/ND and/or proxy-ARP/ND the way ARP/ND entries are installed in ARP/ND and/or proxy-ARP/ND
tables, and therefore the resolution protocols for IPv4 and IPv6 tables, and therefore the resolution protocols for IPv4 and IPv6
addresses. For instance, if a given IPv6->MAC binding is configured 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 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 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 information for the IPv6->MAC. This will cause all the PEs in the BD
to reply Neighbor Solicitations for the IPv6 with Neighbor to reply to Neighbor Solicitations for the IPv6 with Neighbor
Advertisement messages containing the wrong R and O Flags. Advertisement (NA) messages containing the wrong R and O Flags. For
example, as specified in [RFC4861], the receiver of a 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 a NA message with the wrong R flag, may
update its Default Router List incorrectly adding or removing an
entry.
The I Flag, or Immutable ARP/ND Binding Flag, introduces a useful The I Flag, or Immutable ARP/ND Binding Flag, introduces a useful
security tool so that an operator makes sure a given IP address is security tool so that an operator makes sure a given IP address is
always bound to the same MAC and that information is distributed to always bound to the same MAC and that information is distributed to
all the PEs attached to the same BD. ARP/ND spoofing attacks from all the PEs attached to the same BD. ARP/ND spoofing attacks from
hosts injecting Gratuitous ARPs or unsolicited Neighbor Advertisement hosts injecting Gratuitous ARPs or unsolicited Neighbor Advertisement
messages for that IP address with a different MAC address will not messages for that IP address with a different MAC address will not
succeed to be programmed in ARP/ND and proxy-ARP/ND tables and succeed to be programmed in ARP/ND and proxy-ARP/ND tables and
therefore will avoid attracting traffic to the spoofer. therefore will avoid attracting traffic to the spoofer.
 End of changes. 24 change blocks. 
95 lines changed or deleted 97 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/