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
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
大量链路的透明互连（TRILL）：ARP和邻居发现（ND）优化
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.
本文档描述了在多链路透明互连（TRILL）校园中优化地址解析协议（ARP）和邻居发现（ND）流量的机制。TRILL交换机维护IP/媒体访问控制（MAC）地址/数据标签绑定的缓存，这些绑定是从通过它们的ARP/ND请求和响应中学习的。在许多情况下，此缓存允许边缘路由桥（RBridge）通过直接响应ARP/ND请求或封装并单播ARP/ND请求来避免泛洪。这样的优化减少了TRILL校园中的数据包泛滥。
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.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 7841第2节。
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.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问https://www.rfc-editor.org/info/rfc8302.
Copyright Notice
版权公告
Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2018 IETF信托基金和确定为文件作者的人员。版权所有。
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.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(https://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
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 . . . . . . . . . . . . . . . . . . . . . . . . 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
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.
ARP[RFC826]和ND[RFC4861]消息通常分别通过广播和多播发送。为了减少这些多目的地消息对TRILL校园造成的负担，当入口RBridge知道目标位置或可以从目录获得目标位置时，RBridge可以实现如本文所述的“优化ARP/ND响应”。这避免了ARP/ND查询和应答泛滥。
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.
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”在所有大写字母出现时（如图所示）应按照BCP 14[RFC2119][RFC8174]所述进行解释。
The abbreviations and terminology in [RFC6325] are used herein. Some of these are listed below for convenience along with some additions:
此处使用[RFC6325]中的缩写和术语。为了方便起见，下面列出了其中一些内容以及一些补充内容：
APPsub-TLV Application sub-Type-Length-Value [RFC6823]
APPsub TLV应用子类型长度值[RFC6823]
ARP Address Resolution Protocol [RFC826]
ARP地址解析协议[RFC826]
Campus A TRILL network consisting of RBridges, links, and possibly bridges bounded by end stations and IP routers [RFC6325]
校园一个TRILL网络，由RBridge、链路和可能由终端站和IP路由器连接的网桥组成[RFC6325]
DAD Duplicate Address Detection [RFC3756] [RFC5227]
DAD重复地址检测[RFC3756][RFC5227]
Data Label VLAN or Fine-Grained Label (FGL)
数据标签VLAN或细粒度标签（FGL）
DHCP Dynamic Host Configuration Protocol. In this document, DHCP refers to both DHCP for IPv4 [RFC2131] and DHCPv6 [RFC3315]
DHCP动态主机配置协议。在本文档中，DHCP同时指IPv4的DHCP[RFC2131]和DHCPv6[RFC3315]
ESADI End Station Address Distribution Information [RFC7357]
ESADI端站地址分布信息[RFC7357]
FGL Fine-Grained Label [RFC7172]
FGL细粒度标签[RFC7172]
IA Interface Address; a TRILL APPsub-TLV [RFC7961]
IA接口地址；颤音APPsub TLV[RFC7961]
IP Internet Protocol, both IPv4 and IPv6
IP Internet协议，IPv4和IPv6
MAC Media Access Control [RFC7042]
MAC媒体访问控制[RFC7042]
ND Neighbor Discovery [RFC4861]
第二邻居发现[RFC4861]
RBridge A contraction of "Routing Bridge". A device implementing the TRILL protocol.
RBridge是“路由桥”的缩写。实现TRILL协议的设备。
SEND Secure Neighbor Discovery [RFC3971]
发送安全邻居发现[RFC3971]
TRILL Transparent Interconnection of Lots of Links or Tunneled Routing in the Link Layer [RFC6325] [RFC7780]
大量链路的TRILL透明互连或链路层中的隧道路由[RFC6325][RFC7780]
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.
正如[RFC6820]中所讨论的，IP地址解析会由于数据包被淹没而在数据中心产生重大问题。如本文件，特别是第4节所述，可通过边缘RBridge上的代理ARP/ND功能避免此类洪泛。本节是对该问题的一般性讨论，并非规范性讨论。
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).
为了支持这种ARP/ND优化，边缘RBridge需要通过手动配置（管理）、控制平面机制（如目录[RFC8171]）或通过窥探ARP/ND等消息（包括DHCP或免费ARP消息）的数据平面学习来了解终端站的IP/MAC地址映射。
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.
当所有终端站的IP/MAC地址映射为边缘RBridges所知、通过管理提供或通过边缘RBridges上的控制平面学习时，应该可以完全抑制TRILL校园中ARP/ND消息的泛滥。当所有端站MAC地址类似地已知时，应该可以通过丢弃在边缘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.
ARP/ND优化机制应包括边缘RBridge向连接的终端站发出ARP/ND请求以确认或更新信息的规定，并应允许终端站检测其IP地址的重复。
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
大多数终端站主机在联机后立即向网络发送请求IP地址的DHCP消息或免费的ARP或反向地址解析协议（RARP）请求，以通知自己。因此，本地边缘RBridge将立即有机会窥探和了解其MAC和IP地址，并通过TRILL控制平面端站地址分配信息（ESADI）[RFC7357]协议将该信息分配给其他边缘RBridge。一旦远程RBridge通过控制平面接收到该信息，它们应该将IP到MAC映射信息以及地址信息的昵称和数据标签添加到ARP/ND缓存中。因此，TRILL中最活跃的IP主机
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.
边缘RBridges可以通过局部学习或基于控制平面的远程学习来学习网络。因此，ARP抑制可以大大减少主机ARP学习行为导致的网络洪泛。
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]).
当完整的目录信息可用时，终端站MAC地址的默认数据平面学习不仅是不必要的，而且如果存在基于伪造源地址的帧的学习，则可能是有害的。这种数据平面学习可以被抑制，因为TRILL已经提供了一个选项来禁用从端站帧的源MAC地址进行的数据平面学习（参见[RFC6325]第5.3节）。
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.
默认情况下，RBridge[RFC6325][RFC7172]学习其接收和解除封装的TRILL数据帧的MAC地址和数据标签（VLAN或FGL）的出口昵称映射信息。没有IP地址信息直接从TRILL数据帧中学习。IA APPsub TLV[RFC7961]通过允许任何RBridge在控制平面中分布IP/MAC地址映射，增强了TRILL基本协议。此APPsub TLV出现在ESADI[RFC7357]中的TRILL GENINFO TLV中，但它指定的值数据结构也可能出现在其他应用程序上下文中。Edge RBridge目录辅助机制[RFC8171]将此APPsub TLV用于其推送模型，并使用其在拉送模型中指定的值数据结构。
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].
通过接收ARP[RFC826]或ND[RFC4861]消息，RBridge可以很容易地知道通过其接入端口连接到的本地终端站的IP/MAC地址映射。如果边缘RBridge从接收到的数据帧（ARP或ND）中提取了发送方的IP/MAC地址对，它可以保存信息，然后使用IA APPsub TLV链接IP和MAC地址，并通过ESADI将其分发给其他RBridge。然后，相关的远程RBridge（通常是那些对原始ARP/ND消息的相同数据标签感兴趣的远程RBridge）也接收并保存此类映射信息。RBridges还可以通过其他方式提前保存IP/MAC地址映射，例如，从管理系统导入并通过目录服务器分发它们[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
上面给出的示例表明，RBridges可能在终端站发送或接收任何实际数据包之前，为给定的数据标签（VLAN或FGL）保存了终端站的{IP地址、MAC地址、入口昵称}三元组。请注意，此类信息可能是也可能不是一个完整的列表，可能存在也可能不存在于所有RBridge上；这些信息可能来自不同的来源。RBridges然后可以使用IA APPsub TLV中的Flags字段来识别
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.
如果源是目录服务器或发送方的本地观察。还可以使用不同的置信水平来指示映射信息的可靠性。
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.
作为ARP[RFC826]消息的本机帧由其以太网类型0x0806检测。通过作为五种不同的ICMPv6数据包类型之一来检测ND[RFC4861]的本机帧。ARP/ND通常用于以下链接：（1）查询与IPv4或IPv6地址对应的MAC地址，（2）测试IPv4/IPv6地址是否已在使用，或（3）宣布以下任何一项的新信息或更新信息：IPv4/IPv6地址、MAC地址和/或连接点。
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.
1. IP地址——指示的协议地址，通常是ARP中的IPv4地址或ND中的IPv6地址。
2. sender's IP/MAC address -- sender IP/MAC address in ARP, source IP address, and source link-layer address in ND.
2. 发送方的IP/MAC地址——ARP中的发送方IP/MAC地址、ND中的源IP地址和源链路层地址。
3. target's IP/MAC address -- target IP/MAC address in ARP, target address, and target link-layer address in ND.
3. 目标IP/MAC地址——ARP中的目标IP/MAC地址、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.
当入口RBridge接收到ARP/ND/SEND消息时，它可以执行下面小节中描述的步骤。特别是，第4.4节描述了此类入口处理ARP/ND消息的选项，在转发消息的情况下，第4.5节描述了如何处理由于转发消息而返回的任何响应。
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.
第4.3节描述了RBridge从其处理的ARP/ND消息中提取地址信息。在某些情况下，此提取可能会提示与终端站进行验证。第4.2节描述了RBridges发起的ARP/ND消息的可选使用，以验证地址或活跃度。
As described in Section 4.1, SEND messages are not optimized by the mechanisms specified in this document but are snooped on.
如第4.1节所述，发送消息未通过本文档中指定的机制进行优化，而是被监听。
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.
安全邻居发现（SEND）[RFC3971]是一种保护ND的方法，可解决[RFC3756]中讨论的威胁。典型的TRILL校园位于数据中心、互联网交换点或运营商设施内。这些通常是受控制和保护的环境，这些威胁不太受关注。然而，SEND提供了额外的保护层。
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.
安全发送消息需要了解加密密钥。将此类密钥传送给RBridge以用于发送的方法超出了本文档的范围。因此，使用本文中的优化，RBridge不会尝试构造发送消息，并且通常对它们是透明的。RBridges仅根据需要构造ARP、RARP或不安全的ND消息。然而，实现ARP/ND优化的RBridges应该监听发送消息，以提取在发送消息作为不安全的ND消息发送并且仍然存在于发送消息中时将出现的寻址信息。
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.
RBridges可使用ARP/ND探测直接连接或远程终端站，以进行地址或活动性验证。这通常最适合于管理较少和/或移动性较高的环境。在强管理的环境中，例如典型的数据中心，其中中央编排/目录系统具有完整的寻址知识[RFC7067]，优化的ARP/ND响应可以使用这些知识。在这种情况下，除了调试操作问题或类似问题外，几乎没有理由进行验证。
4.3. Extracting Local Mapping Information for End-Station IP/MAC Addresses
4.3. 提取终端站IP/MAC地址的本地映射信息
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.
Edge RBridges从这些终端站发送的ARP/ND消息中提取并使用有关本地终端站IP和MAC地址之间对应关系的信息，如下所述。明显的零源IP地址意味着终端站正在探测重复的IP地址，并且具有这种零源IP地址的消息不用于提取IP/MAC地址映射信息。
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 如果入口RBridge的ARP/ND缓存中不存在发送方的IP，请在其ARP/ND缓存表中填充发送方的IP/MAC地址映射信息。入口RBridge将其昵称与IP/MAC地址映射信息关联起来。如下文所述，这种{IP地址、MAC地址、入口昵称}信息的三元组保存在本地，并且可以分发到其他rbridge。
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.
o 否则，如果发送方的IP之前已保存，但映射了不同的MAC地址或与同一对IP/MAC关联的不同入口昵称，则RBridge应验证重复的IP地址是否已被使用，或终端站是否已更改其连接的RBridge。RBridge可能会使用不同的策略来实现这一点。例如，RBridge可能会询问权威实体，如目录服务器，或者它可能会将ARP/ND消息封装并单播到它认为地址正在使用的位置（第4.2节）。RBridge应根据验证结果更新保存的{IP地址、MAC地址、入口昵称}三元组。如果网络管理器的策略是让网络对每个数据标签进行操作，就好像它是单个链路一样，并且只相信它接收到的ARP/ND，则RBridge可能不会验证IP地址。
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].
入口RBridge可以使用在ESADI[RFC7357]中设置了本地标志的IA APPsub TLV[RFC7961]来分发获得的{IP地址、MAC地址、入口昵称}信息的任何新的或更新的三元组。如果使用推送目录服务器，则可以按照[RFC8171]中的规定分发此类信息。
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.
edge RBridge处理本机ARP/ND的选项如下所示。对于查找与IP地址对应的MAC地址的通用ARP/ND请求，如果边缘RBridge知道IP地址和相应的MAC，行为如（a）项所示，否则行为如（b）项所示。第（c）项给出了免费ARP和ND非请求邻居广告（NAs）[RFC4861]的行为。第（d）项涉及地址探测ARP查询的处理。在每个字母项目中，它是一个实施决策，决定在该项目下的任何特定ARP/ND查询中使用哪个编号策略。
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. 如果消息是通用ARP/ND请求，且入口RBridge知道目标的IP地址和相关MAC地址，则入口RBridge必须采取以下一种或多种措施。在发送[RFC3971]的情况下，加密将阻止入口RBridge的本地应答，因为RBridge将无法使用目标的私钥对响应进行签名，并且只有操作a.2或a.5有效。
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、 一,。使用入口RBridge的ARP/ND缓存表中存在的目标MAC地址，直接向查询器发送ARP/ND响应。由于边缘RBridge可能没有IPv6地址，因此此类ND响应的源IP地址必须是目标端站的源IP地址。
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、 二,。将ARP/ND/SEND请求封装到目标的指定RBridge，并让目标的出口RBridge将查询转发给目标。这种行为的优点是对请求的响应具有权威性。如果请求未到达目标，则查询者不会得到响应。
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、 三,。阻止在向同一目标发出请求后一段时间内发生的ARP/ND请求，然后在收到对最近向该目标发出的查询的响应时向查询器作出响应。
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、 四,。基于目录信息[RFC8171]回复查询器，例如从拉目录服务器获得的信息或入口RBridge请求推送到的目录信息。
a.5. Flood the ARP/ND/SEND request as per [RFC6325].
a、 五,。根据[RFC6325]泛洪ARP/ND/SEND请求。
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. 如果消息是通用ARP/ND/SEND请求，并且入口RBridge不知道目标的IP地址，则入口RBridge必须采取以下操作之一。在发送[RFC3971]的情况下，加密将阻止入口RBridge的本地应答，因为RBridge将无法使用目标的私钥对响应进行签名；因此，只有行动b.1是有效的。
b.1. Flood the ARP/ND/SEND message as per [RFC6325].
b、 一,。按照[RFC6325]向ARP/ND/发送消息。
b.2. Use a directory server to pull the information [RFC8171] and reply to the querier.
b、 二,。使用目录服务器获取信息[RFC8171]并回复查询者。
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.
b、 三,。如果没有响应，请删除该消息，因为目录服务器提供了权威信息，表明所查询的地址不存在。
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:
c. 如果消息是免费的ARP，可以通过相同发送方和目标方的“协议”地址字段或ND/SEND中的未经请求的邻居广告[RFC4861]来识别，则：
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.
RBridge可以使用设置了本地标志的IA APPsub TLV[RFC7961]来分发发送方的IP/MAC地址映射信息。当部署一个或多个目录服务器且数据标签中的所有RBridge使用完整的推送目录信息时，应丢弃免费的ARP或未经请求的NA，而不是进入。否则，根据[RFC6325]的规定，它们要么进入并淹没，要么根据当地政策丢弃。
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.
d. 如果消息是地址探测ARP查询[RFC5227]，可通过发送方的协议（IPv4）地址字段为零和目标方的协议地址字段为待测试的IPv4地址或具有未指定源地址[RFC4862]的重复地址检测邻居请求（DAD）来识别，应将其作为上文（a）或（b）中的通用ARP消息处理。
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
如果入口RBridge R1决定将ARP/ND请求单播到目标的出口RBridge R2，如第4.4节第a.2项所述，或根据第a.5项和[RFC6325]项将请求泛洪，则R2将解除对查询的封装，并在目标链路上发起ARP/ND查询。如果目标有响应，R2会将响应封装并单播给R1，R1会将响应解除封装并发送给查询器。R2应启动链路状态更新，以通知所有其他RBridge目标的位置、第3层地址和位置
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.
第2层地址，除了将回复转发给查询者之外。更新使用IA APPsub TLV[RFC7961]（因此可以链接第3层和第2层地址）和ESADI[RFC7357]中设置的本地标志，或者在使用推送目录服务器时根据[RFC8171]进行。
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.
RARP[RFC903]使用与ARP相同的数据包格式，但使用不同的以太网类型（0x8035）和操作码值。其处理类似于第4.4节a项所述的通用ARP请求/响应。和b。不同之处在于，它旨在查询与所提供的目标“硬件”（MAC）地址相对应的目标“协议”（IP）地址。它应该通过在提供的目标“硬件”地址上执行本地缓存或目录服务器查找来处理，以查找到所需“协议”地址的映射。
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.
当新连接的终端站与DHCP[RFC3315][RFC2131]服务器交换消息时，边缘RBridge应该监听它们（主要是DHCPAck消息），并将IP/MAC地址映射信息存储在其ARP/ND缓存中，还应该使用ESADI通过TRILL控制平面发送信息。
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.
由于攻击者发送虚假ARP/ND消息或由于人为/配置错误，数据标签中可能会出现重复的IP地址。如果完整、可靠的目录信息可用，则根据定义，目录中的IP位置信息是正确的。IP地址出现在与其他来源不同的位置（不同的边缘或端口）是不正确的。
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.
如果没有完整的目录信息，ARP/ND优化功能应该支持重复IP检测。在数据中心中，这对于阻止攻击者使用ARP/ND欺骗从其预期目的地转移流量至关重要。
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
当修改现有的活动IP/MAC地址映射时，可以检测到重复的IP地址。此外，边缘RBridge可以通过使用先前与该IP地址相关联的MAC地址，向该IP地址的前所有者发送称为重复地址检测查询（DAD查询）的查询，该查询询问所述IP地址。DAD查询是一条单播ARP/ND消息，ARP为发送方IP 0.0.0.0（或每个RBridge的可配置IP地址称为DAD查询源IP），ND为IPv6链路本地地址，源MAC设置为DAD查询者RBridge的MAC。如果查询RBridge在给定时间内未收到答复
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.
时间，它可能是一种流动的情况；在任何情况下，新的IP条目都将在其ARP/ND缓存中被确认和激活。
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.
在前所有者答复的情况下，检测到重复的地址。在这种情况下，查询RBridge应该记录副本，以便网络管理员可以采取适当的操作。
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.
当目录或配置中没有权威信息时，如何响应网络中重复的地址查询是一种实现选择。通常，返回最近窥探的信息。
A maintenance procedure is needed for RBridge ARP/ND caching to ensure IP end stations connected to ingress RBridges are still active.
RBridge ARP/ND缓存需要一个维护程序，以确保连接到入口RBridge的IP端站仍然处于活动状态。
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.
某些链接提供链接活跃度的物理层指示。如果动态代理ARP/ND条目（从数据平面观察中学习的条目）在其上学习的链接失败，则必须从表中删除该条目。
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].
类似地，如果IP/MAC地址映射在给定时间内未刷新，则应将动态代理ARP/ND条目从表中清除。如果从任何位置接收到同一IP/MAC地址映射项的ARP或ND消息，则会刷新该项。IP/MAC地址映射信息老化计时器可根据RBridge配置，默认为MAC地址学习老化计时器的3/4[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.
例如，终端站“A”连接到edge-RBridge1（RB1），并已作为RB1上的本地条目被读入。如果终端站“A”移动到其他位置（MAC/虚拟机（VM）移动性）并连接到边缘RBridge（RB2），在RB2的访问端口上学习后，RB2通过颤音控制平面播发该条目，并在RB1上作为远程条目学习。RB1上的旧条目应被替换，所有其他为该数据标签启用终端站服务的边缘RBridge应更新该条目，以显示RB2而不是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.
如果缓存中的ARP/ND条目未刷新，则连接到该终端站的RBridge可以向该终端站发送定期刷新消息（ARP/ND“探测”），以便在条目过期之前可以刷新。终端站将回复ARP/ND探测器，回复将重置相应的进入时间计时器。
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.
通常有两种模式学习地址信息，这是ARP/ND优化的基础：数据平面模式和目录模式。数据平面模式是传统的网桥地址学习[IEEE802.1Q]，也在TRILL交换机[RFC6325]中实现，并在第9.1节中讨论。目录模式使用从目录[RFC8171]获得的数据，并在第9.2节中讨论。第9.3节讨论了TRILL置信水平功能，它可以帮助在冲突的地址信息之间进行仲裁。
RBridges should rate limit ARP/ND queries injected into the TRILL campus to limit some potential denial-of-service attacks.
RBridges应该对注入TRILL校园的ARP/ND查询进行速率限制，以限制一些潜在的拒绝服务攻击。
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.
一般来说，当ARP/ND优化在数据平面模式下运行时，RBridges学习到的信息与终端站学习到的信息相同。因此，由rbridge生成的对正在优化的查询消息的应答通常是在没有优化的情况下由终端站生成的应答，并且安全考虑是底层ARP/ND协议的应答。
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].
窥探DHCPack消息的RBridge对ARP/ND消息的响应方式与发送这些DHCPack消息的终端站的响应方式基本相同。因此，有关可能被窥探的DHCP消息的ARP/ND优化的安全注意事项，请参阅[RFC3315]和[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.
除非使用发送[RFC3971]，否则ARP和ND消息很容易伪造。因此，RBridges从ARP/ND中学习IP/MAC地址是可以破解的，但这是无需发送即可用于数据平面学习的。参见第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.
由于终端站使用以太网与边缘RBridge通信，因此通过在终端站和边缘RBridge之间使用[IEEE802.1AE]可以获得一些安全改进。这种链路安全性超出了本文件的范围，并将对边缘站提出要求，而TRILL通常设计用于未经修改的、不含TRILL的终端站。
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).)
在RBridge本地学习的ARP/ND地址映射信息可以使用TRILL ESADI协议分发给其他RBridge，该协议可以按照[RFC7357]中的规定进行保护。（ESADI还用于数据中带有标志的推送目录，标志指示数据是来自目录还是来自数据平面学习，以及来自置信水平（见第9.3节）。）
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.)
ARP/ND优化可以基于目录信息[RFC8171]。如果已知目录信息是可信和完整的，那么ARP/ND查询的可信响应可以完全基于此信息。这限制了伪造ARP/ND消息对终端站和边缘RBridge之间的本地链路造成的损害。（在TRILL中，这种“链路”可以是桥接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.
当然，也可能存在不完整和/或不可靠的目录地址映射数据。网络管理员可以配置TRILL校园，以使用此类目录数据代替数据平面学习数据。或者，此类目录数据可与第9.3节中讨论的置信水平仲裁的数据平面学习数据一起使用。
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.
RBridge可以使用通过ESADI或Pull目录检索接收的IA APPsub TLV信息中的置信度来确定来自这些源和本地学习的地址信息的IP/MAC地址映射信息的配置相对可靠性。推送目录信息通过ESADI发送，可按照[RFC7357]中的规定进行安全保护；拉目录信息可以按照[RFC8171]中的规定进行保护。该实现决定RBridge是否将从本地ARP/ND消息接收的IP和MAC地址映射分发到同一数据标签中的其他RBridge，以及它这样做的置信度。因此，在某种程度上，实现者可以使他们知道的更可靠的源控制他们知道的不可靠的源。实施者如何确定这一点超出了本文档的范围。
This document does not require any IANA actions.
本文件不要求IANA采取任何行动。
[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>.
[RFC826]Plummer，D.，“以太网地址解析协议：或将网络协议地址转换为48位以太网地址以便在以太网硬件上传输”，STD 37，RFC 826，DOI 10.17487/RFC0826，1982年11月<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>.
[RFC903]Finlayson，R.，Mann，T.，Mogul，J.，和M.Theimer，“反向地址解析协议”，STD 38，RFC 903，DOI 10.17487/RFC0903，1984年6月<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>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<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>.
[RFC2131]Droms，R.，“动态主机配置协议”，RFC 2131，DOI 10.17487/RFC2131，1997年3月<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>.
[RFC3315]Droms，R.，Ed.，Bound，J.，Volz，B.，Lemon，T.，Perkins，C.，和M.Carney，“IPv6的动态主机配置协议（DHCPv6）”，RFC 3315，DOI 10.17487/RFC3315，2003年7月<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>.
[RFC4861]Narten，T.，Nordmark，E.，Simpson，W.，和H.Soliman，“IP版本6（IPv6）的邻居发现”，RFC 4861，DOI 10.17487/RFC48612007年9月<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>.
[RFC4862]Thomson，S.，Narten，T.和T.Jinmei，“IPv6无状态地址自动配置”，RFC 4862，DOI 10.17487/RFC4862，2007年9月<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>.
[RFC6325]Perlman，R.，Eastlake 3rd，D.，Dutt，D.，Gai，S.，和A.Ghanwani，“路由桥（RBridges）：基本协议规范”，RFC 6325DOI 10.17487/RFC6325，2011年7月<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>.
[RFC7172]Eastlake 3rd，D.，Zhang，M.，Agarwal，P.，Perlman，R.，和D.Dutt，“大量链接的透明互连（TRILL）：细粒度标记”，RFC 7172，DOI 10.17487/RFC7172，2014年5月<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>.
[RFC7357]翟，H.，胡，F.，帕尔曼，R.，东湖3号，D.，和O.斯托克斯，“大量链路的透明互连（TRILL）：端站地址分配信息（ESADI）协议”，RFC 7357，DOI 10.17487/RFC7357，2014年9月<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>.
[RFC7780]Eastlake 3rd，D.，Zhang，M.，Perlman，R.，Banerjee，A.，Ghanwani，A.，和S.Gupta，“大量链接的透明互连（TRILL）：澄清，更正和更新”，RFC 7780，DOI 10.17487/RFC77802016年2月<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>.
[RFC7961]Eastlake 3rd，D.和L.Yizhou，“大量链路的透明互连（TRILL）：接口地址APPsub TLV”，RFC 7961，DOI 10.17487/RFC7961，2016年8月<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>.
[RFC8171]Eastlake 3rd，D.，Dunbar，L.，Perlman，R.，和Y.Li，“大量链接的透明互连（TRILL）：边缘目录协助机制”，RFC 8171，DOI 10.17487/RFC8171，2017年6月<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>.
[RFC8174]Leiba，B.，“RFC 2119关键词中大写与小写的歧义”，BCP 14，RFC 8174，DOI 10.17487/RFC8174，2017年5月<https://www.rfc-editor.org/info/rfc8174>.
[IEEE802.1AE] IEEE, "IEEE Standard for Local and metropolitan area networks: Media Access Control (MAC) Security", IEEE Std 802.1AE.
[IEEE802.1AE]IEEE，“局域网和城域网的IEEE标准：媒体访问控制（MAC）安全”，IEEE标准802.1AE。
[IEEE802.1Q] IEEE, "IEEE Standard for Local and metropolitan area networks -- Bridges and Bridged Networks", IEEE Std 802.1Q.
[IEEE802.1Q]IEEE，“局域网和城域网的IEEE标准——网桥和桥接网络”，IEEE标准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>.
[RFC3756]Nikander，P.，Ed.，Kempf，J.和E.Nordmark，“IPv6邻居发现（ND）信任模型和威胁”，RFC 3756，DOI 10.17487/RFC3756，2004年5月<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>.
[RFC3971]Arkko，J.，Ed.，Kempf，J.，Zill，B.，和P.Nikander，“安全邻居发现（SEND）”，RFC 3971，DOI 10.17487/RFC3971，2005年3月<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>.
[RFC5227]南柴郡，“IPv4地址冲突检测”，RFC 5227，DOI 10.17487/RFC5227，2008年7月<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>.
[RFC6820]Narten，T.，Karir，M.，和I.Foo，“解决大型数据中心网络中的解决方案问题”，RFC 6820，DOI 10.17487/RFC6820，2013年1月<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>.
[RFC6823]Ginsberg，L.，Previdi，S.，和M.Shand，“IS-IS中的广告通用信息”，RFC 6823，DOI 10.17487/RFC6823，2012年12月<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>.
[RFC7042]Eastlake 3rd，D.和J.Abley，“IEEE802参数的IANA考虑因素和IETF协议及文档使用”，BCP 141，RFC 7042，DOI 10.17487/RFC7042，2013年10月<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>.
[RFC7067]Dunbar，L.，Eastlake 3rd，D.，Perlman，R.，和I.Gashinsky，“目录协助问题和高层设计方案”，RFC 7067，DOI 10.17487/RFC7067，2013年11月<https://www.rfc-editor.org/info/rfc7067>.
Acknowledgments
致谢
The authors would like to thank Igor Gashinsky and Sue Hares for their contributions.
作者要感谢Igor Gashinsky和Sue Hares的贡献。
Authors' Addresses
作者地址
Yizhou Li Huawei Technologies 101 Software Avenue, Nanjing 210012 China Phone: +86-25-56625375 Email: liyizhou@huawei.com
宜州利华为技术有限公司南京软件大道101号210012中国电话：+86-25-56625375电子邮件：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
Donald Eastlake 3rd华为研发美国马萨诸塞州米尔福德海狸街155号01757美国电话：+1-508-333-2270电子邮件：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
Linda Dunbar Huawei Technologies 5430 Legacy Drive，德克萨斯州普莱诺175号套房75024美国电话：+1-469-277-5840电子邮件：ldunbar@huawei.com
Radia Perlman Dell EMC 176 South Street Hopkinton, MA 01748 United States of America Email: Radia@alum.mit.edu
Radia Perlman Dell EMC 176 South Street Hopkinton，马萨诸塞州01748美利坚合众国电子邮件：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
Mohammed Umair Cisco Cessna商业园，Kadubeesanahalli村，霍布利，萨尔贾普尔，瓦尔图尔大道，马拉塔哈利，卡纳塔克邦班加罗尔560087印度电子邮件：Mohammed。umair2@gmail.com