doc: Add RFC documents

1 files changed, 1011 insertions, 0 deletions

diff --git a/doc/rfc/rfc8302.txt b/doc/rfc/rfc8302.txt
new file mode 100644
index 0000000..620d8cb
--- /dev/null
+++ b/doc/rfc/rfc8302.txt
@@ -0,0 +1,1011 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                             Y. Li
+Request for Comments: 8302                               D. Eastlake 3rd
+Category: Standards Track                                      L. Dunbar
+ISSN: 2070-1721                                      Huawei Technologies
+                                                              R. Perlman
+                                                                Dell EMC
+                                                                M. Umair
+                                                                   Cisco
+                                                            January 2018
+
+
+         Transparent Interconnection of Lots of Links (TRILL):
+              ARP and Neighbor Discovery (ND) Optimization
+
+Abstract
+
+   This document describes mechanisms to optimize the Address Resolution
+   Protocol (ARP) and Neighbor Discovery (ND) traffic in a Transparent
+   Interconnection of Lots of Links (TRILL) campus.  TRILL switches
+   maintain a cache of IP / Media Access Control (MAC) address / Data
+   Label bindings that are learned from ARP/ND requests and responses
+   that pass through them.  In many cases, this cache allows an edge
+   Routing Bridge (RBridge) to avoid flooding an ARP/ND request by
+   either responding to it directly or encapsulating it and unicasting
+   it.  Such optimization reduces packet flooding over a TRILL campus.
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   Internet Standards is available in Section 2 of RFC 7841.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   https://www.rfc-editor.org/info/rfc8302.
+
+
+
+
+
+
+
+
+
+
+
+
+Li, et al.                   Standards Track                    [Page 1]
+
+RFC 8302                TRILL ARP/ND Optimization           January 2018
+
+
+Copyright Notice
+
+   Copyright (c) 2018 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) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+Table of Contents
+
+   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
+     1.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   3
+   2.  ARP/ND Optimization Requirement and Solution  . . . . . . . .   4
+   3.  IP/MAC Address Mappings . . . . . . . . . . . . . . . . . . .   5
+   4.  Handling ARP/ND/SEND Messages . . . . . . . . . . . . . . . .   6
+     4.1.  SEND Considerations . . . . . . . . . . . . . . . . . . .   7
+     4.2.  Address Verification  . . . . . . . . . . . . . . . . . .   7
+     4.3.  Extracting Local Mapping Information for End-Station
+           IP/MAC Addresses  . . . . . . . . . . . . . . . . . . . .   8
+     4.4.  Determining How to Reply to ARP/ND  . . . . . . . . . . .   9
+     4.5.  Determining How to Handle the ARP/ND Response . . . . . .  10
+   5.  Handling of Reverse Address Resolution Protocol (RARP)
+       Messages  . . . . . . . . . . . . . . . . . . . . . . . . . .  11
+   6.  Handling of DHCP Messages . . . . . . . . . . . . . . . . . .  11
+   7.  Handling of Duplicate IP Addresses  . . . . . . . . . . . . .  11
+   8.  RBridge ARP/ND Cache Liveness and MAC Mobility  . . . . . . .  12
+   9.  Security Considerations . . . . . . . . . . . . . . . . . . .  13
+     9.1.  Data-Plane-Based Considerations . . . . . . . . . . . . .  13
+     9.2.  Directory-Based Considerations  . . . . . . . . . . . . .  14
+     9.3.  Use of the Confidence Level Feature . . . . . . . . . . .  14
+   10. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  14
+   11. References  . . . . . . . . . . . . . . . . . . . . . . . . .  15
+     11.1.  Normative References . . . . . . . . . . . . . . . . . .  15
+     11.2.  Informative References . . . . . . . . . . . . . . . . .  16
+   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  17
+   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  18
+
+
+
+
+
+
+
+
+Li, et al.                   Standards Track                    [Page 2]
+
+RFC 8302                TRILL ARP/ND Optimization           January 2018
+
+
+1.  Introduction
+
+   ARP [RFC826] and ND [RFC4861] messages are normally sent by broadcast
+   and multicast, respectively.  To reduce the burden on a TRILL campus
+   caused by these multi-destination messages, RBridges MAY implement an
+   "optimized ARP/ND response", as specified herein, when the target's
+   location is known by the ingress RBridge or can be obtained from a
+   directory.  This avoids ARP/ND query and answer flooding.
+
+1.1.  Terminology
+
+   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.
+
+   The abbreviations and terminology in [RFC6325] are used herein.  Some
+   of these are listed below for convenience along with some additions:
+
+   APPsub-TLV   Application sub-Type-Length-Value [RFC6823]
+
+   ARP          Address Resolution Protocol [RFC826]
+
+   Campus       A TRILL network consisting of RBridges, links, and
+                possibly bridges bounded by end stations and IP routers
+                [RFC6325]
+
+   DAD          Duplicate Address Detection [RFC3756] [RFC5227]
+
+   Data Label   VLAN or Fine-Grained Label (FGL)
+
+   DHCP         Dynamic Host Configuration Protocol.  In this document,
+                DHCP refers to both DHCP for IPv4 [RFC2131] and DHCPv6
+                [RFC3315]
+
+   ESADI        End Station Address Distribution Information [RFC7357]
+
+   FGL          Fine-Grained Label [RFC7172]
+
+   IA           Interface Address; a TRILL APPsub-TLV [RFC7961]
+
+   IP           Internet Protocol, both IPv4 and IPv6
+
+   MAC          Media Access Control [RFC7042]
+
+   ND           Neighbor Discovery [RFC4861]
+
+
+
+
+Li, et al.                   Standards Track                    [Page 3]
+
+RFC 8302                TRILL ARP/ND Optimization           January 2018
+
+
+   RBridge      A contraction of "Routing Bridge".  A device
+                implementing the TRILL protocol.
+
+   SEND         Secure Neighbor Discovery [RFC3971]
+
+   TRILL        Transparent Interconnection of Lots of Links or Tunneled
+                Routing in the Link Layer [RFC6325] [RFC7780]
+
+2.  ARP/ND Optimization Requirement and Solution
+
+   IP address resolution can create significant issues in data centers
+   due to flooded packets, as discussed in [RFC6820].  Such flooding can
+   be avoided by a proxy ARP/ND function on edge RBridges as described
+   in this document, particularly in Section 4.  This section is a
+   general discussion of this problem and is not intended to be
+   normative.
+
+   To support such ARP/ND optimization, edge RBridges need to know an
+   end station's IP/MAC address mapping through manual configuration
+   (management), control-plane mechanisms such as directories [RFC8171],
+   or data-plane learning by snooping of messages such as ARP/ND
+   (including DHCP or gratuitous ARP messages).
+
+   When all the end station's IP/MAC address mappings are known to edge
+   RBridges, provisioned through management, or learned via the control
+   plane on the edge RBridges, it should be possible to completely
+   suppress flooding of ARP/ND messages in a TRILL campus.  When all end
+   station MAC addresses are similarly known, it should be possible to
+   suppress unknown unicast flooding by dropping any unknown unicast
+   received at an edge RBridge.
+
+   An ARP/ND optimization mechanism should include provisions for an
+   edge RBridge to issue an ARP/ND request to an attached end station to
+   confirm or update information and should allow an end station to
+   detect duplication of its IP address.
+
+   Most of the end station hosts send either DHCP messages requesting an
+   IP address or gratuitous ARP or Reverse Address Resolution Protocol
+   (RARP) requests to announce themselves to the network right after
+   they come online.  Thus, the local edge RBridge will immediately have
+   the opportunity to snoop and learn their MAC and IP addresses and
+   distribute this information to other edge RBridges through the TRILL
+   control-plane End Station Address Distribution Information (ESADI)
+   [RFC7357] protocol.  Once remote RBridges receive this information
+   via the control plane, they should add IP-to-MAC mapping information
+   to their ARP/ND cache along with the nickname and Data Label of the
+   address information.  Therefore, most active IP hosts in the TRILL
+
+
+
+
+Li, et al.                   Standards Track                    [Page 4]
+
+RFC 8302                TRILL ARP/ND Optimization           January 2018
+
+
+   network can be learned by the edge RBridges through either local
+   learning or control-plane-based remote learning.  As a result, ARP
+   suppression can vastly reduce the network flooding caused by host ARP
+   learning behavior.
+
+   When complete directory information is available, the default data-
+   plane learning of end-station MAC addresses is not only unnecessary
+   but could be harmful if there is learning based on frames with forged
+   source addresses.  Such data-plane learning can be suppressed because
+   TRILL already provides an option to disable data-plane learning from
+   the source MAC address of end-station frames (see Section 5.3 of
+   [RFC6325]).
+
+3.  IP/MAC Address Mappings
+
+   By default, an RBridge [RFC6325] [RFC7172] learns egress nickname
+   mapping information for the MAC address and Data Label (VLAN or FGL)
+   of TRILL data frames it receives and decapsulates.  No IP address
+   information is learned directly from the TRILL data frame.  The IA
+   APPsub-TLV [RFC7961] enhances the TRILL base protocol by allowing IP/
+   MAC address mappings to be distributed in the control plane by any
+   RBridge.  This APPsub-TLV appears inside the TRILL GENINFO TLV in
+   ESADI [RFC7357], but the value data structure it specifies may also
+   occur in other application contexts.  Edge RBridge Directory Assist
+   Mechanisms [RFC8171] make use of this APPsub-TLV for its push model
+   and use the value data structure it specifies in its pull model.
+
+   An RBridge can easily know the IP/MAC address mappings of the local
+   end stations that it is attached to via its access ports by receiving
+   ARP [RFC826] or ND [RFC4861] messages.  If the edge RBridge has
+   extracted the sender's IP/MAC address pair from the received data
+   frame (either ARP or ND), it may save the information and then use
+   the IA APPsub-TLV to link the IP and MAC addresses and distribute it
+   to other RBridges through ESADI.  Then, the relevant remote RBridges
+   (normally those interested in the same Data Label as the original
+   ARP/ND messages) also receive and save such mapping information.
+   There are other ways that RBridges save IP/MAC address mappings in
+   advance, e.g., importing them from the management system and
+   distributing them by directory servers [RFC8171].
+
+   The examples given above show that RBridges might have saved an end
+   station's triplet of {IP address, MAC address, ingress nickname} for
+   a given Data Label (VLAN or FGL) before that end station sends or
+   receives any real data packet.  Note that such information might or
+   might not be a complete list and might or might not exist on all
+   RBridges; the information could possibly be from different sources.
+   RBridges can then use the Flags field in an IA APPsub-TLV to identify
+
+
+
+
+Li, et al.                   Standards Track                    [Page 5]
+
+RFC 8302                TRILL ARP/ND Optimization           January 2018
+
+
+   if the source is a directory server or local observation by the
+   sender.  A different confidence level may also be used to indicate
+   the reliability of the mapping information.
+
+4.  Handling ARP/ND/SEND Messages
+
+   A native frame that is an ARP [RFC826] message is detected by its
+   Ethertype of 0x0806.  A native frame that is an ND [RFC4861] is
+   detected by being one of five different ICMPv6 packet types.  ARP/ND
+   is commonly used on a link to (1) query for the MAC address
+   corresponding to an IPv4 or IPv6 address, (2) test if an IPv4/IPv6
+   address is already in use, or (3) announce the new or updated info on
+   any of the following: IPv4/IPv6 address, MAC address, and/or point of
+   attachment.
+
+   To simplify the text, we use the following terms in this section.
+
+   1.  IP address -- indicated protocol address that is normally an IPv4
+       address in ARP or an IPv6 address in ND.
+
+   2.  sender's IP/MAC address -- sender IP/MAC address in ARP, source
+       IP address, and source link-layer address in ND.
+
+   3.  target's IP/MAC address -- target IP/MAC address in ARP, target
+       address, and target link-layer address in ND.
+
+   When an ingress RBridge receives an ARP/ND/SEND message, it can
+   perform the steps described within the subsections below.  In
+   particular, Section 4.4 describes the options for such an ingress
+   handling an ARP/ND message and, in the cases where it forwards the
+   message, Section 4.5 describes how to handle any response that may be
+   returned due to the forwarded message.
+
+   Section 4.3 describes the extraction of address information by an
+   RBridge from ARP/ND messages it handles.  Under some circumstances,
+   this extraction may prompt verification with an end station.
+   Section 4.2 describes an optional use of ARP/ND messages originated
+   by RBridges to verify addresses or liveness.
+
+   As described in Section 4.1, SEND messages are not optimized by the
+   mechanisms specified in this document but are snooped on.
+
+
+
+
+
+
+
+
+
+
+Li, et al.                   Standards Track                    [Page 6]
+
+RFC 8302                TRILL ARP/ND Optimization           January 2018
+
+
+4.1.  SEND Considerations
+
+   Secure Neighbor Discovery (SEND) [RFC3971] is a method of securing ND
+   that addresses the threats discussed in [RFC3756].  Typical TRILL
+   campuses are inside data centers, Internet exchange points, or
+   carrier facilities.  These are generally controlled and protected
+   environments where these threats are of less concern.  Nevertheless,
+   SEND provides an additional layer of protection.
+
+   Secure SEND messages require knowledge of cryptographic keys.
+   Methods of communicating such keys to RBridges for use in SEND are
+   beyond the scope of this document.  Thus, using the optimizations in
+   this document, RBridges do not attempt to construct SEND messages and
+   are generally transparent to them.  RBridges only construct ARP,
+   RARP, or insecure ND messages, as appropriate.  Nevertheless,
+   RBridges implementing ARP/ND optimization SHOULD snoop on SEND
+   messages to extract the addressing information that would be present
+   if the SEND had been sent as an insecure ND message and is still
+   present in the SEND message.
+
+4.2.  Address Verification
+
+   RBridges may use ARP/ND to probe directly attached or remote end
+   stations for address or liveness verification.  This is typically
+   most appropriate in less-managed and/or higher-mobility environments.
+   In strongly managed environments, such as a typical data center,
+   where a central orchestration/directory system has complete
+   addressing knowledge [RFC7067], optimized ARP/ND responses can use
+   that knowledge.  In such cases, there is little reason for
+   verification except for debugging operational problems or the like.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Li, et al.                   Standards Track                    [Page 7]
+
+RFC 8302                TRILL ARP/ND Optimization           January 2018
+
+
+4.3.  Extracting Local Mapping Information for End-Station IP/MAC
+      Addresses
+
+   Edge RBridges extract and use information about the correspondence
+   between local end-station IP and MAC addresses from the ARP/ND
+   messages those end stations send, as described below.  An apparent
+   zero source IP address means that the end station is probing for
+   duplicate IP addresses, and messages with such a zero source IP
+   address are not used for the extraction of IP/MAC address mapping
+   information.
+
+   o  If the sender's IP is not present in the ingress RBridge's ARP/ND
+      cache, populate the information of the sender's IP/MAC address
+      mapping in its ARP/ND cache table.  The ingress RBridge correlates
+      its nickname and that IP/MAC address mapping information.  Such a
+      triplet of {IP address, MAC address, ingress nickname} information
+      is saved locally and can be distributed to other RBridges, as
+      explained later.
+
+   o  Else, if the sender's IP has been saved before but with a
+      different MAC address mapped or a different ingress nickname
+      associated with the same pair of IP/MAC, the RBridge SHOULD verify
+      if a duplicate IP address has already been in use or an end
+      station has changed its attaching RBridge.  The RBridge may use
+      different strategies to do so.  For example, the RBridge might ask
+      an authoritative entity like directory servers or it might
+      encapsulate and unicast the ARP/ND message to the location where
+      it believes the address is in use (Section 4.2).  RBridge SHOULD
+      update the saved triplet of {IP address, MAC address, ingress
+      nickname} based on the verification results.  An RBridge might not
+      verify an IP address if the network manager's policy is to have
+      the network behave, for each Data Label, as if it were a single
+      link and just believe an ARP/ND it receives.
+
+   The ingress RBridge MAY use the IA APPsub-TLV [RFC7961] with the
+   Local flag set in ESADI [RFC7357] to distribute any new or updated
+   triplet of {IP address, MAC address, ingress nickname} information
+   obtained.  If a Push Directory server is used, such information can
+   be distributed as specified in [RFC8171].
+
+
+
+
+
+
+
+
+
+
+
+
+Li, et al.                   Standards Track                    [Page 8]
+
+RFC 8302                TRILL ARP/ND Optimization           January 2018
+
+
+4.4.  Determining How to Reply to ARP/ND
+
+   The options for an edge RBridge to handle a native ARP/ND are given
+   below.  For generic ARP/ND requests seeking the MAC address
+   corresponding to an IP address, if the edge RBridge knows the IP
+   address and corresponding MAC, behavior is as in item (a), otherwise
+   behavior is as in item (b).  Behavior for gratuitous ARP and ND
+   unsolicited Neighbor Advertisements (NAs) [RFC4861] is given in item
+   (c).  And item (d) covers the handling of an Address Probe ARP query.
+   Within each lettered item, it is an implementation decision as to
+   which numbered strategy to use for any particular ARP/ND query
+   falling under that item.
+
+   a.  If the message is a generic ARP/ND request, and the ingress
+       RBridge knows the target's IP address and associated MAC address,
+       the ingress RBridge MUST take one or a combination of the actions
+       below.  In the case of SEND [RFC3971], cryptography would prevent
+       a local reply by the ingress RBridge, since the RBridge would not
+       be able to sign the response with the target's private key, and
+       only action a.2 or a.5 is valid.
+
+       a.1.  Send an ARP/ND response directly to the querier, using the
+             target's MAC address present in the ingress RBridge's ARP/
+             ND cache table.  Because the edge RBridge might not have an
+             IPv6 address, the source IP address for such an ND response
+             MUST be that of the target end station.
+
+       a.2.  Encapsulate the ARP/ND/SEND request to the target's
+             Designated RBridge and have the egress RBridge for the
+             target forward the query to the target.  This behavior has
+             the advantage that a response to the request is
+             authoritative.  If the request does not reach the target,
+             then the querier does not get a response.
+
+       a.3.  Block ARP/ND requests that occur for some time after a
+             request to the same target has been launched, and then
+             respond to the querier when the response to the recently
+             launched query to that target is received.
+
+       a.4.  Reply to the querier based on directory information
+             [RFC8171] such as information obtained from a Pull
+             Directory server or directory information that the ingress
+             RBridge has requested to be pushed to it.
+
+       a.5.  Flood the ARP/ND/SEND request as per [RFC6325].
+
+
+
+
+
+
+Li, et al.                   Standards Track                    [Page 9]
+
+RFC 8302                TRILL ARP/ND Optimization           January 2018
+
+
+   b.  If the message is a generic ARP/ND/SEND request and the ingress
+       RBridge does not know the target's IP address, the ingress
+       RBridge MUST take one of the following actions.  In the case of
+       SEND [RFC3971], cryptography would prevent local reply by the
+       ingress RBridge, since the RBridge would not be able to sign the
+       response with the target's private key; therefore, only action
+       b.1 is valid.
+
+       b.1.  Flood the ARP/ND/SEND message as per [RFC6325].
+
+       b.2.  Use a directory server to pull the information [RFC8171]
+             and reply to the querier.
+
+       b.3.  Drop the message if there should be no response because the
+             directory server gives authoritative information that the
+             address being queried is nonexistent.
+
+   c.  If the message is a gratuitous ARP, which can be identified by
+       the same sender's and target's "protocol" address fields, or an
+       unsolicited Neighbor Advertisement [RFC4861] in ND/SEND then:
+
+       The RBridge MAY use an IA APPsub-TLV [RFC7961] with the Local
+       flag set to distribute the sender's IP/MAC address mapping
+       information.  When one or more directory servers are deployed and
+       complete Push Directory information is used by all the RBridges
+       in the Data Label, a gratuitous ARP or unsolicited NA SHOULD be
+       discarded rather than ingressed.  Otherwise, they are either
+       ingressed and flooded as per [RFC6325] or discarded depending on
+       local policy.
+
+   d.  If the message is an Address Probe ARP query [RFC5227], which can
+       be identified by the sender's protocol (IPv4) address field being
+       zero and the target's protocol address field being the IPv4
+       address to be tested or a Neighbor Solicitation for Duplicate
+       Address Detection (DAD) that has the unspecified source address
+       [RFC4862], it SHOULD be handled as the generic ARP message as in
+       (a) or (b) above.
+
+4.5.  Determining How to Handle the ARP/ND Response
+
+   If the ingress RBridge R1 decides to unicast the ARP/ND request to
+   the target's egress RBridge R2 as discussed in Section 4.4, item a.2
+   or to flood the request as per item a.5 and [RFC6325], then R2
+   decapsulates the query and initiates an ARP/ND query on the target's
+   link.  If and when the target responds, R2 encapsulates and unicasts
+   the response to R1, which decapsulates the response and sends it to
+   the querier.  R2 SHOULD initiate a link state update to inform all
+   the other RBridges of the target's location, Layer 3 address, and
+
+
+
+Li, et al.                   Standards Track                   [Page 10]
+
+RFC 8302                TRILL ARP/ND Optimization           January 2018
+
+
+   Layer 2 address, in addition to forwarding the reply to the querier.
+   The update uses an IA APPsub-TLV [RFC7961] (so the Layer 3 and Layer
+   2 addresses can be linked) with the Local flag set in ESADI [RFC7357]
+   or as per [RFC8171] if the Push Directory server is in use.
+
+5.  Handling of Reverse Address Resolution Protocol (RARP) Messages
+
+   RARP [RFC903] uses the same packet format as ARP but different
+   Ethertype (0x8035) and opcode values.  Its processing is similar to
+   the generic ARP request/response as described in Section 4.4, items
+   a. and b.  The difference is that it is intended to query for the
+   target "protocol" (IP) address corresponding to the target "hardware"
+   (MAC) address provided.  It SHOULD be handled by doing a local cache
+   or directory server lookup on the target "hardware" address provided
+   to find a mapping to the desired "protocol" address.
+
+6.  Handling of DHCP Messages
+
+   When a newly connected end station exchanges messages with a DHCP
+   [RFC3315][RFC2131] server, an edge RBridge should snoop them (mainly
+   the DHCPAck message) and store IP/MAC address mapping information in
+   its ARP/ND cache and should also send the information out through the
+   TRILL control plane using ESADI.
+
+7.  Handling of Duplicate IP Addresses
+
+   Duplicate IP addresses within a Data Label can occur due to an
+   attacker sending fake ARP/ND messages or due to human/configuration
+   errors.  If complete, trustworthy directory information is available,
+   then, by definition, the IP location information in the directory is
+   correct.  Any appearance of an IP address in a different place
+   (different edge RBridge or port) from other sources is not correct.
+
+   Without complete directory information, the ARP/ND optimization
+   function should support duplicate IP detection.  This is critical in
+   a data center to stop an attacker from using ARP/ND spoofing to
+   divert traffic from its intended destination.
+
+   Duplicate IP addresses can be detected when an existing active IP/MAC
+   address mapping gets modified.  Also, an edge RBridge may send a
+   query called a Duplicate Address Detection query (DAD-query) asking
+   about the IP address in question to the former owner of that IP
+   address by using the MAC address formerly associated with that IP
+   address.  A DAD-query is a unicast ARP/ND message with sender IP
+   0.0.0.0 in case of ARP (or a configurable IP address per RBridge
+   called the DAD-Query source IP) and an IPv6 Link Local Address in
+   case of ND with the source MAC set to the DAD-querier RBridge's MAC.
+   If the querying RBridge does not receive an answer within a given
+
+
+
+Li, et al.                   Standards Track                   [Page 11]
+
+RFC 8302                TRILL ARP/ND Optimization           January 2018
+
+
+   time, it may be a case of mobility; in any case, the new IP entry
+   will be confirmed and activated in its ARP/ND cache.
+
+   In the case where the former owner replies, a duplicate address has
+   been detected.  In this case, the querying RBridge SHOULD log the
+   duplicate so that the network administrator can take appropriate
+   action.
+
+   It is an implementation choice how to respond to a query for an
+   address that is duplicated in the network when authoritative
+   information is not available from a directory or configuration.
+   Typically, the information most recently snooped is returned.
+
+8.  RBridge ARP/ND Cache Liveness and MAC Mobility
+
+   A maintenance procedure is needed for RBridge ARP/ND caching to
+   ensure IP end stations connected to ingress RBridges are still
+   active.
+
+   Some links provide a physical-layer indication of link liveness.  A
+   dynamic proxy ARP/ND entry (one learned from data-plane observation)
+   MUST be removed from the table if the link over which it was learned
+   fails.
+
+   Similarly, a dynamic proxy ARP/ND entry SHOULD be flushed out of the
+   table if the IP/MAC address mapping has not been refreshed within a
+   given age-time.  The entry is refreshed if an ARP or ND message is
+   received for the same IP/MAC address mapping entry from any location.
+   The IP/MAC address mapping information Ageing Timer is configurable
+   per RBridge and defaults to 3/4 of the MAC address learning Ageing
+   Timer [RFC6325].
+
+   For example, end station "A" is connected to edge-RBridge1 (RB1) and
+   has been learned as a local entry on RB1.  If end station "A" moves
+   to some other location (MAC / Virtual Machine (VM) Mobility) and gets
+   connected to edge-RBridge (RB2), after learning on RB2's access port,
+   RB2 advertises this entry through the TRILL control plane, and it is
+   learned on RB1 as a remote entry.  The old entry on RB1 SHOULD get
+   replaced, and all other edge-RBridges with end-station service
+   enabled for that Data Label should update the entry to show
+   reachability from RB2 instead of RB1.
+
+   If an ARP/ND entry in the cache is not refreshed, then the RBridge
+   connected to that end station MAY send periodic refresh messages
+   (ARP/ND "probes") to that end station, so that the entries can be
+   refreshed before they age out.  The end station would reply to the
+   ARP/ND probe, and the reply resets the corresponding entry age-timer.
+
+
+
+
+Li, et al.                   Standards Track                   [Page 12]
+
+RFC 8302                TRILL ARP/ND Optimization           January 2018
+
+
+9.  Security Considerations
+
+   There are generally two modes of learning the address information
+   that is the basis of ARP/ND optimization: data-plane mode and
+   directory mode.  The data-plane mode is the traditional bridge
+   address learning [IEEE802.1Q] that is also implemented in TRILL
+   switches [RFC6325] and is discussed in Section 9.1.  The directory
+   mode uses data obtained from a directory [RFC8171] and is discussed
+   in Section 9.2.  The TRILL confidence-level feature, which can help
+   arbitrate between conflicting address information, is discussed in
+   Section 9.3.
+
+   RBridges should rate limit ARP/ND queries injected into the TRILL
+   campus to limit some potential denial-of-service attacks.
+
+9.1.  Data-Plane-Based Considerations
+
+   Generally speaking, when ARP/ND optimization is operating in the
+   data-plane mode, the information learned by RBridges is the same as
+   that which is learned by end stations.  Thus, the answers generated
+   by RBridges to the query messages being optimized are generally those
+   that would be generated by end stations in the absence of
+   optimization, and the security considerations are those of the
+   underlying ARP/ND protocols.
+
+   RBridges that snoop on DHCPack messages respond to ARP/ND messages in
+   essentially the same way that the end stations sending those DHCPack
+   messages would.  Thus, for security considerations of ARP/ND
+   optimization for DHCP messages that may be snooped, see the Security
+   Considerations sections of [RFC3315] and [RFC2131].
+
+   Unless SEND [RFC3971] is used, ARP and ND messages can be easily
+   forged.  Therefore, the learning of IP/MAC addresses by RBridges from
+   ARP/ND is hackable, but this is what is available for data-plane
+   learning without SEND.  See "SEND Considerations", Section 4.1.
+
+   Since end stations communicate with edge RBridges using Ethernet,
+   some security improvements could be obtained by the use of
+   [IEEE802.1AE] between end stations and edge RBridges.  Such link
+   security is beyond the scope of this document and would impose
+   requirements on edge stations, while TRILL is generally designed to
+   operate with unmodified, TRILL-ignorant end stations.
+
+
+
+
+
+
+
+
+
+Li, et al.                   Standards Track                   [Page 13]
+
+RFC 8302                TRILL ARP/ND Optimization           January 2018
+
+
+   ARP/ND address mapping information learned locally at an RBridge can
+   be distributed to other RBridges using the TRILL ESADI protocol that
+   can be secured as specified in [RFC7357].  (ESADI is also used for
+   Push Directories with flags in the data indicating whether data comes
+   from a directory or from data-plane learning, as well as from a
+   confidence level (see Section 9.3).)
+
+9.2.  Directory-Based Considerations
+
+   ARP/ND optimization can be based on directory information [RFC8171].
+   If the directory information is known to be trustworthy and complete,
+   then trustworthy responses to ARP/ND queries can be entirely based on
+   this information.  This bounds the damage that forged ARP/ND messages
+   can do to the local link between end stations and edge RBridges.  (In
+   TRILL, such a "link" can be a bridged LAN.)
+
+   Of course, there can also be incomplete and/or unreliable directory
+   address mapping data.  The network administrator can configure their
+   TRILL campus to use such directory data in place of data-plane-
+   learned data.  Alternatively, such directory data can be used along
+   with data-plane-learned data arbitrated by the confidence level as
+   discussed in Section 9.3.
+
+9.3.  Use of the Confidence Level Feature
+
+   An RBridge can use the confidence level in IA APPsub-TLV information
+   received via ESADI or Pull Directory retrievals to determine the
+   configured relative reliability of IP/MAC address mapping information
+   from those sources and from locally learned address information.
+   Push Directory information is sent via ESADI, which can be secured as
+   provided in [RFC7357]; Pull Directory information can be secured as
+   provided in [RFC8171].  The implementation decides if an RBridge will
+   distribute the IP and MAC address mappings received from local native
+   ARP/ND messages to other RBridges in the same Data Label, and with
+   what confidence level it does so.  Thus, the implementer can, to some
+   extent, cause sources that they know are more reliable to dominate
+   those they know to be less reliable.  How the implementer determines
+   this is beyond the scope of this document.
+
+10.  IANA Considerations
+
+   This document does not require any IANA actions.
+
+
+
+
+
+
+
+
+
+Li, et al.                   Standards Track                   [Page 14]
+
+RFC 8302                TRILL ARP/ND Optimization           January 2018
+
+
+11.  References
+
+11.1.  Normative References
+
+   [RFC826]   Plummer, D., "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>.
+
+   [RFC903]   Finlayson, R., Mann, T., Mogul, J., and M. Theimer, "A
+              Reverse Address Resolution Protocol", STD 38, RFC 903,
+              DOI 10.17487/RFC0903, June 1984,
+              <https://www.rfc-editor.org/info/rfc903>.
+
+   [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>.
+
+   [RFC2131]  Droms, R., "Dynamic Host Configuration Protocol",
+              RFC 2131, DOI 10.17487/RFC2131, March 1997,
+              <https://www.rfc-editor.org/info/rfc2131>.
+
+   [RFC3315]  Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins,
+              C., and M. Carney, "Dynamic Host Configuration Protocol
+              for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July
+              2003, <https://www.rfc-editor.org/info/rfc3315>.
+
+   [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>.
+
+   [RFC4862]  Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
+              Address Autoconfiguration", RFC 4862,
+              DOI 10.17487/RFC4862, September 2007,
+              <https://www.rfc-editor.org/info/rfc4862>.
+
+   [RFC6325]  Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A.
+              Ghanwani, "Routing Bridges (RBridges): Base Protocol
+              Specification", RFC 6325, DOI 10.17487/RFC6325, July 2011,
+              <https://www.rfc-editor.org/info/rfc6325>.
+
+
+
+
+
+
+
+
+Li, et al.                   Standards Track                   [Page 15]
+
+RFC 8302                TRILL ARP/ND Optimization           January 2018
+
+
+   [RFC7172]  Eastlake 3rd, D., Zhang, M., Agarwal, P., Perlman, R., and
+              D. Dutt, "Transparent Interconnection of Lots of Links
+              (TRILL): Fine-Grained Labeling", RFC 7172,
+              DOI 10.17487/RFC7172, May 2014,
+              <https://www.rfc-editor.org/info/rfc7172>.
+
+   [RFC7357]  Zhai, H., Hu, F., Perlman, R., Eastlake 3rd, D., and O.
+              Stokes, "Transparent Interconnection of Lots of Links
+              (TRILL): End Station Address Distribution Information
+              (ESADI) Protocol", RFC 7357, DOI 10.17487/RFC7357,
+              September 2014, <https://www.rfc-editor.org/info/rfc7357>.
+
+   [RFC7780]  Eastlake 3rd, D., Zhang, M., Perlman, R., Banerjee, A.,
+              Ghanwani, A., and S. Gupta, "Transparent Interconnection
+              of Lots of Links (TRILL): Clarifications, Corrections, and
+              Updates", RFC 7780, DOI 10.17487/RFC7780, February 2016,
+              <https://www.rfc-editor.org/info/rfc7780>.
+
+   [RFC7961]  Eastlake 3rd, D. and L. Yizhou, "Transparent
+              Interconnection of Lots of Links (TRILL): Interface
+              Addresses APPsub-TLV", RFC 7961, DOI 10.17487/RFC7961,
+              August 2016, <https://www.rfc-editor.org/info/rfc7961>.
+
+   [RFC8171]  Eastlake 3rd, D., Dunbar, L., Perlman, R., and Y. Li,
+              "Transparent Interconnection of Lots of Links (TRILL):
+              Edge Directory Assistance Mechanisms", RFC 8171,
+              DOI 10.17487/RFC8171, June 2017,
+              <https://www.rfc-editor.org/info/rfc8171>.
+
+   [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>.
+
+11.2.  Informative References
+
+   [IEEE802.1AE]
+              IEEE, "IEEE Standard for Local and metropolitan area
+              networks: Media Access Control (MAC) Security", IEEE
+              Std 802.1AE.
+
+   [IEEE802.1Q]
+              IEEE, "IEEE Standard for Local and metropolitan area
+              networks -- Bridges and Bridged Networks", IEEE
+              Std 802.1Q.
+
+
+
+
+
+
+
+Li, et al.                   Standards Track                   [Page 16]
+
+RFC 8302                TRILL ARP/ND Optimization           January 2018
+
+
+   [RFC3756]  Nikander, P., Ed., Kempf, J., and E. Nordmark, "IPv6
+              Neighbor Discovery (ND) Trust Models and Threats",
+              RFC 3756, DOI 10.17487/RFC3756, May 2004,
+              <https://www.rfc-editor.org/info/rfc3756>.
+
+   [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>.
+
+   [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>.
+
+   [RFC6823]  Ginsberg, L., Previdi, S., and M. Shand, "Advertising
+              Generic Information in IS-IS", RFC 6823,
+              DOI 10.17487/RFC6823, December 2012,
+              <https://www.rfc-editor.org/info/rfc6823>.
+
+   [RFC7042]  Eastlake 3rd, D. and J. Abley, "IANA Considerations and
+              IETF Protocol and Documentation Usage for IEEE 802
+              Parameters", BCP 141, RFC 7042, DOI 10.17487/RFC7042,
+              October 2013, <https://www.rfc-editor.org/info/rfc7042>.
+
+   [RFC7067]  Dunbar, L., Eastlake 3rd, D., Perlman, R., and I.
+              Gashinsky, "Directory Assistance Problem and High-Level
+              Design Proposal", RFC 7067, DOI 10.17487/RFC7067, November
+              2013, <https://www.rfc-editor.org/info/rfc7067>.
+
+Acknowledgments
+
+   The authors would like to thank Igor Gashinsky and Sue Hares for
+   their contributions.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Li, et al.                   Standards Track                   [Page 17]
+
+RFC 8302                TRILL ARP/ND Optimization           January 2018
+
+
+Authors' Addresses
+
+   Yizhou Li
+   Huawei Technologies
+   101 Software Avenue,
+   Nanjing  210012
+   China
+   Phone: +86-25-56625375
+   Email: liyizhou@huawei.com
+
+
+   Donald Eastlake 3rd
+   Huawei R&D USA
+   155 Beaver Street
+   Milford, MA  01757
+   United States of America
+   Phone: +1-508-333-2270
+   Email: d3e3e3@gmail.com
+
+
+   Linda Dunbar
+   Huawei Technologies
+   5430 Legacy Drive, Suite #175
+   Plano, TX  75024
+   United States of America
+   Phone: +1-469-277-5840
+   Email: ldunbar@huawei.com
+
+
+   Radia Perlman
+   Dell EMC
+   176 South Street
+   Hopkinton, MA  01748
+   United States of America
+   Email: Radia@alum.mit.edu
+
+
+   Mohammed Umair
+   Cisco
+   Cessna Business Park, Kadubeesanahalli Village, Hobli,
+   Sarjapur, Varthur Main Road, Marathahalli,
+   Bengaluru, Karnataka  560087
+   India
+   Email: mohammed.umair2@gmail.com
+
+
+
+
+
+
+
+Li, et al.                   Standards Track                   [Page 18]
+