[要約] RFC 8302は、TRILLネットワークにおけるARPとNeighbor Discovery（ND）の最適化に関するものです。このRFCの目的は、TRILLネットワークでのARPとNDのパフォーマンスを向上させるためのガイドラインを提供することです。
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スイッチは、ARP / ND要求とそれらを通過する応答から学習したIP /メディアアクセス制御（MAC）アドレス/データラベルバインディングのキャッシュを維持します。多くの場合、このキャッシュにより、エッジルーティングブリッジ（RBridge）は、直接応答するか、カプセル化してユニキャストすることにより、ARP / ND要求のフラッディングを回避できます。このような最適化により、TRILLキャンパスでのパケットフラッディングが減少します。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
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（Internet Engineering Task Force）の製品です。これは、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.
Copyright（c）2018 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
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）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、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
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.
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの「」は、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 Application sub-Type-Length-Value [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]
キャンパスRBridges、リンク、および場合によってはエンドステーションとIPルーターで囲まれたブリッジで構成されるTRILLネットワーク[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 [RFC2131]とDHCPv6 [RFC3315]の両方のDHCPを指します。
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インターフェイスアドレス。 TRILL APPsub-TLV [RFC7961]
IP Internet Protocol, both IPv4 and IPv6
IPインターネットプロトコル、IPv4とIPv6の両方
MAC Media Access Control [RFC7042]
MACメディアアクセスコントロール[RFC7042]
ND Neighbor Discovery [RFC4861] RBridge A contraction of "Routing Bridge". A device implementing the TRILL protocol.
ND Neighbor Discovery [RFC4861] RBridge「ルーティングブリッジ」の収縮。 TRILLプロトコルを実装するデバイス。
SEND Secure Neighbor Discovery [RFC3971]
Secure Neighbor Discoveryを送信する[RFC3971]
TRILL Transparent Interconnection of Lots of Links or Tunneled Routing in the Link Layer [RFC6325] [RFC7780]
多くのリンクの透過的な相互接続またはリンク層のトンネルルーティング[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]、または次のようなメッセージのスヌーピングによるデータプレーン学習を通じて、端末のIP / MACアドレスマッピングを知る必要があります。 ARP / ND（DHCPまたはGratuitous ARPメッセージを含む）。
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アドレスマッピングがエッジRBridgeに認識されているか、管理を通じてプロビジョニングされているか、エッジRBridgeのコントロールプレーンを介して学習されている場合、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 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.
ほとんどのエンドステーションホストは、IPアドレスを要求するDHCPメッセージ、または無償のARPまたは逆アドレス解決プロトコル（RARP）要求を送信して、オンラインになった直後にネットワークに通知します。したがって、ローカルエッジRBridgeは、MACアドレスとIPアドレスをスヌープして学習し、この情報をTRILLコントロールプレーンエンドステーションアドレス配布情報（ESADI）[RFC7357]プロトコルを介して他のエッジRBridgeに配布する機会を得ます。リモートRBridgeがコントロールプレーンを介してこの情報を受信すると、IP-to-MACマッピング情報を、アドレス情報のニックネームとデータラベルとともにARP / NDキャッシュに追加する必要があります。したがって、TRILLネットワーク内のほとんどのアクティブなIPホストは、ローカルラーニングまたはコントロールプレーンベースのリモートラーニングを通じてエッジRBridgeによって学習できます。その結果、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内に表示されますが、それが指定する値のデータ構造は他のアプリケーションコンテキストでも発生する可能性があります。エッジ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].
RBridgeは、ARP [RFC826]またはND [RFC4861]メッセージを受信することにより、アクセスポートを介して接続されているローカルエンドステーションのIP / MACアドレスマッピングを簡単に知ることができます。エッジRBridgeが受信したデータフレーム（ARPまたはNDのいずれか）から送信者のIP / MACアドレスペアを抽出した場合、情報を保存し、IA APPsub-TLVを使用してIPアドレスとMACアドレスをリンクし、他のアドレスに配布します。 ESADIを介したRBridges。次に、関連するリモートRBridge（通常、元のARP / NDメッセージと同じデータラベルに関心があるもの）も、そのようなマッピング情報を受信して保存します。 RBridgeが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 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.
上記の例は、エンドステーションが実際のデータパケットを送信または受信する前に、RBridgesが特定のデータラベル（VLANまたはFGL）のエンドステーションのトリプレット{IPアドレス、MACアドレス、入力ニックネーム}を保存した可能性があることを示しています。このような情報は完全なリストである場合とそうでない場合があり、すべてのRBridgeに存在する場合と存在しない場合があります。情報は異なるソースからのものである可能性があります。次に、RBridgesは、IA APPsub-TLVのFlagsフィールドを使用して、ソースがディレクトリサーバーか、送信者によるローカル監視かを識別できます。マッピング情報の信頼性を示すために、異なる信頼レベルを使用することもできます。
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]メッセージであるネイティブフレームは、そのEthertype 0x0806によって検出されます。 ND [RFC4861]であるネイティブフレームは、5つの異なるICMPv6パケットタイプの1つであることによって検出されます。 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アドレス、送信元IPアドレス、およびNDの送信元リンク層アドレス。
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メッセージからのRBridgeによるアドレス情報の抽出について説明します。状況によっては、この抽出によりエンドステーションでの確認が求められる場合があります。セクション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で説明されているように、SENDメッセージはこのドキュメントで指定されたメカニズムによって最適化されず、スヌーピングされます。
Secure Neighbor Discovery (SEND) [RFC3971] is a method of securing ND that addresses the threats discussed in [RFC3756]. Typical TRILL campuses are inside data centers, Internet exchange points, or carrier facilities. These are generally controlled and protected environments where these threats are of less concern. Nevertheless, SEND provides an additional layer of protection.
Secure Neighbor Discovery（SEND）[RFC3971]は、[RFC3756]で説明されている脅威に対処するNDを保護する方法です。典型的な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.
安全なSENDメッセージには、暗号化キーの知識が必要です。そのようなキーをSENDで使用するためにRBridgeに通信する方法は、このドキュメントの範囲外です。したがって、このドキュメントの最適化を使用すると、RBridgeはSENDメッセージを構築しようとせず、一般に透過的です。 RBridgeは、ARP、RARP、または安全でないNDメッセージのみを適切に構築します。それにもかかわらず、ARP / ND最適化を実装するRBridgeは、SENDメッセージをスヌープして、SENDが安全でないNDメッセージとして送信され、SENDメッセージにまだ存在する場合に存在するアドレス情報を抽出する必要があります。
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.
エッジRBridgeは、以下に説明するように、エンドステーションが送信する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 送信者のIPが入力RBridgeのARP / NDキャッシュに存在しない場合は、送信者のIP / MACアドレスマッピングの情報をARP / NDキャッシュテーブルに入力します。入力RBridgeは、そのニックネームとそのIP / MACアドレスマッピング情報を関連付けます。後で説明するように、このような{IPアドレス、MACアドレス、入力ニックネーム}の3つの情報はローカルに保存され、他の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アドレスがすでに使用されているか、エンドステーションであるかどうかを確認する必要があります（SHOULD）。付属のRBridgeを変更しました。 RBridgeは、これを行うために異なる戦略を使用する場合があります。たとえば、RBridgeは、ディレクトリサーバーなどの信頼できるエンティティに問い合わせるか、ARP / NDメッセージをカプセル化して、アドレスが使用されていると考えられる場所にユニキャストする場合があります（セクション4.2）。 RBridgeは、検証結果に基づいて、保存された{IPアドレス、MACアドレス、入力ニックネーム}のトリプレットを更新する必要があります（SHOULD）。 RBridgeは、ネットワークマネージャーのポリシーが、各データラベルに対して、単一のリンクであり、受信したARP / NDであるかのようにネットワークを動作させることである場合、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.
エッジRBridgeがネイティブARP / NDを処理するためのオプションを以下に示します。 IPアドレスに対応するMACアドレスを求める一般的なARP / NDリクエストの場合、エッジRBridgeがIPアドレスと対応するMACを知っている場合、動作は（a）のようになり、それ以外の場合は（b）のようになります。無償のARPおよびNDの非送信請求ネイバーアドバタイズメント（NA）の動作[RFC4861]は、項目（c）に示されています。また、項目（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は以下のアクションの1つまたは組み合わせを実行する必要があります。 SEND [RFC3971]の場合、RBridgeはターゲットの秘密鍵で応答に署名できず、アクションa.2またはa.5のみが有効であるため、暗号化により、入力RBridgeによるローカル応答が防止されます。
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.1。入力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.2。ターゲットの指定RBridgeへのARP / ND / SENDリクエストをカプセル化し、ターゲットの出力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.3。同じターゲットへのリクエストが起動された後しばらくの間発生する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.4。プルディレクトリサーバーから取得した情報や、入力RBridgeがそこにプッシュするように要求したディレクトリ情報などのディレクトリ情報[RFC8171]に基づいてクエリアに返信します。
a.5. Flood the ARP/ND/SEND request as per [RFC6325].
a.5。 [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は次のいずれかのアクションを実行する必要があります。 SEND [RFC3971]の場合、RBridgeはターゲットの秘密鍵で応答に署名できないため、暗号化により、入力RBridgeによるローカルな応答が防止されます。したがって、アクションb.1のみが有効です。
b.1. Flood the ARP/ND/SEND message as per [RFC6325].
b.1。 [RFC6325]に従って、ARP / ND / SENDメッセージをフラッディングします。
b.2. Use a directory server to pull the information [RFC8171] and reply to the querier.
b.2。ディレクトリサーバーを使用して情報[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.3。ディレクトリサーバーが、照会されているアドレスが存在しないという信頼できる情報を提供するため、応答がない場合はメッセージをドロップします。
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アドレスマッピング情報を配布する場合があります。 1つ以上のディレクトリサーバーが展開され、データラベル内のすべてのRBridgeが完全なプッシュディレクトリ情報を使用する場合、不必要なARPまたは未承諾のNAは、進入するのではなく破棄する必要があります（SHOULD）。それ以外の場合は、[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メッセージとして処理する必要があります（SHOULD）。
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 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.
入力RBridge R1がセクション4.4、項目a.2で説明したようにARP / ND要求をターゲットの出力RBridge R2にユニキャストするか、項目a.5および[RFC6325]に従って要求をフラッディングする場合、R2はクエリのカプセル化を解除しますターゲットのリンクでARP / NDクエリを開始します。ターゲットが応答すると、R2はR1への応答をカプセル化およびユニキャストし、R1は応答をカプセル化解除してクエリアに送信します。 R2は、リンクの状態の更新を開始して、他のすべてのRBridgeに、クエリアに応答を転送するだけでなく、ターゲットの場所、レイヤー3アドレス、およびレイヤー2アドレスを通知する必要があります（SHOULD）。更新では、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と同じパケット形式を使用しますが、Ethertype（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メッセージ）、ARP / NDキャッシュにIP / MACアドレスマッピング情報を保存し、さらに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ロケーション情報は正しいです。他のソースとは別の場所（異なるエッジRBridgeまたはポート）に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 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 / MACアドレスマッピングが変更されると、重複したIPアドレスを検出できます。また、エッジRBridgeは、重複アドレス検出クエリ（DADクエリ）と呼ばれるクエリを、以前にそのIPアドレスに関連付けられていたMACアドレスを使用して、そのIPアドレスの元の所有者に問い合わせます。 DADクエリは、ARP（またはDADクエリソースIPと呼ばれるRBridgeごとの構成可能なIPアドレス）の場合は送信者IP 0.0.0.0のユニキャストARP / NDメッセージで、ソースがNDの場合はIPv6リンクローカルアドレスです。 DADクエリアRBridgeのMACに設定されたMAC。クエリを実行しているRBridgeが所定の時間内に応答を受信しない場合は、モビリティのケースである可能性があります。いずれの場合も、新しい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は、ネットワーク管理者が適切なアクションを実行できるように、重複をログに記録する必要があります（SHOULD）。
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エントリをテーブルからフラッシュする必要があります（SHOULD）。エントリは、任意の場所から同じIP / MACアドレスマッピングエントリのARPまたはNDメッセージを受信した場合に更新されます。 IP / MACアドレスマッピング情報のエージングタイマーは、RBridgeごとに構成可能であり、MACアドレスラーニングエージングタイマー[RFC6325]の3/4にデフォルト設定されています。
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」はエッジRBridge1（RB1）に接続され、RB1のローカルエントリとして学習されています。端末Aが他の場所（MAC /仮想マシン（VM）モビリティ）に移動してエッジRBridge（RB2）に接続された場合、RB2のアクセスポートで学習した後、RB2はこのエントリをTRILLコントロールプレーンを通じてアドバタイズします。これは、RB1でリモートエントリとして学習されます。 RB1の古いエントリは置き換えられる必要があり（SHOULD）、そのデータラベルに対して端末サービスが有効になっている他のすべてのエッジRBridgeは、RB1ではなくRB2からの到達可能性を示すようにエントリを更新する必要があります。
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最適化の基礎であるアドレス情報を学習する一般的な2つのモードがあります。データプレーンモードとディレクトリモードです。データプレーンモードは、従来のブリッジアドレス学習[IEEE802.1Q]であり、TRILLスイッチ[RFC6325]にも実装されており、セクション9.1で説明されています。ディレクトリモードは、ディレクトリ[RFC8171]から取得したデータを使用します。これについては、セクション9.2で説明します。競合する住所情報間の仲裁に役立つTRILL信頼レベル機能については、セクション9.3で説明します。
RBridges should rate limit ARP/ND queries injected into the TRILL campus to limit some potential denial-of-service attacks.
RBridgeは、潜在的なサービス拒否攻撃を制限するために、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最適化がデータプレーンモードで動作している場合、RBridgeによって学習される情報は、エンドステーションによって学習される情報と同じです。したがって、最適化されるクエリメッセージに対してRBridgesによって生成される応答は、一般に、最適化がない場合にエンドステーションによって生成されるものであり、セキュリティに関する考慮事項は、基礎となる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は、それらのDHCPackメッセージを送信するエンドステーションが応答するのと基本的に同じ方法でARP / NDメッセージに応答します。したがって、スヌープされる可能性のある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.
SEND [RFC3971]を使用しない限り、ARPおよびNDメッセージは簡単に偽造できます。したがって、ARP / NDからのRBridgesによるIP / MACアドレスの学習はハッキング可能ですが、これはSENDなしのデータプレーン学習に利用できるものです。 「送信に関する考慮事項」のセクション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アドレスマッピング情報は、[RFC7357]で指定されているように保護できるTRILL ESADIプロトコルを使用して他のRBridgeに配布できます。 （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またはプルディレクトリの取得を介して受信した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.、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>.
[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。、「Dynamic Host Configuration Protocol」、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.、and M. Carney、 "Dynamic Host Configuration Protocol for 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、「Neighbor Discovery for IP version 6（IPv6）」、RFC 4861、DOI 10.17487 / RFC4861、2007年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 Stateless Address Autoconfiguration」、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、「Routing Bridges（RBridges）：Base Protocol Specification」、RFC 6325、DOI 10.17487 / RFC6325、7月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>.
[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、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] Zhai、H.、Hu、F.、Perlman、R.、Eastlake 3rd、D。、およびO. Stokes、「多数のリンクの透過的相互接続（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.、and S. Gupta、 "Transparent Interconnection of Lots of Links（TRILL）：Clarifications、Corrections、andアップデート」、RFC 7780、DOI 10.17487 / RFC7780、2016年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、6月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>.
[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 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.
[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>.
[RFC3756] Nikander、P.、Ed。、Kempf、J。、およびE. Nordmark、「IPv6 Neighbor Discovery（ND）Trust Models and Threats」、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、「SEcure Neighbor Discovery（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] Cheshire、S。、「IPv4 Address Conflict Detection」、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.、Kairr、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、「IANAの考慮事項とIEEE 802パラメータの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、「Directory Assistance Problem and High-Level Design Proposal」、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
Y Iweekl IH UAはテクノロジー101ソフトウェアアベニュー、南京210012中国電話：+ 86-25-56625375メール：Li Yizhou@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 Huawei R＆D USA 155 Beaver Street Milford、MA 01757 United States電話：+ 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、Suite＃175 Plano、TX 75024 United States of Phone電話：+ 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、MA 01748 United States of Email 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
Mohammed Umair Cisco Cessna Business Park、Kadubeesanahalli Village、Hobli、Sarjapur、Varthur Main Road、Marathahalli、Bengaluru、Karnataka 560087 India Email：mohammed.umair2@gmail.com