Internet Engineering Task Force (IETF) L. Dunbar
Request for Comments: 8380 D. Eastlake 3rd
Category: Standards Track Huawei
ISSN: 2070-1721 R. Perlman
Dell/EMC
May 2018
Internet Engineering Task Force (IETF) L. Dunbar
Request for Comments: 8380 D. Eastlake 3rd
Category: Standards Track Huawei
ISSN: 2070-1721 R. Perlman
Dell/EMC
May 2018
Directory-Assisted Transparent Interconnection of Lots of Links (TRILL) Encapsulation
目录辅助的大量链接透明互连（TRILL）封装
Abstract
摘要
This document describes how data center networks can benefit from non-RBridge nodes performing TRILL (Transparent Interconnection of Lots of Links) encapsulation with assistance from a directory service.
本文档描述了数据中心网络如何从非RBridge节点在目录服务的帮助下执行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/rfc8380.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问https://www.rfc-editor.org/info/rfc8380.
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 ....................................................2
2. Conventions Used in This Document ...............................2
3. Directory Assistance to Non-RBridge .............................3
4. Source Nickname in Encapsulation by Non-RBridge Nodes ...........6
5. Benefits of a Non-RBridge Performing TRILL Encapsulation ........6
5.1. Avoid Nickname Exhaustion Issue ............................6
5.2. Reduce MAC Tables for Switches on Bridged LANs .............6
6. Manageability Considerations ....................................7
7. Security Considerations .........................................7
8. IANA Considerations .............................................9
9. References .....................................................9
9.1. Normative References .....................................10
9.2. Informative References ...................................10
Acknowledgments ...................................................10
Authors' Addresses.................................................10
1. Introduction ....................................................2
2. Conventions Used in This Document ...............................2
3. Directory Assistance to Non-RBridge .............................3
4. Source Nickname in Encapsulation by Non-RBridge Nodes ...........6
5. Benefits of a Non-RBridge Performing TRILL Encapsulation ........6
5.1. Avoid Nickname Exhaustion Issue ............................6
5.2. Reduce MAC Tables for Switches on Bridged LANs .............6
6. Manageability Considerations ....................................7
7. Security Considerations .........................................7
8. IANA Considerations .............................................9
9. References .....................................................9
9.1. Normative References .....................................10
9.2. Informative References ...................................10
Acknowledgments ...................................................10
Authors' Addresses.................................................10
This document describes how data center networks can benefit from non-RBridge nodes performing TRILL encapsulation with assistance from a directory service and specifies a method for them to do so.
本文档描述了数据中心网络如何从非RBridge节点在目录服务的帮助下执行TRILL封装中获益，并指定了一种方法。
[RFC7067] and [RFC8171] describe the framework and methods for edge RBridges to get (MAC and VLAN) <-> Edge RBridge mapping from a directory service instead of flooding unknown destination MAC addresses across a TRILL domain. If it has the needed directory information, any node, even a non-RBridge node, can perform the TRILL data packet encapsulation. This document describes the benefits of and a scheme for non-RBridge nodes performing TRILL encapsulation.
[RFC7067]和[RFC8171]描述了边缘RBridge从目录服务获取（MAC和VLAN）<->边缘RBridge映射的框架和方法，而不是在TRILL域中淹没未知的目标MAC地址。如果它具有所需的目录信息，任何节点，甚至非RBridge节点，都可以执行TRILL数据包封装。本文档描述了非RBridge节点执行TRILL封装的优点和方案。
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]所述进行解释。
AF: Appointed Forwarder RBridge port [RFC8139].
AF：指定货代RBRIGE港口[RFC8139]。
Bridge: A device compliant with IEEE 802.1Q. In this document, Bridge is used interchangeably with Layer 2 switch.
网桥：符合IEEE 802.1Q的设备。在本文档中，桥接器可与第2层交换机互换使用。
DA: Destination Address.
DA：目的地地址。
ES-IS: End System to Intermediate System [RFC8171].
ES-IS：终端系统到中间系统[RFC8171]。
Host: A physical server or a virtual machine running applications. A host usually has at least one IP address and at least one MAC address.
主机：运行应用程序的物理服务器或虚拟机。主机通常至少有一个IP地址和一个MAC地址。
IS-IS: Intermediate System to Intermediate System [RFC7176].
IS-IS：中间系统到中间系统[RFC7176]。
SA: Source Address.
SA：源地址。
TRILL-EN: TRILL Encapsulating Node. A node that performs the TRILL encapsulation but doesn't participate in an RBridge's IS-IS routing.
TRILL-EN：TRILL封装节点。执行TRILL封装但不参与RBridge IS-IS路由的节点。
VM: Virtual Machine.
虚拟机：虚拟机。
With directory assistance [RFC7067] [RFC8171], a non-RBridge node can learn if a data packet needs to be forwarded across the RBridge domain and, if so, the corresponding egress RBridge.
通过目录帮助[RFC7067][RFC8171]，非RBridge节点可以了解数据包是否需要跨RBridge域转发，如果需要，还可以了解相应的出口RBridge。
Suppose the RBridge domain boundary starts at network switches (not virtual switches embedded on servers). (See Figure 1 for a high-level diagram of a typical data center network.) A directory can assist virtual switches embedded on servers to encapsulate with a proper TRILL header by providing the nickname of the egress RBridge edge to which the destination is attached. The other information needed to encapsulate can be learned either by listening to TRILL ES-IS and/or IS-IS Hellos [RFC7176] [RFC8171], which will indicate the MAC address and nickname of appropriate local edge RBridges, or by configuration.
假设RBridge域边界始于网络交换机（不是嵌入服务器上的虚拟交换机）。（典型数据中心网络的高级示意图见图1。）通过提供目标所连接的出口RBridge边缘的昵称，目录可以帮助嵌入在服务器上的虚拟交换机使用适当的TRILL头进行封装。封装所需的其他信息可以通过收听TRILL ES-IS和/或IS-IS Hellos[RFC7176][RFC8171]来学习，这将指示适当的本地边缘RBridge的MAC地址和昵称，也可以通过配置来学习。
If it is not known whether a destination is attached to one or more edge RBridges, based on the directory, the non-RBridge node can forward the data frames natively, i.e., not encapsulating with any TRILL header. Or, if the directory is known to be complete, the non-RBridge node can discard such data frames.
如果不知道目的地是否连接到一个或多个边缘RBridge，则基于目录，非RBridge节点可以本地转发数据帧，即，不封装任何TRILL报头。或者，如果已知目录是完整的，则非RBridge节点可以丢弃此类数据帧。
\ +-----------+ +-----------+ /
\ +/----------+ | +/----------+ | TRILL /
\ |Aggregation| | |Aggregation| | Domain /
\ | 11 | + --- | N1 | + /
\ +-----------+/ +-----------+/ /
\ / \ / \ /
\ / \ / \ /
Top- \ +---+ +---+ +---+ +---+ /
of- --> \- |T11|... |T1x| |T21| .. |T2y|---/
Rack +---+ +---+ +---+ +---+
Switches | | | |
+-|-+ +-|-+ +-|-+ +-|-+
| |... | V | | V | .. | V | <- vSwitch
+---+ +---+ +---+ +---+
| |... | V | | V | .. | V |
+---+ +---+ +---+ +---+
| |... | V | | V | .. | V |
+---+ +---+ +---+ +---+
\ +-----------+ +-----------+ /
\ +/----------+ | +/----------+ | TRILL /
\ |Aggregation| | |Aggregation| | Domain /
\ | 11 | + --- | N1 | + /
\ +-----------+/ +-----------+/ /
\ / \ / \ /
\ / \ / \ /
Top- \ +---+ +---+ +---+ +---+ /
of- --> \- |T11|... |T1x| |T21| .. |T2y|---/
Rack +---+ +---+ +---+ +---+
Switches | | | |
+-|-+ +-|-+ +-|-+ +-|-+
| |... | V | | V | .. | V | <- vSwitch
+---+ +---+ +---+ +---+
| |... | V | | V | .. | V |
+---+ +---+ +---+ +---+
| |... | V | | V | .. | V |
+---+ +---+ +---+ +---+
Figure 1: TRILL Domain in a Typical Data Center Network
图1：典型数据中心网络中的TRILL域
When a TRILL-encapsulated data packet reaches the ingress RBridge, that RBridge simply performs the usual TRILL processing and forwards the pre-encapsulated packet to the RBridge that is specified by the egress nickname field of the TRILL header. When an ingress RBridge receives a native Ethernet frame in an environment with complete directory information, the ingress RBridge doesn't flood or forward the received data frames when the destination MAC address in the Ethernet data frames is unknown.
当TRILL封装的数据分组到达入口RBridge时，该RBridge简单地执行通常的TRILL处理，并将预封装的分组转发到由TRILL报头的出口昵称字段指定的RBridge。当入口RBridge在具有完整目录信息的环境中接收到本机以太网帧时，当以太网数据帧中的目标MAC地址未知时，入口RBridge不会洪泛或转发接收到的数据帧。
When all end nodes attached to an ingress RBridge pre-encapsulate with a TRILL header for traffic across the TRILL domain, the ingress RBridge doesn't need to encapsulate any native Ethernet frames to the TRILL domain. The attached nodes can be connected to multiple edge RBridges by having multiple ports or through a bridged LAN. All RBridge edge ports connected to one bridged LAN can receive and forward pre-encapsulated traffic; this can greatly improve the overall network utilization. However, it is still necessary to, for example, designate AF ports to be sure that multi-destination packets from the TRILL campus are only egressed through one RBridge.
当连接到入口RBridge的所有端节点使用TRILL报头预封装整个TRILL域的流量时，入口RBridge不需要将任何本机以太网帧封装到TRILL域。连接的节点可以通过具有多个端口或通过桥接LAN连接到多个边缘RBridge。连接到一个桥接LAN的所有RBridge边缘端口都可以接收和转发预封装的流量；这可以大大提高整体网络利用率。然而，例如，仍然需要指定AF端口以确保来自TRILL校园的多目的地分组仅通过一个RBridge流出。
Item 8 of Section 4.6.2 of the TRILL base protocol specification [RFC6325] specifies that an RBridge port can be configured to accept TRILL-encapsulated frames from a neighbor that is not an RBridge.
Item 8 of Section 4.6.2 of the TRILL base protocol specification [RFC6325] specifies that an RBridge port can be configured to accept TRILL-encapsulated frames from a neighbor that is not an RBridge.translate error, please retry
When a TRILL frame arrives at an RBridge whose nickname matches the destination nickname in the TRILL header of the frame, the processing is exactly as normal: as specified in [RFC6325], the RBridge
当颤音帧到达其昵称与帧颤音报头中的目的地昵称匹配的RBridge时，处理完全正常：如[RFC6325]中所述，RBridge
decapsulates the received TRILL frame and forwards the decapsulated frame to the target attached to its edge ports. When the destination MAC address of the decapsulated Ethernet frame is not in the egress RBridge's local MAC attachment tables, the egress RBridge floods the decapsulated frame to all attached links in the frame's VLAN, or drops the frame (if the egress RBridge is configured with that policy).
解除接收到的颤音帧的封装，并将解除封装的帧转发到连接到其边缘端口的目标。当解除封装的以太网帧的目标MAC地址不在出口RBridge的本地MAC连接表中时，出口RBridge将解除封装的帧洪泛到帧的VLAN中的所有连接链路，或丢弃帧（如果出口RBridge配置了该策略）。
We call a node that, as specified herein, only performs TRILL encapsulation, but doesn't participate in RBridge's IS-IS routing, a TRILL Encapsulating Node (TRILL-EN). The TRILL Encapsulating Node can pull (MAC and VLAN) <-> Edge RBridge mapping from directory servers [RFC8171]. In order to do this, a TRILL-EN MUST support TRILL ES-IS [RFC8171].
如本文所述，我们将只执行TRILL封装但不参与RBridge的IS-IS路由的节点称为TRILL封装节点（TRILL-EN）。TRILL封装节点可以从目录服务器拉取（MAC和VLAN）<->边缘RBridge映射[RFC8171]。为此，TRILL-EN必须支持TRILL ES-IS[RFC8171]。
Upon receiving or locally generating a native Ethernet frame, the TRILL-EN checks the (MAC and VLAN) <-> Edge RBridge mapping and performs the corresponding TRILL encapsulation if the mapping entry is found as shown in Figure 2. If the destination MAC address and VLAN of the received Ethernet frame doesn't exist in the mapping table and there is no positive reply from pull requests to a directory, the Ethernet frame is dropped or is forwarded in native form to an edge RBridge, depending on the TRILL-EN configuration.
在接收或本地生成本机以太网帧时，TRILL-EN检查（MAC和VLAN）<->边缘RBridge映射，如果找到映射条目，则执行相应的TRILL封装，如图2所示。如果接收到的以太网帧的目标MAC地址和VLAN在映射表中不存在，并且从拉入请求到目录没有肯定的答复，则根据TRILL-EN配置，以太网帧将被丢弃或以本机形式转发到边缘RBridge。
+------------+--------+---------+---------+--+-------+---+
|OuterEtherHd|TRILL HD| InnerDA | InnerSA |..|Payload|FCS|
+------------+--------+---------+---------+--+-------+---+
|
| |<Inner Ether Header> |
|
|
| +-------+ TRILL +------+
| | RB1 |---------->| RB2 | Decapsulate
| +-------+ domain +------+ TRILL header
v ^ |
+---------->| |
| V
+--------+ +--------+
Non-RBridge node: |TRILL-EN| |TRILL-EN|
Encapsulate TRILL | 1 | | 2 |
Header for data +--------+ +--------+
Frames to traverse TRILL domain.
+------------+--------+---------+---------+--+-------+---+
|OuterEtherHd|TRILL HD| InnerDA | InnerSA |..|Payload|FCS|
+------------+--------+---------+---------+--+-------+---+
|
| |<Inner Ether Header> |
|
|
| +-------+ TRILL +------+
| | RB1 |---------->| RB2 | Decapsulate
| +-------+ domain +------+ TRILL header
v ^ |
+---------->| |
| V
+--------+ +--------+
Non-RBridge node: |TRILL-EN| |TRILL-EN|
Encapsulate TRILL | 1 | | 2 |
Header for data +--------+ +--------+
Frames to traverse TRILL domain.
Figure 2: Data Frames from a TRILL-EN
图2：来自TRILL-EN的数据帧
The TRILL header includes a Source RBridge's Nickname (ingress) and Destination RBridge's Nickname (egress). When a TRILL header is added to a data packet by a TRILL-EN, the ingress RBridge nickname field in the TRILL header is set to a nickname of the AF for the data packet's VLAN. The TRILL-EN determines the AF by snooping on IS-IS Hellos from the edge RBridges on the link with the TRILL-EN in the same way that the RBridges on the link determine the AF [RFC8139]. A TRILL-EN is free to send the encapsulated data frame to any of the edge RBridges on its link.
TRILL报头包括源RBridge的昵称（入口）和目标RBridge的昵称（出口）。当TRILL-EN将TRILL报头添加到数据分组时，TRILL报头中的入口RBridge昵称字段被设置为数据分组的VLAN的AF昵称。TRILL-EN通过与TRILL-EN在链路上的边缘RBridges上窥探IS-IS Hellos来确定AF，与链路上的RBridges确定AF的方式相同[RFC8139]。TRILL-EN可以自由地将封装的数据帧发送到其链路上的任何边缘RBridge。
This section summarizes the benefits of having a non-RBridge node perform TRILL encapsulation.
本节总结了让非RBridge节点执行TRILL封装的好处。
For a large data center with hundreds of thousands of virtualized servers, setting the TRILL boundary at the servers' virtual switches will create a TRILL domain with hundreds of thousands of RBridge nodes; this could lead to TRILL nickname exhaustion and challenges to IS-IS. On the other hand, setting the TRILL boundary at aggregation switches that have many virtualized servers attached can limit the number of RBridge nodes in a TRILL domain, but introduces the issue of having very large (MAC and VLAN) <-> Edge RBridge mapping tables that need to be maintained by edge RBridges.
对于拥有数十万虚拟服务器的大型数据中心，在服务器的虚拟交换机上设置TRILL边界将创建一个拥有数十万RBridge节点的TRILL域；这可能导致颤音昵称耗尽，并对IS-IS提出挑战。另一方面，在连接了许多虚拟化服务器的聚合交换机上设置TRILL边界可以限制TRILL域中RBridge节点的数量，但会引入需要由边缘RBridge维护的非常大（MAC和VLAN）<->边缘RBridge映射表的问题。
Allowing non-RBridge nodes to pre-encapsulate data frames with TRILL headers makes it possible to have a TRILL domain with a reasonable number of RBridge nodes in a large data center. All the TRILL-ENs attached to one RBridge can be represented by one TRILL nickname, which can avoid the nickname exhaustion problem.
允许非RBridge节点使用TRILL报头预封装数据帧，使得在大型数据中心中有一个TRILL域和合理数量的RBridge节点成为可能。连接到一个RBridge的所有颤音可以用一个颤音昵称表示，这可以避免昵称耗尽问题。
When hosts in a VLAN (or subnet) span across multiple edge RBridges and each edge RBridge has multiple VLANs enabled, the switches on the bridged LANs attached to the edge RBridges are exposed to all MAC addresses among all the VLANs enabled.
当VLAN（或子网）中的主机跨越多个边缘RBridge且每个边缘RBridge启用了多个VLAN时，连接到边缘RBridge的桥接LAN上的交换机将暴露于所有启用VLAN中的所有MAC地址。
For example, for an Access Switch with 40 physical servers attached, where each server has 100 VMs, there are 4000 hosts under the Access Switch. If indeed hosts/VMs can be moved anywhere, the worst case for the Access Switch is when all those 4000 VMs belong to different VLANs, i.e., the Access Switch has 4000 VLANs enabled. If each VLAN
例如，对于连接了40台物理服务器的访问交换机，其中每台服务器有100个VM，访问交换机下有4000台主机。如果主机/虚拟机确实可以移动到任何地方，那么访问交换机的最坏情况是，所有这些4000个虚拟机都属于不同的VLAN，即，访问交换机启用了4000个VLAN。如果每个VLAN
has 200 hosts, this Access Switch's MAC table potentially has 200 * 4000 = 800,000 entries.
有200台主机，此访问交换机的MAC表可能有200*4000=800000个条目。
If the virtual switches on servers pre-encapsulate the data frames destined for hosts attached to remote edge RBridges, the outer MAC destination address of those TRILL-encapsulated data frames will be the MAC address of a local RBridge edge, i.e., the ingress RBridge. The switches on the local bridged LAN don't need to keep the MAC entries for remote hosts attached to other edge RBridges.
如果服务器上的虚拟交换机预先封装了目的地为连接到远程边缘RBridge的主机的数据帧，则这些TRILL封装的数据帧的外部MAC目的地地址将是本地RBridge边缘（即入口RBridge）的MAC地址。本地桥接LAN上的交换机不需要将远程主机的MAC条目保持连接到其他边缘RBridge。
But the TRILL traffic from nodes attached to other RBridges is decapsulated and has the true source and destination MACs. One simple way to prevent local bridges from learning remote hosts' MACs and adding to their MAC tables, if that would be a problem, is to disable this data-plane learning on local bridges. With the assistance of a directory, the local bridges can be pre-configured with MAC addresses of local hosts. The local bridges can always send frames with unknown destination MAC addresses to the ingress RBridge. In an environment where a large number of VMs are instantiated in one server, the number of remote MAC addresses could be very large. If it is not feasible to disable learning and pre-configure MAC tables for local bridges and all important traffic is IP, one effective method to minimize local bridges' MAC table size is to use the server's MAC address to hide MAC addresses of the attached VMs. That is, the server acting as an edge node uses its own MAC address in the source MAC address field of the packets originated from a host (or VM). When the Ethernet frame arrives at the target edge node (the egress), the target edge node can send the packet to the corresponding destination host based on the packet's IP address. Very often, the target edge node communicates with the embedded VMs via a Layer 2 virtual switch. In this case, the target edge node can construct the proper Ethernet header with the assistance of the directory. The information from the directory includes the proper mapping of host IP to MAC.
但是，来自连接到其他RBridge的节点的TRILL流量被解除封装，并且具有真正的源MAC和目标MAC。防止本地网桥学习远程主机的MAC并将其添加到MAC表的一种简单方法是禁用本地网桥上的数据平面学习。在目录的帮助下，可以使用本地主机的MAC地址预先配置本地网桥。本地网桥始终可以将目标MAC地址未知的帧发送到入口RBridge。在一台服务器中实例化了大量虚拟机的环境中，远程MAC地址的数量可能非常大。如果禁用本地网桥的学习和预配置MAC表是不可行的，并且所有重要的通信量都是IP，则最小化本地网桥MAC表大小的一种有效方法是使用服务器的MAC地址隐藏连接的VM的MAC地址。即，充当边缘节点的服务器在源自主机（或VM）的数据包的源MAC地址字段中使用其自己的MAC地址。当以太网帧到达目标边缘节点（出口）时，目标边缘节点可以基于分组的IP地址将分组发送到相应的目的主机。通常，目标边缘节点通过第2层虚拟交换机与嵌入式虚拟机通信。在这种情况下，目标边缘节点可以在目录的帮助下构造适当的以太网报头。目录中的信息包括主机IP到MAC的正确映射。
Directory assistance [RFC8171] is required to make it possible for a non-TRILL node to pre-encapsulate packets destined towards remote RBridges. TRILL-ENs have the same configuration options as any pull directory client. See Section 4 of [RFC8171].
需要目录协助[RFC8171]使非TRILL节点能够预封装发送到远程RBridge的数据包。TRILL ENs具有与任何pull目录客户端相同的配置选项。见[RFC8171]第4节。
If the TRILL-ENs are not trusted, they can forge arbitrary ingress and egress nicknames in the TRILL Headers of the TRILL Data packets they construct. With data-plane learning, decapsulating a TRILL Data packet at an egress RBridge associates the inner source MAC address
如果TRILL-en不受信任，它们可以在它们构造的TRILL数据包的TRILL报头中伪造任意入口和出口昵称。通过数据平面学习，在出口RBridge处解封装TRILL数据包与内部源MAC地址相关联
with the ingress nickname in the TRILL Header (assuming that MAC address is unicast). Thus, if those ingress nicknames are forged, incorrect learning will occur and future traffic destined for the inner source MAC will be sent to the wrong RBridge for egress. Because of this, an RBridge port should not be configured to accept encapsulated TRILL data frames on a link were it does not have an RBridge adjacency unless the end stations on that link are trusted.
在TRILL报头中使用入口昵称（假设MAC地址为单播）。因此，如果这些入口昵称是伪造的，则将发生错误的学习，并且将来发送到内部源MAC的流量将被发送到错误的RBridge进行出口。因此，如果RBridge端口没有RBridge邻接，则不应将其配置为在链路上接受封装的TRILL数据帧，除非该链路上的终端站是可信的。
As with any end station, TRILL-ENs can forge the outer MAC addresses of packets they send. (See Section 6 of [RFC6325].) Because they pre-encapsulate, they can also forge inner MAC addresses.
与任何终端站一样，TRILL ENs可以伪造他们发送的数据包的外部MAC地址。（参见[RFC6325]第6节）因为它们是预封装的，所以它们还可以伪造内部MAC地址。
The pre-encapsulation performed by TRILL-ENs also means they can send data in any VLAN; this means they must be trusted in order to enforce a security policy based on VLANs. (See Section 6.1 of [RFC6325].)
TRILL ENs执行的预封装也意味着他们可以在任何VLAN中发送数据；这意味着必须信任它们，才能实施基于VLAN的安全策略。（见[RFC6325]第6.1节）
Use of directory-assisted encapsulation by TRILL-ENs essentially involves those TRILL-ENs spoofing edge RBridges to which they are connected; this is another reason that TRILL-ENs should be trusted nodes. Such spoofing cannot cause persistently looping traffic because TRILL has a hop count in the TRILL header [RFC6325] so that, should there be a loop, a TRILL packet caught in that loop (i.e., an encapsulated frame) will be discarded. (In the potentially more dangerous case of multidestination packets (as compared with known unicast) where copies could multiply due to forks in the distribution tree, a Reverse Path Forwarding Check is also used [RFC6325] to discard packets that appear to be on the wrong link or when there is disagreement about the distribution tree.)
TRILL-en使用目录辅助封装本质上涉及到那些TRILL-en欺骗它们所连接的边缘rbridge；这是TRILL ENs应该是可信节点的另一个原因。此类欺骗不会导致持续循环流量，因为TRILL在TRILL报头[RFC6325]中有一个跃点计数，因此，如果存在循环，在该循环中捕获的TRILL数据包（即封装的帧）将被丢弃。（在多目的地数据包（与已知的单播相比）的潜在更危险情况下，由于分发树中的分叉，副本可能会成倍增加，也可以使用反向路径转发检查[RFC6325]来丢弃似乎位于错误链路上的数据包，或者当对分发树存在分歧时。）
The mechanism described in this document requires a TRILL-EN to be aware of the MAC address(es) of the TRILL edge RBridge(s) to which the TRILL-EN is attached and the egress RBridge nickname from which the destination of the packets is reachable. With that information, TRILL-ENs can learn a substantial amount about the topology of the TRILL domain. Therefore, there could be a potential security risk when the TRILL-ENs are not trusted or are compromised.
本文档中描述的机制要求TRILL-EN知道TRILL-EN连接到的TRILL边缘RBridge的MAC地址以及可从中到达分组目的地的出口RBridge昵称。有了这些信息，TRILL ENs可以了解大量关于TRILL域拓扑的信息。因此，当TRILL ENs不受信任或受到破坏时，可能存在潜在的安全风险。
If the path between the directory and a TRILL-EN is attacked, false mappings can be sent to the TRILL-EN causing packets from the TRILL-EN to be sent to wrong destinations, possibly violating security policy as to which end stations should receive what data. Therefore, a combination of authentication and encryption is RECOMMENDED between the directory and TRILL-EN. The entities involved will need to properly authenticate with each other, provide session encryption, maintain security patch levels, and configure their systems to allow minimal access and running processes to protect sensitive information.
如果目录和TRILL-EN之间的路径受到攻击，则可能会向TRILL-EN发送错误的映射，从而导致来自TRILL-EN的数据包被发送到错误的目的地，这可能违反关于哪些终端站应该接收什么数据的安全策略。因此，建议在目录和TRILL-EN之间结合使用身份验证和加密。所涉及的实体将需要彼此进行适当的身份验证，提供会话加密，维护安全补丁级别，并配置其系统以允许最小的访问和运行进程来保护敏感信息。
For added security against the compromise of data due to its misdelivery for any reason, including the above, end-to-end encryption and authentication should be considered; that is, encryption and authentication from source end station to destination end station.
为了增加安全性，防止由于任何原因（包括上述原因）导致的数据误发，应考虑端到端加密和身份验证；即，从源端站到目标端站的加密和身份验证。
For Pull Directory and TRILL ES-IS security considerations, see [RFC8171].
有关Pull目录和TRILL ES-IS安全注意事项，请参阅[RFC8171]。
This document has no IANA actions.
本文档没有IANA操作。
[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>.
[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>.
[RFC7176] Eastlake 3rd, D., Senevirathne, T., Ghanwani, A., Dutt, D., and A. Banerjee, "Transparent Interconnection of Lots of Links (TRILL) Use of IS-IS", RFC 7176, DOI 10.17487/RFC7176, May 2014, <https://www.rfc-editor.org/info/rfc7176>.
[RFC7176]Eastlake 3rd，D.，Senevirathne，T.，Ghanwani，A.，Dutt，D.，和A.Banerjee，“IS-IS大量链路的透明互连（TRILL）使用”，RFC 7176，DOI 10.17487/RFC7176，2014年5月<https://www.rfc-editor.org/info/rfc7176>.
[RFC8139] Eastlake 3rd, D., Li, Y., Umair, M., Banerjee, A., and F. Hu, "Transparent Interconnection of Lots of Links (TRILL): Appointed Forwarders", RFC 8139, DOI 10.17487/RFC8139, June 2017, <https://www.rfc-editor.org/info/rfc8139>.
[RFC8139]Eastlake 3rd，D.，Li，Y.，Umair，M.，Banerjee，A.，和F.Hu，“大量链接的透明互连（TRILL）：指定的货运代理”，RFC 8139，DOI 10.17487/RFC8139，2017年6月<https://www.rfc-editor.org/info/rfc8139>.
[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>.
[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 following are thanked for their contributions:
感谢以下各方的贡献：
Igor Gashinsky Ben Nevin-Jenkins
伊戈尔·加辛斯基·本·内文·詹金斯
Authors' Addresses
作者地址
Linda Dunbar Huawei Technologies 5340 Legacy Drive, Suite 175 Plano, TX 75024 United States of America
Linda Dunbar华为技术5340 Legacy Drive，美国德克萨斯州普莱诺175号套房75024
Phone: +1-469-277-5840
Email: linda.dunbar@huawei.com
Phone: +1-469-277-5840
Email: linda.dunbar@huawei.com
Donald Eastlake 3rd Huawei Technologies 155 Beaver Street Milford, MA 01757 United States of America
美国马萨诸塞州米尔福德市海狸街155号唐纳德·伊斯特莱克第三华为技术有限公司01757
Phone: +1-508-333-2270
Email: d3e3e3@gmail.com
Phone: +1-508-333-2270
Email: d3e3e3@gmail.com
Radia Perlman Dell/EMC 2010 256th Avenue NE, #200 Bellevue, WA 98007 United States of America
Radia Perlman Dell/EMC 2010美国华盛顿州贝尔维尤市东北第256大道200号，邮编：98007
Email: Radia@alum.mit.edu
Email: Radia@alum.mit.edu