RFC 8302

Transparent Interconnection of Lots of Links (TRILL): ARP and Neighbor Discovery (ND) Optimization

📅 published January 2018, from ietf

Okay bestie, the title block is giving a whole team lineup 🎀. The authors are Y. Li, D. Eastlake 3rd, and L. Dunbar from Huawei Technologies, R. Perlman from Dell EMC, and M. Umair from Cisco. It's a Standards Track doc, published in January 2018, with ISSN 2070-1721. The title block doesn't list anything it obsoletes or updates, so it's a standalone glow-up ✨.

Abstract 🦋

Okay so this doc is all about making ARP and Neighbor Discovery traffic way less extra inside a TRILL campus 🌸. TRILL switches keep a cache of IP / MAC address / Data Label bindings that they learn from the ARP/ND requests and responses zooming through them. In lots of cases, that cache lets an edge Routing Bridge (RBridge) skip flooding an ARP/ND request, either by answering it directly or by encapsulating it and unicasting it. Less flooding across the whole campus, iconic behavior 💅.

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.

Info about the current status of this doc, any errata, and how to send feedback is at https://www.rfc-editor.org/info/rfc8302.

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, because 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 they 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

1. Introduction ✨

ARP [RFC826] and ND [RFC4861] messages are normally sent by broadcast and multicast, respectively. To ease the load on a TRILL campus from 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 here. Some of them are listed below for convenience, along with a few 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]
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 serious issues in data centers because of flooded packets, as discussed in [RFC6820]. That 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 the problem and is not intended to be normative 🧠.

To support this ARP/ND optimization, edge RBridges need to know an end station's IP/MAC address mapping. They can get it through manual configuration (management), control-plane mechanisms such as directories [RFC8171], or data-plane learning by snooping messages such as ARP/ND (including DHCP or gratuitous ARP messages).

When all of the end station IP/MAC address mappings are known to edge RBridges, whether provisioned through management or learned via the control plane, 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 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. So the local edge RBridge will immediately have the chance to snoop and learn their MAC and IP addresses, and distribute this info 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 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. That 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] upgrades 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 learn the IP/MAC address mappings of the local end stations 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 them 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 that mapping information. There are other ways RBridges can save IP/MAC address mappings in advance, e.g., importing them from the management system and distributing them by directory servers [RFC8171] 💌.

The examples 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 this information might or might not be a complete list, and might or might not exist on all RBridges. The information could possibly come from different sources. RBridges can then use the Flags field in an IA APPsub-TLV to identify whether 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 ✨

okay so bestie, a native frame is an ARP [RFC826] message if its Ethertype is 0x0806 🫶. A native frame is an ND [RFC4861] if it's one of five different ICMPv6 packet types 🦋. ARP/ND is mostly used on a link to (1) ask for the MAC address that goes with an IPv4 or IPv6 address, (2) check whether an IPv4/IPv6 address is already taken, or (3) announce new or updated info about any of these: an IPv4/IPv6 address, a MAC address, and/or a point of attachment 💅.

To keep this section from getting messy, we use these terms:

  1. IP address -- the protocol address, which is normally an IPv4 address in ARP or an IPv6 address in ND 🌸.
  2. sender's IP/MAC address -- the sender IP/MAC address in ARP, plus the source IP address and source link-layer address in ND 💜.
  3. target's IP/MAC address -- the target IP/MAC address in ARP, plus the target address and target link-layer address in ND 🎀.

When an ingress RBridge gets an ARP/ND/SEND message, it can do the steps in the subsections below 🌈. Section 4.4 is the one that covers the options for an ingress handling an ARP/ND message, and if it forwards the message, Section 4.5 explains how to handle any response that comes back because of that forwarded message 🧚.

Section 4.3 is about how an RBridge pulls out address information from the ARP/ND messages it handles. Sometimes this extraction might lead to a check with an end station 👀. Section 4.2 is about an optional thing where RBridges send their own ARP/ND messages to verify addresses or liveness ✨.

As Section 4.1 explains, SEND messages are not optimized by the mechanisms in this document, but they get snooped on 🙈.

4.1. SEND Considerations

Secure Neighbor Discovery (SEND) [RFC3971] is a way of securing ND, and it deals with the threats talked about in [RFC3756] 🔐. Typical TRILL campuses live inside data centers, Internet exchange points, or carrier facilities 🏢. These are usually controlled and protected places, so these threats are less of a worry there. Still, SEND adds an extra layer of protection, which is honestly iconic 👑.

Secure SEND messages need cryptographic keys. How to get those keys to RBridges so they can use SEND is outside the scope of this document 🗝️. So when you use the optimizations in this document, RBridges don't try to build SEND messages and are mostly transparent to them. RBridges only build ARP, RARP, or insecure ND messages, depending on what's needed 💖. Even so, RBridges that do ARP/ND optimization SHOULD snoop on SEND messages to pull out the addressing info that would be there 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 to verify an address or liveness 🦋. This is usually the best fit for less-managed and/or higher-mobility environments 🌸. In strongly managed environments, like a typical data center, there's a central orchestration/directory system that has complete addressing knowledge [RFC7067], and optimized ARP/ND responses can use that knowledge 📚. In those cases, there's not much reason to verify, except for debugging operational problems or things like that 🛠️.

4.3. Extracting Local Mapping Information for End-Station IP/MAC Addresses

Edge RBridges take and use info about how local end-station IP and MAC addresses go together, using the ARP/ND messages those end stations send, as explained below 💅. An apparent zero source IP address means the end station is checking for duplicate IP addresses, so messages with a zero source IP address are NOT used to extract IP/MAC address mapping info 🙅‍♀️.

Wait, quick correction, bestie: those words are not in capitals in the spec, so I'm keeping this one in my normal voice. Messages with such a zero source IP address are not used for the extraction of IP/MAC address mapping information 🧁.

  • 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 with that IP/MAC address mapping info ✨. This {IP address, MAC address, ingress nickname} triplet is saved locally and can be distributed to other RBridges, as explained later 🌈.
  • 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 whether a duplicate IP address is already in use or whether an end station has changed its attaching RBridge 😳. The RBridge may use different strategies to do this. 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) 🎯. The RBridge SHOULD update the saved {IP address, MAC address, ingress nickname} triplet 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 any 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 {IP address, MAC address, ingress nickname} triplet it got 🎁. If a Push Directory server is used, that info can be distributed as specified in [RFC8171] 🧚‍♀️.

4.4. Determining How to Reply to ARP/ND

Here are the options for an edge RBridge handling a native ARP/ND 💅. For generic ARP/ND requests asking for the MAC address that goes with an IP address: if the edge RBridge knows the IP address and its corresponding MAC address, the behavior is item (a). Otherwise, the behavior is item (b) 🎀. Behavior for gratuitous ARP and for ND unsolicited Neighbor Advertisements (NAs) [RFC4861] is in item (c) 📢. And item (d) covers handling an Address Probe ARP query 🔎. Inside each lettered item, it's up to the implementation which numbered strategy to use for any particular ARP/ND query 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 stop the ingress RBridge from replying locally, since the RBridge couldn't sign the response with the target's private key 🔑. So only action a.2 or a.5 is valid there 🙅‍♀️.

  • a.1. Send an ARP/ND response directly to the querier, using the target's MAC address that's 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 has the advantage that a response to the request is authoritative ✅. If the request doesn't reach the target, then the querier doesn't get a response 😭.
  • a.3. Block ARP/ND requests that come in 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], like info obtained from a Pull Directory server or directory information that the ingress RBridge has asked to have pushed to it 🗂️.
  • a.5. Flood the ARP/ND/SEND request as per [RFC6325] 🌊.

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 stop a local reply by the ingress RBridge, since the RBridge couldn't 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 doesn't exist 🗑️.

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're 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 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 starts an ARP/ND query on the target's link 🛰️. If and when the target responds, R2 encapsulates and unicasts the response to R1, and R1 decapsulates the response and sends it to the querier 💌. R2 SHOULD start a link state update to tell all the other RBridges where the target is, along with its Layer 3 address and 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 a different Ethertype (0x8035) and opcode values 🦋. Its processing is similar to the generic ARP request/response described in Section 4.4, items a. and b. 💜. The difference is that it's meant to query for the target "protocol" (IP) address that matches 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 🎀

okay so when a newly connected end station chats with a DHCP [RFC3315][RFC2131] server, the edge RBridge should snoop on those messages (mainly the DHCPAck message 👀). It should store the IP/MAC address mapping info in its ARP/ND cache 🗂️, and also send that info out through the TRILL control plane using ESADI 💅.

7. Handling of Duplicate IP Addresses 🙈

duplicate IP addresses inside a Data Label can happen because an attacker is sending fake ARP/ND messages, or because of human or configuration mistakes 💀. if you have complete, trustworthy directory info, then by definition the IP location in the directory is correct. any appearance of that IP in a different place (different edge RBridge or port) from other sources is not correct.

without complete directory info, the ARP/ND optimization function should support duplicate IP detection. this is critical in a data center, because it stops an attacker from using ARP/ND spoofing to divert traffic away 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 address, using the MAC address that was formerly associated with it. a DAD-query is a unicast ARP/ND message with sender IP 0.0.0.0 in the case of ARP (or a configurable IP address per RBridge called the DAD-Query source IP), and an IPv6 Link Local Address in the case of ND, with the source MAC set to the DAD-querier RBridge's MAC. if the querying RBridge doesn't get an answer within a given time, it may be a case of mobility. either way, 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 the network administrator can take appropriate action. 📝

it's an implementation choice how to respond to a query for an address that is duplicated in the network when authoritative info isn't available from a directory or configuration. typically, the info 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 make sure IP end stations connected to ingress RBridges are still active. it's giving housekeeping 🧹.

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. no exceptions, bestie 🙅‍♀️.

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), then 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 🫶.

9. Security Considerations 🔐

okay, this section is the main character of the whole doc, so pay attention 👑. there are generally two modes of learning the address info 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 it's discussed in Section 9.1. the directory mode uses data obtained from a directory [RFC8171], and it's 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 🚫. this is not optional energy, it's protecting the whole campus 💀.

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 what end stations learn. so the answers RBridges generate to the query messages being optimized are generally the ones end stations would generate without 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 the end stations sending those DHCPack messages would. so 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 using [IEEE802.1AE] between end stations and edge RBridges. such link security is beyond the scope of this document, and it would impose requirements on edge stations, while TRILL is generally designed to operate with unmodified, TRILL-ignorant end stations 🫠.

ARP/ND address mapping information learned locally at an RBridge can be distributed to other RBridges using the TRILL ESADI protocol, which 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. no registry drama here, periodt 💅.

11. References 📚

the reference list wasn't included in the text I was given, so I've kept this heading without making up any entries 🙏.

11.1. Normative References

okay so these are the must-read docs the spec leans on, bestie 💖 Everything below is a citation, so I'm keeping it exactly as written 📚

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

[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

these are the extra-credit reads, the background stuff that's nice to know but not required 🌸

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

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

big shoutout from the authors to Igor Gashinsky and Sue Hares for all their contributions 💜

Authors' Addresses 🎀

and here are the people who wrote this whole thing, with their contact details, iykyk 💅

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

and that's the whole RFC, bestie 🌈✨ we did it!

📦 where this page comes from