[要約] RFC 9161は、Ethernet Virtual Private Networks (EVPNs) におけるProxy ARP/NDの運用面に焦点を当てています。この文書の目的は、ネットワークのスケーラビリティと効率を向上させるために、Proxy ARP/NDの利用方法とベストプラクティスを提供することです。利用場面としては、大規模なEVPN環境でのIPアドレス解決の最適化が挙げられます。
Internet Engineering Task Force (IETF) J. Rabadan, Ed.
Request for Comments: 9161 S. Sathappan
Updates: 7432 K. Nagaraj
Category: Standards Track G. Hankins
ISSN: 2070-1721 Nokia
T. King
DE-CIX
January 2022
Operational Aspects of Proxy ARP/ND in Ethernet Virtual Private Networks
イーサネット仮想プライベートネットワークにおけるプロキシARP / NDの運用面
Abstract
概要
This document describes the Ethernet Virtual Private Network (EVPN) Proxy ARP/ND function augmented by the capability of the ARP/ND Extended Community. From that perspective, this document updates the EVPN specification to provide more comprehensive documentation of the operation of the Proxy ARP/ND function. The EVPN Proxy ARP/ND function and the ARP/ND Extended Community help operators of Internet Exchange Points, Data Centers, and other networks deal with IPv4 and IPv6 address resolution issues associated with large Broadcast Domains by reducing and even suppressing the flooding produced by address resolution in the EVPN network.
この文書では、ARP / ND拡張コミュニティの機能によって拡張されたイーサネット仮想プライベートネットワーク（EVPN）プロキシARP / ND機能について説明します。その観点から、この文書はEVPN仕様を更新して、プロキシARP / ND機能の操作のより包括的な文書を提供します。EVPNプロキシARP / ND関数とARP / ND拡張コミュニティのインターネット交換ポイント、データセンター、およびその他のネットワークのオペレータは、アドレスごとに生成されたフラッディングを抑制することで、大きなブロードキャストドメインに関連するIPv4およびIPv6アドレス解決の問題を扱います。EVPNネットワーク内の解決。
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/rfc9161.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttps://www.rfc-editor.org/info/rfc9161で取得することができます。
Copyright Notice
著作権表示
Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2022 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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
この文書は、この文書の公開日に有効なIETF文書（https://trustee.ietf.org/License-Info）に関するBCP 78およびIETF信頼の法的規定の対象となります。この文書に関してあなたの権利と制限を説明するので、これらの文書をよくレビューしてください。この文書から抽出されたコードコンポーネントには、信託法定規定のセクション4。
Table of Contents
目次
1. Introduction
1.1. The Data Center Use Case
1.2. The Internet Exchange Point Use Case
2. Terminology
3. Solution Description
3.1. Proxy ARP/ND Sub-functions
3.2. Learning Sub-function
3.2.1. Proxy ND and the NA Flags
3.3. Reply Sub-function
3.4. Unicast-Forward Sub-function
3.5. Maintenance Sub-function
3.6. Flood (to Remote PEs) Handling
3.7. Duplicate IP Detection
4. Solution Benefits
5. Deployment Scenarios
5.1. All Dynamic Learning
5.2. Dynamic Learning with Proxy ARP/ND
5.3. Hybrid Dynamic Learning and Static Provisioning with Proxy
ARP/ND
5.4. All Static Provisioning with Proxy ARP/ND
5.5. Example of Deployment in Internet Exchange Points
5.6. Example of Deployment in Data Centers
6. Security Considerations
7. IANA Considerations
8. References
8.1. Normative References
8.2. Informative References
Acknowledgments
Contributors
Authors' Addresses
As specified in [RFC7432], the IP Address field in the Ethernet Virtual Private Network (EVPN) Media Access Control (MAC) / IP Advertisement route may optionally carry one of the IP addresses associated with the MAC address. A Provider Edge (PE) may learn local IP->MAC pairs and advertise them in EVPN MAC/IP Advertisement routes. Remote PEs importing those routes in the same Broadcast Domain (BD) may add those IP->MAC pairs to their Proxy ARP/ND tables and reply to local ARP Requests or Neighbor Solicitations (or "unicast-forward" those packets to the owner MAC), reducing and even suppressing, in some cases, the flooding in the EVPN network.
[RFC7432]で指定されているように、イーサネットバーチャルプライベートネットワーク（EVPN）メディアアクセス制御（MAC）/ IPアドバタイズメントルートのIPアドレスフィールドは、MACアドレスに関連付けられているIPアドレスの1つを任意に運びます。プロバイダエッジ（PE）はローカルIP-> MACペアを学習し、EVPN MAC / IPアドバタイズメントルートでそれらをアドバタイズすることができます。リモートPEと同じブロードキャストドメイン（BD）内でそれらのルートをインポートすると、それらのIP-> MACペアをそれらのプロキシARP / NDテーブルに追加し、ローカルARP要求またはネイバーの勧誘（またはオーナーMacへの "ユニキャストフォワード"に返信することができます。そして、場合によっては、EVPNネットワークにおけるフラッディングを抑制しても抑制しても。
EVPN and its associated Proxy ARP/ND function are extremely useful in Data Centers (DCs) or Internet Exchange Points (IXPs) with large Broadcast Domains, where the amount of ARP/ND flooded traffic causes issues on connected routers and Customer Edges (CEs). [RFC6820] describes the address resolution problems in large DC networks.
EVPNとそれに関連するプロキシARP / ND関数は、データセンター（DC）またはインターネット交換ポイント（IXPS）または大規模なブロードキャストドメイン（IXPS）が非常に役立ちます。ここで、ARP / NDのあふれされたトラフィックの量が接続されたルータや顧客エッジ（CES）の問題を引き起こします。。[RFC6820]大きなDCネットワークにおけるアドレス解決の問題について説明します。
This document describes the Proxy ARP/ND function in [RFC7432] networks, augmented by the capability of the ARP/ND Extended Community [RFC9047]. From that perspective, this document updates [RFC7432].
このドキュメントでは、ARP / ND Extended Community [RFC9047]の機能によって拡張された[RFC7432]ネットワークのプロキシARP / ND機能について説明します。その観点から、この文書は[RFC7432]を更新します。
Proxy ARP/ND may be implemented to help IXPs, DCs, and other operators deal with the issues derived from address resolution in large Broadcast Domains.
プロキシARP / NDは、IXPS、DCS、および他のオペレータが大規模なブロードキャストドメインのアドレス解決に由来する問題を処理するのに役立ちます。
As described in [RFC6820], the IPv4 and IPv6 address resolution can create a lot of issues in large DCs. In particular, the issues created by IPv4 Address Resolution Protocol procedures may be significant.
[RFC6820]で説明されているように、IPv4とIPv6アドレスの解決は大きなDCで多くの問題を生み出す可能性があります。特に、IPv4アドレス解決プロトコル手順によって作成された問題は重要であり得る。
On one hand, ARP Requests use broadcast MAC addresses; therefore, any Tenant System in a large Broadcast Domain will see a large amount of ARP traffic, which is not addressed to most of the receivers.
一方では、ARP要求はブロードキャストMACアドレスを使用します。したがって、大容量ブロードキャストドメインのテナントシステムでは、ほとんどの受信機には対処されていない大量のARPトラフィックが表示されます。
On the other hand, the flooding issue becomes even worse if some Tenant Systems disappear from the Broadcast Domain, since some implementations will persistently retry sending ARP Requests. As [RFC6820] states, there are no clear requirements for retransmitting ARP Requests in the absence of replies; hence, an implementation may choose to keep retrying endlessly even if there are no replies.
一方、一部の実装は永続的にARP要求を送信することを永続的に再試行するため、いくつかのテナントシステムがブロードキャストドメインから消えてもフラッディングの問題がさらに悪化します。[RFC6820]の状態として、返信がない場合はARP要求を再送信するための明確な要件はありません。したがって、実装は、返信がなくても無限に再試行し続けることを選択できます。
The amount of flooding that address resolution creates can be mitigated by the use of EVPN and its Proxy ARP/ND function.
アドレス解決が作成する洪水の量はEVPNとそのプロキシARP/NDの機能を利用することによって緩和することができます。
The implementation described in this document is especially useful in IXP networks.
この文書に記載されている実施は、IXPネットワークにおいて特に役立ちます。
A typical IXP provides access to a large Layer 2 Broadcast Domain for peering purposes (referred to as "the peering network"), where (hundreds of) Internet routers are connected. We refer to these Internet routers as CE devices in this section. Because of the requirement to connect all routers to a single Layer 2 network, the peering networks use IPv4 addresses in length ranges from /21 to /24 (and even bigger for IPv6), which can create very large Broadcast Domains. This peering network is transparent to the CEs and therefore floods any ARP Requests or NS messages to all the CEs in the network. Gratuitous ARP and NA messages are flooded to all the CEs too.
典型的なIXPは、ピアリング目的（「ピアリングネットワーク」と呼ばれる）の大規模レイヤ2ブロードキャストドメインへのアクセスを提供し、ここで（数百の）インターネットルータが接続されている。このセクションのCEデバイスとしてこれらのインターネットルータを参照します。すべてのルータを単一のレイヤ2ネットワークに接続するための要件のために、ピアリングネットワークは/ 21から/ 24の長さの範囲のIPv4アドレス（そしてIPv6ではさらに大きな）で、非常に大きなブロードキャストドメインを作成できます。このピアリングネットワークはCESに対して透過的であり、したがってネットワーク内のすべてのCEにARP要求またはNSメッセージをフラッディングします。無償ARPとNAメッセージもすべてのCEにあふれています。
In these IXP networks, most of the CEs are typically peering routers and roughly all the Broadcast, Unknown Unicast, and Multicast (BUM) traffic is originated by the ARP and ND address resolution procedures. This ARP/ND BUM traffic causes significant data volumes that reach every single router in the peering network. Since the ARP/ND messages are processed in "slow path" software processors and they take high priority in the routers, heavy loads of ARP/ND traffic can cause some routers to run out of resources. CEs disappearing from the network may cause address resolution explosions that can make a router with limited processing power fail to keep BGP sessions running.
これらのIXPネットワークでは、ほとんどのCESは通常ピアリングルーターであり、すべてのブロードキャスト、不明ユニキャスト、およびマルチキャスト（BUM）トラフィックがARPおよびNDアドレス解決手順によって発信されます。このARP / ND BUMトラフィックは、ピアリングネットワーク内のすべての単一のルータに到達する重要なデータボリュームを引き起こします。ARP / NDメッセージは「スローパス」ソフトウェアプロセッサで処理され、ルータで優先順位が高くなりますので、ARP / NDトラフィックの負荷が大きな負荷がかかります。ネットワークから消えているCESは、BGPセッションを実行しておくことができないルータを制限されたルータを作ることができるアドレス解像度の爆発を引き起こす可能性があります。
The issue might be better in IPv6 routers if Multicast Listener Discovery (MLD) snooping was enabled, since ND uses an SN-multicast address in NS messages; however, ARP uses broadcast and has to be processed by all the routers in the network. Some routers may also be configured to broadcast periodic Gratuitous ARPs (GARPs) [RFC5227]. For IPv6, the fact that IPv6 CEs have more than one IPv6 address contributes to the growth of ND flooding in the network. The amount of ARP/ND flooded traffic grows linearly with the number of IXP participants; therefore, the issue can only grow worse as new CEs are added.
Multicast Listener Discovery（MLD）スヌーピングが有効になっている場合、問題はIPv6ルータでは優れている可能性があります.NDはNSメッセージでSNマルチキャストアドレスを使用しているためです。ただし、ARPはブロードキャストを使用しており、ネットワーク内のすべてのルータによって処理されます。一部のルータは、周期的な無償ARP（GARPS）[RFC5227]を放送するように構成されている可能性があります。IPv6の場合、IPv6 CESが複数のIPv6アドレスを持っているという事実は、ネットワーク内のNDフラッディングの成長に貢献します。ARP / NDのフラッディングトラフィックの量は、IXP参加者の数と直線的に増加します。したがって、問題は新しいCESが追加されるにつれて悪化することしかできません。
In order to deal with this issue, IXPs have developed certain solutions over the past years. While these solutions may mitigate the issues of address resolution in large Broadcast Domains, EVPN provides new more efficient possibilities to IXPs. EVPN and its Proxy ARP/ND function may help solve the issue in a distributed and scalable way, fully integrated with the PE network.
この問題に対処するために、IXPSは過去数年間で特定の解決策を発展させました。これらの解決策は、大規模なブロードキャストドメインのアドレス解決の問題を軽減するかもしれませんが、EVPNはIXPSに新しいより効率的な可能性を提供します。EVPNとそのプロキシARP / ND関数は、PEネットワークと完全に統合された、分散およびスケーラブルな方法で問題を解決するのに役立ちます。
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", "MAY", および "OPTIONAL" はBCP 14 [RFC2119] [RFC8174]で説明されているように、すべて大文字の場合にのみ解釈されます。
ARP: Address Resolution Protocol
ARP：アドレス解決プロトコル
AS-MAC: Anti-spoofing MAC. It is a special MAC configured on all the PEs attached to the same BD and used for the duplicate IP detection procedures.
AS-Mac：スプーフィング防止Mac。同じBDに接続され、重複したIP検出手順に使用されているすべてのPEに設定された特別なMACです。
BD: Broadcast Domain
BD：ブロードキャストドメイン
BUM: Broadcast, Unknown Unicast, and Multicast Layer 2 traffic
Bum：ブロードキャスト、不明ユニキャスト、およびマルチキャストレイヤ2トラフィック
CE: Customer Edge router
CE：カスタマーエッジルータ
DAD: Duplicate Address Detection, as per [RFC4861]
DAD：RFC4861のように、アドレス検出の重複アドレス検出
DC: Data Center
DC：データセンター
EVI: EVPN Instance
EVI：EVPNインスタンス
EVPN: Ethernet Virtual Private Network, as per [RFC7432]
EVPN：[RFC7432]のように、イーサネット仮想プライベートネットワーク
GARP: Gratuitous ARP
GARP：レートメス
IP->MAC: An IP address associated to a MAC address. IP->MAC entries are programmed in Proxy ARP/ND tables and may be of three different types: dynamic, static, or EVPN-learned.
IP-> MAC：MACアドレスに関連付けられているIPアドレス。IP-> MACエントリは、プロキシARP / NDテーブルでプログラムされており、動的、静的、またはEVPNを学んだ3つの異なるタイプでもよい。
IXP: Internet Exchange Point
IXP：インターネット交換ポイント
IXP-LAN: The IXP's large Broadcast Domain to where Internet routers are connected.
IXP-LAN：インターネットルーターが接続されているIXPの大きなブロードキャストドメイン。
LAG: Link Aggregation Group
LAG：リンクアグリゲーショングループ
MAC or IP DA: MAC or IP Destination Address
MACまたはIP DA：MACまたはIP宛先アドレス
MAC or IP SA: MAC or IP Source Address
MACまたはIP SA：MACまたはIPソースアドレス
ND: Neighbor Discovery
ND：ネイバーディスカバリー
NS: Neighbor Solicitation
NS：隣接勧誘
NA: Neighbor Advertisement
NA：近隣広告
NUD: Neighbor Unreachability Detection, as per [RFC4861]
NUD：近隣到達不能検出、[RFC4861]の通り
O Flag: Override Flag in NA messages, as per [RFC4861]
o flag：[RFC4861]に従って、NAメッセージのフラグを上書きします。
PE: Provider Edge router
PE：プロバイダエッジルータ
R Flag: Router Flag in NA messages, as per [RFC4861]
Rフラグ：[RFC4861]のように、NAメッセージのルータフラグ
RT2: EVPN Route type 2 or EVPN MAC/IP Advertisement route, as per [RFC7432]
RT2：EVPNルートタイプ2またはEVPN MAC / IPアドバタイズメントルート[RFC7432]
S Flag: Solicited Flag in NA messages, as per [RFC4861]
Sフラグ：[RFC4861]と同様に、NAメッセージの募集フラグ
SN-multicast address: Solicited-Node IPv6 multicast address used by NS messages
SNマルチキャストアドレス：NSメッセージで使用されているノードIPv6マルチキャストアドレス
TLLA: Target Link Layer Address, as per [RFC4861]
TLLA：ターゲットリンクレイヤアドレス[RFC4861]
VPLS: Virtual Private LAN Service
VPLS：仮想プライベートLANサービス
This document assumes familiarity with the terminology used in [RFC7432].
この文書は[RFC7432]で使用されている用語に精通しています。
Figure 1 illustrates an example EVPN network where the Proxy ARP/ND function is enabled.
図1は、プロキシARP / ND機能が有効になっている例示的なEVPNネットワークを示しています。
BD1
Proxy ARP/ND
+------------+
IP1/M1 +----------------------------+ |IP1->M1 EVPN|
GARP --->Proxy ARP/ND | |IP2->M2 EVPN|
+---+ +--------+ RT2(IP1/M1) | |IP3->M3 sta |
|CE1+------| BD1 | ------> +------+---|IP4->M4 dyn |
+---+ +--------+ | +------------+
PE1 | +--------+ Who has IP1?
| EVPN | | BD1 | <----- +---+
| EVI1 | | | -----> |CE3|
IP2/M2 | | | | IP1->M1 +---+
GARP --->Proxy ARP/ND | +--------+ | IP3/M3
+---+ +--------+ RT2(IP2/M2) | |
|CE2+----| BD1 | ------> +--------------+
+---+ +--------+ PE3| +---+
PE2 | +----+CE4|
+----------------------------+ +---+
<---IP4/M4 GARP
Figure 1: Proxy ARP/ND Network Example
図1：プロキシARP / NDネットワークの例
When the Proxy ARP/ND function is enabled in a BD (Broadcast Domain) of the EVPN PEs, each PE creates a Proxy table specific to that BD that can contain three types of Proxy ARP/ND entries:
EVPN PEのBD（ブロードキャストドメイン）でプロキシARP / ND機能が有効になっている場合、各PEは、3種類のプロキシARP / NDエントリを含むことができるBDに固有のプロキシテーブルを作成します。
Dynamic entries: Learned by snooping a CE's ARP and ND messages; for instance, see IP4->M4 in Figure 1.
動的エントリ：CEのARPおよびNDメッセージをスヌーピングすることによって学びました。たとえば、図1のIP4-> M4を参照してください。
Static entries: Provisioned on the PE by the management system; for instance, see IP3->M3 in Figure 1.
静的エントリ：管理システムによってPEにプロビジョニングされました。たとえば、図1のIP3-> M3を参照してください。
EVPN-learned entries: Learned from the IP/MAC information encoded in the received RT2's coming from remote PEs; for instance, see IP1->M1 and IP2->M2 in Figure 1.
EVPN学習エントリ：受信したRT2でエンコードされたIP / MAC情報からリモートPESからの学習。たとえば、図1のIP1-> M1、IP2-> M2を参照してください。
As a high-level example, the operation of the EVPN Proxy ARP/ND function in the network of Figure 1 is described below. In this example, we assume IP1, IP2, and IP3 are IPv4 addresses:
高レベルの例として、図1のネットワークにおけるEVPNプロキシARP / ND機能の動作について説明する。この例では、IP1、IP2、およびIP3はIPv4アドレスです。
1. Proxy ARP/ND is enabled in BD1 of PE1, PE2, and PE3.
1. PE1、PE2、およびPE3のBD1でプロキシARP / NDが有効になっています。
2. The PEs start adding dynamic, static, and EVPN-learned entries to their Proxy tables:
2. PESは、動的、静的、およびEVPN学習エントリをプロキシテーブルに追加します。
a. PE3 adds IP1->M1 and IP2->M2 based on the EVPN routes received from PE1 and PE2. Those entries were previously learned as dynamic entries in PE1 and PE2, respectively, and advertised in BGP EVPN.
a. PE3は、PE1とPE2から受信したEVPNルートに基づいてIP1-> M1とIP2-> M2を追加します。これらのエントリは以前はPE1とPE2の動的エントリとしてそれぞれ学習され、BGP EVPNで宣伝されていました。
b. PE3 adds IP4->M4 as dynamic. This entry is learned by snooping the corresponding ARP messages sent by CE4.
b. PE3は動的としてIP4-> M4を追加します。このエントリは、CE4によって送信された対応するARPメッセージをスヌーピングすることによって学習されます。
c. An operator also provisions the static entry IP3->M3.
c. オペレータは静的エントリIP3-> M3を規定しています。
3. When CE3 sends an ARP Request asking for the MAC address of IP1, PE3 will:
3. CE3はIP1のMACアドレスを尋ねるARPリクエストを送信すると、PE3は以下となります。
a. Intercept the ARP Request and perform a Proxy ARP lookup for IP1.
a. ARP要求を傍受し、IP1のプロキシARP検索を実行します。
b. If the lookup is successful (as in Figure 1), PE3 will send an ARP Reply with IP1->M1. The ARP Request will not be flooded to the EVPN network or any other local CEs.
b. ルックアップが成功した場合（図1のように）、PE3はIP1-> M1でARP応答を送信します。ARP要求はEVPNネットワークまたは他のどのローカルCEにあふれされません。
c. If the lookup is not successful, PE3 will flood the ARP Request in the EVPN network and the other local CEs.
c. ルックアップが成功しなかった場合、PE3はEVPNネットワークと他のローカルCESでARP要求をフラッディングします。
In the same example, if we assume IP1, IP2, IP3, and IP4 are now IPv6 addresses and Proxy ARP/ND is enabled in BD1:
同じ例では、IP1、IP2、IP3、およびIP4がIPv6アドレスにあると仮定した場合は、BD1でプロキシARP / NDが有効になっています。
1. PEs will start adding entries in a similar way as they would for IPv4; however, there are some differences:
1. PESは、IPv4の場合と同様の方法でエントリを追加し始めます。ただし、いくつかの違いがあります。
a. IP1->M1 and IP2->M2 are learned as dynamic entries in PE1 and PE2, respectively, by snooping NA messages and not by snooping NS messages. In the IPv4 case, any ARP frame can be snooped to learn the dynamic Proxy ARP entry. When learning the dynamic entries, the R and O Flags contained in the snooped NA messages will be added to the Proxy ND entries too.
a. IP1-> M1とIP2-> M2は、NAメッセージをスヌーピングしてNSメッセージをスヌーピングすることによって、それぞれPE1およびPE2の動的エントリとして学習されます。IPv4ケースでは、どのようなARPフレームをスヌーピングして動的プロキシARPエントリを学習できます。動的エントリを学習するときは、スヌープされたNAメッセージに含まれるRフラグとOフラグがプロキシNDエントリに追加されます。
b. PE1 and PE2 will advertise those entries in EVPN MAC/IP Advertisement routes, including the corresponding learned R and O Flags in the ARP/ND Extended Community.
b. PE1およびPE2は、ARP / ND拡張コミュニティの対応する学習されたRフラグおよびOフラグを含む、EVPN MAC / IPアドバタイズメントルートにそれらのエントリを宣伝します。
c. PE3 also adds IP4->M4 as dynamic after snooping an NA message sent by CE4.
c. PE3はまた、CE4によって送信されたNAメッセージをスヌーピングした後、IP4-> M4を動的に追加します。
2. When CE3 sends an NS message asking for the MAC address of IP1, PE3 behaves as in the IPv4 example, by intercepting the NS, performing a lookup on the IP, and replying with an NA if the lookup is successful. If it is successful, the NS is not flooded to the EVPN PEs or any other local CEs.
2. CE3がIP1のMACアドレスを尋ねるNSメッセージを送信すると、PE3は、NSを傍受し、IPの検索を実行し、ルックアップが成功した場合にNAで返信することによって、IPv4の例のように動作します。それが成功した場合、NSはEVPN PEまたはその他のローカルCEにあふれていません。
3. If the lookup is not successful, PE3 will flood the NS to remote EVPN PEs attached to the same BD and the other local CEs as in the IPv4 case.
3. ルックアップが成功しなかった場合、PE3は、同じBDに接続されているリモートEVPN PEとIPv4の場合と同じように、他のローカルCESにNSをフラッディングします。
As PE3 learns more and more host entries in the Proxy ARP/ND table, the flooding of ARP Request messages among PEs is reduced and in some cases, it can even be suppressed. In a network where most of the participant CEs are not moving between PEs and are advertising their presence with GARPs or unsolicited-NA messages, the ARP/ND flooding among PEs, as well as the unknown unicast flooding, can practically be suppressed. In an EVPN-based IXP network, where all the entries are static, the ARP/ND flooding among PEs is in fact totally suppressed.
PE3がPROSY ARP / NDテーブル内のより多くのホストエントリを学習すると、PES間のARP要求メッセージのフラッディングが減少し、場合によっては抑制することができます。ほとんどの参加者CESがPES間で移動していないネットワークでは、GARPSまたは迷惑なNAメッセージで存在を宣伝しているネットワークでは、PES間のARP / NDフラッディング、および未知のユニキャストフラッディングは実際に抑制できます。EVPNベースのIXPネットワークでは、すべてのエントリが静的である場合、PE間のARP / NDフラッディングは実際には完全に抑制されます。
In a network where CEs move between PEs, the Proxy ARP/ND function relies on the CE signaling its new location via GARP or unsolicited-NA messages so that tables are immediately updated. If a CE moves "silently", that is, without issuing any GARP or NA message upon getting attached to the destination PE, the mechanisms described in Section 3.5 make sure that the Proxy ARP/ND tables are eventually updated.
CESがPE間で移動するネットワークでは、プロキシARP / ND機能は、テーブルがすぐに更新されるように、GARPまたは迷惑なNAメッセージを介してその新しい場所をシグナリングするCEに依存しています。CEが「静かに」移動すると、宛先PEに添付されているときにGARPまたはNAメッセージを発行することなく、セクション3.5に記載されているメカニズムは、プロキシARP / NDテーブルが最終的に更新されていることを確認します。
The Proxy ARP/ND function can be structured in six sub-functions or procedures:
プロキシARP / ND機能は、6つのサブ機能または手順で構成できます。
1. Learning sub-function
1. 学習サブ機能
2. Reply sub-function
2. 返信サブ機能
3. Unicast-forward sub-function
3. ユニキャストフォワードサブ機能
4. Maintenance sub-function
4. メンテナンスサブ機能
5. Flood handling sub-function
5. 洪水処理サブ機能
6. Duplicate IP detection sub-function
6. 重複IP検出サブ機能
A Proxy ARP/ND implementation MUST at least support the Learning, Reply, Maintenance, and duplicate IP detection sub-functions. The following sections describe each individual sub-function.
プロキシARP / ND実装は、少なくとも学習、返信、保守、および重複したIP検出サブ機能をサポートしなければなりません。次のセクションでは、各個別のサブ機能について説明します。
A Proxy ARP/ND implementation in an EVPN BD MUST support dynamic and EVPN-learned entries and SHOULD support static entries.
EVPN BDのプロキシARP / ND実装は、動的およびEVPN学習エントリをサポートし、静的エントリをサポートする必要があります。
Static entries are provisioned from the management plane. A static entry is configured on the PE attached to the host using the IP address in that entry. The provisioned static IP->MAC entry MUST be advertised in EVPN with an ARP/ND Extended Community where the Immutable ARP/ND Binding Flag (I) is set to 1, as per [RFC9047]. When the I Flag in the ARP/ND Extended Community is 1, the advertising PE indicates that the IP address must not be associated to a MAC other than the one included in the EVPN MAC/IP Advertisement route. The advertisement of I = 1 in the ARP/ND Extended Community is compatible with any value of the Sticky bit (S) or sequence number in the [RFC7432] MAC Mobility Extended Community. Note that the I bit in the ARP/ND Extended Community refers to the immutable configured association between the IP and the MAC address in the IP->MAC binding, whereas the S bit in the MAC Mobility Extended Community refers to the fact that the advertised MAC address is not subject to the [RFC7432] mobility procedures.
静的エントリは管理プレーンからプロビジョニングされています。そのエントリ内のIPアドレスを使用して、ホストに接続されているPEに静的エントリが設定されています。プロビジョニングされた静的IP-> MACエントリは、[RFC9047]に従って、不変のARP / NDバインディングフラグ（I）が1に設定されているARP / ND拡張コミュニティを使用してEVPNでアドバタイズする必要があります。 ARP / ND拡張コミュニティのIフラグが1である場合、広告PEは、IPアドレスがEVPN MAC / IPアドバタイズメントルートに含まれるもの以外のMACに関連付けてはならないことを示す。 ARP / ND拡張コミュニティのI = 1の広告は、[RFC7432] MACモビリティ拡張コミュニティのスティッキビットまたはシーケンス番号の任意の値と互換性があります。 ARP / ND拡張コミュニティのIビットは、IP-> MACバインディング内のIPとMACアドレスとの間の不変の設定された関連付けを指し、MACモビリティ拡張コミュニティのSビットは、宣伝が言及されたという事実を指します。 MACアドレスは、[RFC7432]モビリティ手順の対象となりません。
An entry may associate a configured static IP to a list of potential MACs, i.e., IP1->(MAC1,MAC2..MACN). Until a frame (including a local ARP/NA message) is received from the CE, the PE will not advertise any IP1->MAC in EVPN. Upon receiving traffic from the CE, the PE will check that the source MAC, e.g., MAC1, is included in the list of allowed MACs. Only in that case, the PE will activate the IP1->MAC1 and advertise only that IP1 and MAC1 in an EVPN MAC/IP Advertisement route.
エントリは、設定された静的IPを潜在的なMAC、すなわちIP1 - >（MAC1、MAC2..MACN）のリストに関連付けることができる。CEからフレーム（ローカルARP / NAメッセージを含む）が受信されるまで、PEはEVPNでIP1-> Macをアドバタイズしません。CEからトラフィックを受信すると、PEは、ソースMAC、例えばMAC1が許可されたMACのリストに含まれていることを確認する。その場合のみ、PEはIP1-> MAC1を有効にし、そのIP1とMAC1のみをEVPN MAC / IPアドバタイズメントルートでアドバタイズします。
The PE MUST create EVPN-learned entries from the received valid EVPN MAC/IP Advertisement routes containing a MAC and IP address.
PEは、MACおよびIPアドレスを含む受信した有効なEVPN MAC / IPアドバタイズメントルートからEVPN学習エントリを作成する必要があります。
Dynamic entries are learned in different ways depending on whether the entry contains an IPv4 or IPv6 address:
エントリにIPv4またはIPv6アドレスが含まれているかどうかによって、動的エントリはさまざまな方法で学習されます。
Proxy ARP dynamic entries: The PE MUST snoop all ARP packets (that is, all frames with Ethertype 0x0806) received from the CEs attached to the BD in order to learn dynamic entries. ARP packets received from remote EVPN PEs attached to the same BD are not snooped. The Learning function will add the sender MAC and sender IP of the snooped ARP packet to the Proxy ARP table. Note that a MAC or an IP address with value 0 SHOULD NOT be learned.
プロキシARP動的エントリ：PEは、動的エントリを学習するためにBDに接続されているCEから受信したすべてのARPパケット（つまり、EtherType 0x0806を含むすべてのフレーム）をスヌープする必要があります。同じBDに接続されているリモートEVPN PEから受信したARPパケットはスヌープされていません。学習機能は、スヌープARPパケットの送信者MACと送信者IPをProxy ARPテーブルに追加します。値0のMACまたはIPアドレスは学習しないでください。
Proxy ND dynamic entries: The PE MUST snoop the NA messages (Ethertype 0x86dd, ICMPv6 type 136) received from the CEs attached to the BD and learn dynamic entries from the Target Address and TLLA information. NA messages received from remote EVPN PEs are not snooped. A PE implementing Proxy ND as in this document MUST NOT create dynamic IP->MAC entries from NS messages because they don't contain the R Flag required by the Proxy ND reply function. See Section 3.2.1 for more information about the R Flag.
プロキシND動的エントリ：PEは、BDに接続されているCEから受信したNAメッセージ（EtherType 0x86DD、ICMPv6タイプ136）をスヌープし、ターゲットアドレスとTLLA情報から動的エントリを学習する必要があります。リモートEVPN PESから受信したNAメッセージはスヌープされていません。この文書のようにプロキシNDを実装するPEは、プロキシND Reply関数に必要なRフラグを含まないため、NSメッセージから動的IP> MACエントリを作成してはなりません。Rフラグの詳細については、セクション3.2.1を参照してください。
This document specifies an "anycast" capability that can be configured for the Proxy ND function of the PE and affects how dynamic Proxy ND entries are learned based on the O Flag of the snooped NA messages. If the O Flag is zero in the received NA message, the IP->MAC SHOULD only be learned in case the IPv6 "anycast" capability is enabled in the BD. Irrespective, an NA message with O Flag = 0 will be normally forwarded by the PE based on a MAC DA lookup.
この文書では、PEのプロキシND機能用に構成することができる「エニーキャスト」機能を指定し、ダイナミックプロキシNDエントリはNAメッセージを詮索のOフラグに基づいて学習される方法に影響します。Oフラグは、受信NAメッセージ内のゼロの場合は、IP->MACSHOULDはIPv6のみ「エニーキャスト」機能がBDで有効になっている場合で学んだこと。かかわらず、Oフラグ=0とNAメッセージが正常にMACDAルックアップに基づいてPEによって転送されるであろう。
The following procedure associated to the Learning sub-function is RECOMMENDED:
学習サブ機能に関連付けられている以下の手順をお勧めします。
* When a new Proxy ARP/ND EVPN or static active entry is learned (or provisioned), the PE SHOULD send a GARP or unsolicited-NA message to all the connected access CEs. The PE SHOULD send a GARP or unsolicited-NA message for dynamic entries only if the ARP/NA message that previously created the entry on the PE was NOT flooded to all the local connected CEs before. This GARP/ unsolicited-NA message makes sure the CE ARP/ND caches are updated even if the ARP/NS/NA messages from CEs connected to remote PEs are not flooded in the EVPN network.
* 新しいプロキシARP / ND EVPNまたは静的アクティブエントリが学習（またはプロビジョニングされている）が発生した場合、PEはすべての接続されたアクセスCESにGARPまたは迷惑なNAメッセージを送信する必要があります。PEは動的エントリのためにGARPまたは迷惑なNAメッセージを送信する必要があります。これまでPE上のエントリを作成したARP / NAメッセージが以前にすべてのローカル接続されたCESにあふれていない場合にのみ、PEは動的エントリに送信されます。このGARP /迷惑なNAメッセージは、リモートPEに接続されているARP / NS / NAメッセージがEVPNネットワークであふれていない場合でも、CE ARP / NDキャッシュが更新されていることを確認します。
Note that if a static entry is provisioned with the same IP as an existing EVPN-learned or dynamic entry, the static entry takes precedence.
静的エントリが既存のEVPN学習または動的エントリと同じIPを使用してプロビジョニングされている場合、静的エントリは優先されます。
In case of a PE reboot, the static and EVPN entries will be re-added as soon as the PE is back online and receives all the EVPN routes for the BD. However, the dynamic entries will be gone. Due to that reason, new NS and ARP Requests will be flooded by the PE to remote PEs and dynamic entries gradually relearned again.
PEの再起動の場合、PEがオンラインに戻ってBDのすべてのEVPNルートを受信するとすぐに静的およびEVPNエントリが再び追加されます。ただし、動的エントリはなくなりました。そのため、新しいNSおよびARP要求はPEによってリモートPESにフラッディングされ、動的エントリは再び再び再生されます。
[RFC4861] describes the use of the R Flag in IPv6 address resolution:
[RFC4861] IPv6アドレス解決におけるRフラグの使用方法について説明します。
* Nodes capable of routing IPv6 packets must reply to NS messages with NA messages where the R Flag is set (R Flag = 1).
* IPv6パケットをルーティングすることができるノードは、Rフラグが設定されているNAメッセージを含むNSメッセージに返信する必要があります（R FLAG = 1）。
* Hosts that are not able to route IPv6 packets must indicate that inability by replying with NA messages that contain R Flag = 0.
* IPv6パケットをルーティングできないホストは、Rフラグ= 0を含むNAメッセージで返信することによって不可能であることを示している必要があります。
The use of the R Flag in NA messages has an impact on how hosts select their default gateways when sending packets off-link, as per [RFC4861]:
NAメッセージ内のRフラグを使用すると、[RFC4861]に従って、オフリンクの送信時にホストがデフォルトゲートウェイを選択する方法に影響を与えます。
* Hosts build a Default Router List based on the received RAs and NAs with R Flag = 1. Each cache entry has an IsRouter flag, which must be set for received RAs and is set based on the R Flag in the received NAs. A host can choose one or more Default Routers when sending packets off-link.
* ホストは、RAS = 1のRASとNASに基づいてデフォルトのルータリストを作成します.1。各キャッシュエントリにはISROUTERフラグがあります。これは受信RASに設定する必要があり、受信したNAS内のRフラグに基づいて設定されます。ホストは、パケットのオフリンクを送信するときに1つ以上のデフォルトルータを選択できます。
* In those cases where the IsRouter flag changes from TRUE to FALSE as a result of an NA update, the node must remove that router from the Default Router List and update the Destination Cache entries for all destinations using that neighbor as a router, as specified in Section 7.3.3 of [RFC4861]. This is needed to detect when a node that is used as a router stops forwarding packets due to being configured as a host.
* NAアップデートの結果としてISROUTERフラグがTRUEからFALSEに変わる場合、ノードはデフォルトのルータリストからそのルータを削除し、そのネイバーを使用してすべての宛先の宛先キャッシュエントリをルータとして更新する必要があります。[RFC4861]のセクション7.3.3。これは、ルータとして使用されるノードがホストとして設定されているため、パケットの転送を停止するときに検出する必要があります。
The R and O Flags for a Proxy ARP/ND entry will be learned in the following ways:
プロキシARP / NDエントリのRフラグとOフラグは、次のようにして学習されます。
* The R Flag information SHOULD be added to the static entries by the management interface. The O Flag information MAY also be added by the management interface. If the R and O Flags are not configured, the default value is 1.
* Rフラグ情報は、管理インターフェイスによって静的エントリに追加されるべきです。OFFフラグ情報も管理インタフェースによって追加されてもよい。RフラグとOフラグが構成されていない場合、デフォルト値は1です。
* Dynamic entries SHOULD learn the R Flag and MAY learn the O Flag from the snooped NA messages used to learn the IP->MAC itself.
* 動的エントリはRフラグを学ぶべきであり、IP-> Mac自体を学ぶために使用されたスヌーポのNAメッセージからoフラグを学ぶことができます。
* EVPN-learned entries SHOULD learn the R Flag and MAY learn the O Flag from the ARP/ND Extended Community [RFC9047] received from EVPN along with the RT2 used to learn the IP->MAC itself. If no ARP/ND Extended Community is received, the PE will add a configured R Flag / O Flag to the entry. These configured R and O Flags MAY be an administrative choice with a default value of 1. The configuration of this administrative choice provides a backwards-compatible option with EVPN PEs that follow [RFC7432] but do not support this specification.
* EVPN学習エントリはRフラグを学ぶべきであり、IP-> Mac自体を学ぶために使用されたRT2と共にEVPNから受信したARP / ND拡張コミュニティ[RFC9047]からOフラグを学ぶことができます。ARP / ND拡張コミュニティが受信されていない場合、PEはエントリに設定されたR FLAG / Oフラグを追加します。これらの設定されたRフラグとOフラグは、デフォルト値1を持つ管理者の選択である可能性があります。この管理者選択の設定は、[RFC7432]に続くが、この仕様をサポートしていません。
Note that, typically, IP->MAC entries with O = 0 will not be learned; therefore, the Proxy ND function will reply to NS messages with NA messages that contain O = 1. However, this document allows the configuration of the "anycast" capability in the BD where the Proxy ND function is enabled. If "anycast" is enabled in the BD and an NA message with O = 0 is received, the associated IP->MAC entry will be learned with O = 0. If this "anycast" capability is enabled in the BD, duplicate IP detection must be disabled so that the PE is able to learn the same IP mapped to different MACs in the same Proxy ND table. If the "anycast" capability is disabled, NA messages with O Flag = 0 will not create a Proxy ND entry (although they will be forwarded normally); hence, no EVPN advertisement with ARP/ND Extended Community will be generated.
通常、O = 0のIP-> MACエントリは学習されません。したがって、プロキシND関数は、O = 1を含むNAメッセージを使用してNSメッセージに返信します。ただし、このドキュメントでは、プロキシND機能が有効になっているBD内の「Anycast」機能を構成できます。BDで "Anycast"が有効になっており、O = 0でNAメッセージが受信された場合、関連するIP-> MACエントリはO = 0で学習されます。この「エニーキャスト」機能がBDで有効になっている場合、重複IP検出PEが同じプロキシNDテーブル内の異なるMACにマッピングされた同じIPを学習できるように、無効にする必要があります。「Anycast」機能が無効になっている場合、o flag = 0のNAメッセージはプロキシNDエントリを作成しません（通常転送されます）。したがって、ARP / ND拡張コミュニティを備えたEVPN広告は生成されません。
This sub-function will reply to address resolution requests/ solicitations upon successful lookup in the Proxy ARP/ND table for a given IP address. The following considerations should be taken into account, assuming that the ARP Request / NS lookup hits a Proxy ARP/ ND entry IP1->MAC1:
このサブ関数は、特定のIPアドレスのプロキシARP / NDテーブルにルックアップが成功すると、アドレス解決要求/呼び出しに応答します。ARP Request / NSルックアップがプロキシARP / NDエントリIP1-> MAC1にヒットすると仮定すると、次の考慮事項を考慮に入れる必要があります。
a. When replying to ARP Requests or NS messages:
a. ARPリクエストまたはNSメッセージに返信するとき
* The PE SHOULD use the Proxy ARP/ND entry MAC address MAC1 as MAC SA. This is RECOMMENDED so that the resolved MAC can be learned in the MAC forwarding database of potential Layer 2 switches sitting between the PE and the CE requesting the address resolution.
* PEは、Mac SAとしてプロキシARP / NDエントリMACアドレスMAC1を使用する必要があります。これは、解決されたMACがPEとアドレス解決を要求するCEとの間に座っている潜在的なレイヤ2スイッチのMAC転送データベースで学習できるように推奨されます。
* For an ARP reply, the PE MUST use the Proxy ARP entry IP1 and MAC1 addresses in the sender Protocol Address and Hardware Address fields, respectively.
* ARP応答の場合、PEはそれぞれ送信者プロトコルアドレスフィールドおよびハードウェアアドレスフィールドにそれぞれプロキシARPエントリIP1およびMAC1アドレスを使用する必要があります。
* For an NA message in response to an address resolution NS or DAD NS, the PE MUST use IP1 as the IP SA and Target Address. M1 MUST be used as the Target Link Local Address (TLLA).
* アドレス解決NSまたはDAD NSに応答してNAメッセージの場合、PEはIP1をIP SAおよびターゲットアドレスとして使用する必要があります。M1はターゲットリンクローカルアドレス（TLLA）として使用する必要があります。
b. A PE SHOULD NOT reply to a request/solicitation received on the same attachment circuit over which the IP->MAC is learned. In this case, the requester and the requested IP are assumed to be connected to the same Layer 2 CE/access network linked to the PE's attachment circuit; therefore, the requested IP owner will receive the request directly.
b. PEは、IP-> MACが学習された同じ添付回路で受信された要求/勧誘に返信しないでください。この場合、リクエスタと要求されたIPは、PEの取り付け回路にリンクされているのと同じ層2のCE /アクセスネットワークに接続されていると仮定される。したがって、要求されたIP所有者は直接要求を受け取ります。
c. A PE SHOULD reply to broadcast/multicast address resolution messages, i.e., ARP Requests, ARP probes, NS messages, as well as DAD NS messages. An ARP probe is an ARP Request constructed with an all-zero sender IP address that may be used by hosts for IPv4 Address Conflict Detection as specified in [RFC5227]. A PE SHOULD NOT reply to unicast address resolution requests (for instance, NUD NS messages).
c. PEは、ブロードキャスト/マルチキャストアドレス解決メッセージ、すなわちARP要求、ARPプローブ、NSメッセージ、およびDAD NSメッセージに返信する必要があります。ARPプローブは、[RFC5227]で指定されているように、IPv4アドレス競合検出用のホストで使用できるすべてのゼロの送信者IPアドレスで構成されたARP要求です。PEはユニキャストアドレス解決要求に返信しないでください（たとえば、NUD NSメッセージ）。
d. When replying to an NS, a PE SHOULD set the Flags in the NA messages as follows:
d. NSに返信するとき、PEはNAメッセージ内のフラグを次のように設定する必要があります。
* The R bit is set as it was learned for the IP->MAC entry in the NA messages that created the entry (see Section 3.2.1).
* Rビットは、エントリを作成したNAメッセージ内のIP-> MACエントリの場合、それが学習されたときに設定されます（セクション3.2.1を参照）。
* The S Flag will be set/unset as per [RFC4861].
* Sフラグは[RFC4861]に従って設定/設定されます。
* The O Flag will be set in all the NA messages issued by the PE except in the case in which the BD is configured with the "anycast" capability and the entry was previously learned with O = 0. If "anycast" is enabled and there is more than one MAC for a given IP in the Proxy ND table, the PE will reply to NS messages with as many NA responses as "anycast" entries there are in the Proxy ND table.
* oフラグは、BDが「Anycast」機能で構成されている場合を除き、PEによって発行されたすべてのNAメッセージに設定され、エントリがO = 0でo = 0で実行されていた場合に設定されます。PROSY NDテーブルで特定のIPのMACが複数のMACであるため、PEは、プロキシNDテーブルにある「Anycast」エントリと同じ数のNAレスポンスを使用してNSメッセージに返信します。
e. For Proxy ARP, a PE MUST only reply to ARP Requests with the format specified in [RFC0826].
e. プロキシARPの場合、PEは[RFC0826]で指定された形式でARP要求にのみ返信する必要があります。
f. For Proxy ND, a PE MUST reply to NS messages with known options with the format and options specified in [RFC4861] and MAY reply, discard, forward, or unicast-forward NS messages containing other options. An administrative choice to control the behavior for received NS messages with unknown options ("reply", "discard", "unicast-forward", or "forward") MAY be supported.
f. プロキシNDの場合、PEは[RFC4861]で指定された形式とオプションを使用して既知のオプションを使用してNSメッセージに返信する必要があり、他のオプションを含む応答、破棄、転送、またはユニキャストフォワードメッセージを返信してください。未知のオプション（「返信」、「破棄」、「Unicast-Forward」、または「Forward」）を持つNSメッセージの動作を制御する管理選択はサポートされている可能性があります。
* The "reply" option implies that the PE ignores the unknown options and replies with NA messages, assuming a successful lookup on the Proxy ND table. An unsuccessful lookup will result in a "forward" behavior (i.e., flood the NS message based on the MAC DA).
* 「応答」オプションは、PROが不明なオプションを無視し、プロキシNDテーブルの検索が成功したと仮定して、NAメッセージで返信することを意味します。失敗したルックアップは「前方」動作をもたらす（すなわち、MAC DAに基づいてNSメッセージをフラッディングする）。
* If "discard" is available, the operator should assess if flooding NS unknown options may be a security risk for the EVPN BD (and if so, enable "discard") or, on the contrary, if not forwarding/flooding NS unknown options may disrupt connectivity. This option discards NS messages with unknown options irrespective of the result of the lookup on the Proxy ND table.
* 「廃棄」が利用可能な場合、オペレータは、NS未知のオプションがEVPN BDのセキュリティリスクである可能性があるかどうかを評価する必要があります（そうであれば、「廃棄」を有効にする）、または反対に、転送/フラッディングNS未知のオプションがある場合は接続性を乱す。このオプションは、プロキシNDテーブルへのルックアップの結果に関係なく、不明なオプションを持つNSメッセージを破棄します。
* The "unicast-forward" option is described in Section 3.4.
* 「ユニキャストフォワード」オプションはセクション3.4で説明されています。
* The "forward" option implies flooding the NS message based on the MAC DA. This option forwards NS messages with unknown options irrespective of the result of the lookup on the Proxy ND table. The "forward" option is RECOMMENDED by this document.
* 「Forward」オプションは、MAC DAに基づいてNSメッセージをフラッディングすることを意味します。このオプションは、プロキシNDテーブルへのルックアップの結果に関係なく、NSメッセージを不明なオプションで転送します。このドキュメントでは「Forward」オプションをお勧めします。
As discussed in Section 3.3, in some cases, the operator may want to "unicast-forward" certain ARP Requests and NS messages as opposed to reply to them. The implementation of a "unicast-forward" function is RECOMMENDED. This option can be enabled with one of the following parameters:
セクション3.3で説明したように、場合によっては、オペレータは、それらに返信するのに対照的に、特定のARP要求およびNSメッセージを「ユニキャスト」にすることをお勧めします。「ユニキャストフォワード」機能の実装をお勧めします。このオプションは、次のいずれかのパラメータで有効にできます。
a. unicast-forward always
a. 常にユニキャストフォワード
b. unicast-forward unknown-options
b. ユニキャストフォワード不明 - オプション
If "unicast-forward always" is enabled, the PE will perform a Proxy ARP/ND table lookup and, in case of a hit, the PE will forward the packet to the owner of the MAC found in the Proxy ARP/ND table. This is irrespective of the options carried in the ARP/ND packet. This option provides total transparency in the BD and yet reduces the amount of flooding significantly.
「ユニキャストフォワード常時」が有効になっている場合、PEはプロキシARP / NDテーブルルックアップを実行し、ヒットの場合、PEはパケットをプロキシARP / NDテーブルにあるMACの所有者に転送します。これはARP / NDパケットで運ばれるオプションに関係なくです。このオプションはBDの全透明性を提供し、それでも洪水の量を大幅に削減します。
If "unicast-forward unknown-options" is enabled, upon a successful Proxy ARP/ND lookup, the PE will perform a "unicast-forward" action only if the ARP Requests or NS messages carry unknown options, as explained in Section 3.3. The "unicast-forward unknown-options" configuration allows the support of new applications using ARP/ND in the BD while still reducing the flooding.
「Unicast-Forward Unknown-Options」が有効になっている場合、プロキシARP / NDルックアップが成功すると、PEは、3.3項で説明されているように、ARP要求またはNSメッセージが未知のオプションを持つ場合にのみ「ユニキャスト」アクションを実行します。「Unicast-Forward Unknown-Options」設定では、まだフラッディングを減らしながら、BDでARP / NDを使用している新しいアプリケーションをサポートできます。
Irrespective of the enabled option, if there is no successful Proxy ARP/ND lookup, the unknown ARP Request / NS message will be flooded in the context of the BD, as per Section 3.6.
有効なオプションにかかわらず、プロキシARP / NDルックアップが成功しなかった場合、未知のARP要求/ NSメッセージは、セクション3.6に従ってBDのコンテキストでフラッディングされます。
The Proxy ARP/ND tables SHOULD follow a number of maintenance procedures so that the dynamic IP->MAC entries are kept if the owner is active and flushed (and the associated RT2 withdrawn) or if the owner is no longer in the network. The following procedures are RECOMMENDED:
Proxy ARP / NDテーブルは、所有者がアクティブでフラッシュされ（および関連付けられているRT2が引き出された場合）、または所有者がネットワーク内でなくなった場合に、動的IP-> MACエントリが保持されるように、いくつかのメンテナンス手順に従います。以下の手順をお勧めします。
Age-time: A dynamic Proxy ARP/ND entry MUST be flushed out of the table if the IP->MAC has not been refreshed within a given age-time. The entry is refreshed if an ARP or NA message is received for the same IP->MAC entry. The age-time is an administrative option, and its value should be carefully chosen depending on the specific use case; in IXP networks (where the CE routers are fairly static), the age-time may normally be longer than in DC networks (where mobility is required).
age-time：IP-> MACが特定の年齢内に更新されていない場合、動的プロキシARP / NDエントリをテーブルからフラッシュする必要があります。ARPまたはNAメッセージが同じIP-> MACエントリに対して受信された場合、エントリは更新されます。年齢は管理オプションであり、その値は特定のユースケースに応じて慎重に選択されるべきです。IXPネットワーク（CEルータがかなり静的な場合）では、時刻は通常DCネットワークでより長くなります（モビリティが必要です）。
Send-refresh option: The PE MAY send periodic refresh messages (ARP/ND "probes") to the owners of the dynamic Proxy ARP/ND entries, so that the entries can be refreshed before they age out. The owner of the IP->MAC entry would reply to the ARP/ND probe and the corresponding entry age-time reset. The periodic send-refresh timer is an administrative option and is RECOMMENDED to be a third of the age-time or a half of the age-time in scaled networks.
SEND-REFRESHオプション：PEは、動的プロキシARP / NDエントリの所有者に定期的なリフレッシュメッセージ（ARP / ND "プローブ"）を送信することができるので、エントリはエージング前に更新できます。IP-> MACエントリの所有者は、ARP / NDプローブ、対応するエントリ時代のリセットに返信します。定期送信リフレッシュタイマは管理オプションであり、スケーリングされたネットワークにおける年齢の3分の1または年齢の半分のものになることをお勧めします。
An ARP refresh issued by the PE will be an ARP Request message with the sender's IP = 0 sent from the PE's MAC SA. If the PE has an IP address in the subnet, for instance, on an Integrated Routing and Bridging (IRB) interface, then it MAY use it as a source for the ARP Request (instead of sender's IP = 0). An ND refresh will be an NS message issued from the PE's MAC SA and a Link Local Address associated to the PE's MAC.
PEによって発行されたARPリフレッシュは、PEのMac SAから送信された送信者のIP = 0を持つARP要求メッセージになります。PEにサブネット内のIPアドレス、たとえば、統合ルーティングとブリッジング（IRB）インタフェースでは、（送信者のIP = 0の代わりに）ARP要求のソースとして使用できます。NDリフレッシュは、PEのMAC SAから発行されたNSメッセージと、PEのMACに関連付けられているリンクローカルアドレスになります。
The refresh request messages SHOULD be sent only for dynamic entries and not for static or EVPN-learned entries. Even though the refresh request messages are broadcast or multicast, the PE SHOULD only send the message to the attachment circuit associated to the MAC in the IP->MAC entry.
リフレッシュ要求メッセージは、静的またはEVPN学習エントリ用ではなく、動的エントリに対してのみ送信する必要があります。リフレッシュ要求メッセージがブロードキャストまたはマルチキャストであっても、PEはIP-> MACエントリのMacに関連付けられている添付ファイルにのみメッセージを送信する必要があります。
The age-time and send-refresh options are used in EVPN networks to avoid unnecessary EVPN RT2 withdrawals; if refresh messages are sent before the corresponding BD Bridge-Table and Proxy ARP/ND age-time for a given entry expires, inactive but existing hosts will reply, refreshing the entry and therefore avoiding unnecessary EVPN MAC/IP Advertisement withdrawals in EVPN. Both entries (MAC in the BD and IP->MAC in the Proxy ARP/ND) are reset when the owner replies to the ARP/ND probe. If there is no response to the ARP/ND probe, the MAC and IP->MAC entries will be legitimately flushed and the RT2s withdrawn.
EVPNネットワークでは、エリア時期とSEND-REFRESHオプションがEVPNネットワークで使用され、不要なEVPN RT2の引き出しを回避します。所与のエントリの有効期限が切れたが、既存のホストが有効期限が切れる前にリフレッシュメッセージが送信された場合は、非アクティブではなくエントリを更新し、したがってEVPNでの不要なEVPN MAC / IPアドバタイズメントの引き出しを回避する。所有者がARP / NDプローブに返信すると、両方のエントリ（Proxy ARP / NDのBDおよびIP→MACのMAC）がリセットされます。ARP / NDプローブへの応答がない場合、MACおよびIP-> MACエントリは合法的にフラッシュされ、RT2が引き出されます。
The Proxy ARP/ND function implicitly helps reduce the flooding of ARP Requests and NS messages to remote PEs in an EVPN network. However, in certain use cases, the flooding of ARP/NS/NA messages (and even the unknown unicast flooding) to remote PEs can be suppressed completely in an EVPN network.
プロキシARP / ND関数は暗黙的には、EVPNネットワーク内のリモートPESへのARP要求とNSメッセージのフラッディングを減らすのに役立ちます。ただし、特定のユースケースでは、EVPNネットワークでは、ARP / NS / NAメッセージ（および未知のユニキャストフラッディング）の洪水を完全に抑制することができます。
For instance, in an IXP network, since all the participant CEs are well known and will not move to a different PE, the IP->MAC entries for the local CEs may be all provisioned on the PEs by a management system. Assuming the entries for the CEs are all provisioned on the local PE, a given Proxy ARP/ND table will only contain static and EVPN-learned entries. In this case, the operator may choose to suppress the flooding of ARP/NS/NA from the local PE to the remote PEs completely.
たとえば、IXPネットワークでは、すべての参加者CESがよく知られており、異なるPEに移動しないため、ローカルCEのIP-> MACエントリはすべてPES上で管理システムによってすべてプロビジョニングされる可能性があります。CEのエントリがすべてローカルPEでプロビジョニングされていると仮定すると、特定のプロキシARP / NDテーブルには静的およびEVPN学習エントリのみが含まれます。この場合、オペレータは、ローカルPEからリモートPEへのARP / NS / NAのフラッディングを完全に抑制することを選択することができる。
The flooding may also be suppressed completely in IXP networks with dynamic Proxy ARP/ND entries assuming that all the CEs are directly connected to the PEs and that they all advertise their presence with a GARP/unsolicited-NA when they connect to the network. If any of those two assumptions are not true and any of the PEs may not learn all the local Proxy ARP/ND entries, flooding of the ARP/NS/NA messages from the local PE to the remote PEs SHOULD NOT be suppressed, or the address resolution process for some CEs will not be completed.
すべてのCESがPESに直接接続されていると仮定して、それらがネットワークに接続されたときにそれらがすべての存在を宣伝することを想定して、動的プロキシARP / NDエントリを使用して、フラッディングを完全に抑制することもできます。これら2つの仮定のいずれかが真実でなく、いずれのPESはすべてのローカルプロキシARP / NDエントリを学ぶことができない場合があります。ローカルPEからリモートPEへのARP / NS / NAメッセージのフラッディングは抑制されてはいけません。一部のCESのアドレス解決処理は完了しません。
In networks where fast mobility is expected (DC use case), it is NOT RECOMMENDED to suppress the flooding of unknown ARP Requests / NS messages or GARPs/unsolicited-NAs. Unknown ARP Requests / NS messages refer to those ARP Requests / NS messages for which the Proxy ARP/ND lookups for the requested IPs do not succeed.
高速モビリティが予想されるネットワーク（DCユースケース）では、未知のARPリクエスト/ NSメッセージまたはGARPS / on -icolited-NASのフラッディングを抑制することはお勧めできません。不明なARP要求/ NSメッセージは、要求されたIPSのプロキシARP / NDルックアップが成功しない、それらのARP要求/ NSメッセージを参照してください。
In order to give the operator the choice to suppress/allow the flooding to remote PEs, a PE MAY support administrative options to individually suppress/allow the flooding of:
オペレータにリモートPEへのフラッディングを抑制/許可することを選択するために、PEは管理オプションを個別に抑制/許可するための管理オプションをサポートすることがある。
* Unknown ARP Requests and NS messages.
* 不明なARP要求とNSメッセージ。
* GARP and unsolicited-NA messages.
* GARPと迷惑なNAメッセージ。
The operator will use these options based on the expected behavior on the CEs.
オペレータは、CESの予想される動作に基づいてこれらのオプションを使用します。
The Proxy ARP/ND function MUST support duplicate IP detection as per this section so that ARP/ND-spoofing attacks or duplicate IPs due to human errors can be detected. For IPv6 addresses, CEs will continue to carry out the DAD procedures as per [RFC4862]. The solution described in this section is an additional security mechanism carried out by the PEs that guarantees IPv6 address moves between PEs are legitimate and not the result of an attack. [RFC6957] describes a solution for the IPv6 Duplicate Address Detection Proxy; however, it is defined for point-to-multipoint topologies with a split-horizon forwarding, where the "CEs" have no direct communication within the same L2 link; therefore, it is not suitable for EVPN Broadcast Domains. In addition, the solution described in this section includes the use of the AS-MAC for additional security.
プロキシARP / ND関数は、このセクションごとに重複IP検出をサポートしているため、ヒューマンエラーによるARP / NDスプーフィング攻撃または重複IPを検出できるようにします。IPv6アドレスの場合、CESは[RFC4862]に従ってDADプロシージャを実行し続けます。このセクションに記載されている解決策は、PES間のIPv6アドレスの移動を正当であり、攻撃の結果ではなく、PESによって実行される追加のセキュリティメカニズムです。[RFC6957] IPv6重複アドレス検出プロキシの解決策について説明しています。ただし、スプリットホライズン転送を備えたポイントツーマルチポイントトポロジで定義されています。ここで、「CE」と同じL2リンク内で直接通信がない。したがって、EVPNブロードキャストドメインには適していません。さらに、このセクションに記載されている解決策は、追加のセキュリティのためのAS-MACの使用を含む。
ARP/ND spoofing is a technique whereby an attacker sends "fake" ARP/ ND messages onto a Broadcast Domain. Generally, the aim is to associate the attacker's MAC address with the IP address of another host causing any traffic meant for that IP address to be sent to the attacker instead.
ARP / NDスプーフィングは、攻撃者が「偽の」ARP / NDメッセージをブロードキャストドメインに送信する技術です。一般的に、目的は、攻撃者のMACアドレスを別のホストのIPアドレスに関連付けることです。
The distributed nature of EVPN and Proxy ARP/ND allows the easy detection of duplicated IPs in the network in a similar way to the MAC duplication detection function supported by [RFC7432] for MAC addresses.
EVPNおよびプロキシARP / NDの分散性は、MACアドレスの[RFC7432]でサポートされているMAC複製検出機能と同様に、ネットワーク内の複製IPを容易に検出することを可能にします。
Duplicate IP detection monitors "IP-moves" in the Proxy ARP/ND table in the following way:
重複IP検出は、プロキシARP /とテーブルの「IP-Moves」を次のようにモニタします。
a. When an existing active IP1->MAC1 entry is modified, a PE starts an M-second timer (default value of M = 180), and if it detects N IP moves before the timer expires (default value of N = g5), it concludes that a duplicate IP situation has occurred. An IP move is considered when, for instance, IP1->MAC1 is replaced by IP1->MAC2 in the Proxy ARP/ND table. Static IP->MAC entries, i.e., locally provisioned or EVPN-learned entries with I = 1 in the ARP/ND Extended Community, are not subject to this procedure. Static entries MUST NOT be overridden by dynamic Proxy ARP/ND entries.
a. 既存のアクティブIP1-> MAC1エントリが変更されると、PEはM秒のタイマ（デフォルト値M = 180）を開始し、タイマーが期限切れになる前にN IP移動を検出した場合（デフォルト値N = G5）重複したIPの状況が発生したと締めます。IP1-> MAC1がプロキシARP / NDテーブルのIP1-> MAC2に置き換えられたときにIP移動が考慮されます。静的IP-> MACエントリ、すなわち、ARP / ND拡張コミュニティでi = 1のローカルプロビジョニングまたはEVPN学習エントリは、この手順を受けない。静的エントリは、動的プロキシARP / NDエントリによって上書きしないでください。
b. In order to detect the duplicate IP faster, the PE SHOULD send a Confirm message to the former owner of the IP. A Confirm message is a unicast ARP Request / NS message sent by the PE to the MAC addresses that previously owned the IP, when the MAC changes in the Proxy ARP/ND table. The Confirm message uses a sender's IP 0.0.0.0 in case of ARP (if the PE has an IP address in the subnet, then it MAY use it) and an IPv6 Link Local Address in case of NS. If the PE does not receive an answer within a given time, the new entry will be confirmed and activated. The default RECOMMENDED time to receive the confirmation is 30 seconds. In case of spoofing, for instance, if IP1->MAC1 moves to IP1->MAC2, the PE may send a unicast ARP Request / NS message for IP1 with MAC DA = MAC1 and MAC SA = PE's MAC. This will force the legitimate owner to respond if the move to MAC2 was spoofed and make the PE issue another Confirm message, this time to MAC DA = MAC2. If both, the legitimate owner and spoofer keep replying to the Confirm message. The PE would then detect the duplicate IP within the M-second timer, and a response would be triggered as follows:
b. 重複したIPをより速く検出するために、PEはIPの元の所有者に確認メッセージを送信する必要があります。確認メッセージは、MACがProxy ARP / NDテーブルで変更されたときに、PEによって送信されたMACアドレスに送信されたUnicast ARP Request / NSメッセージです。 ARPの場合（PEがサブネットにIPアドレスを持っている場合は）送信者のIP 0.0.0.0を使用します（PEがサブネットにIPアドレスがある場合は、）、NSの場合はIPv6リンクローカルアドレスが使用されます。 PEが所与の時間内に答えを受け取らない場合、新しいエントリが確認され有効化されます。確認を受け取るためのデフォルトの推奨時間は30秒です。スプーフィングの場合、例えばIP1→MAC1がIP1→MAC2に移動すると、PEはMac DA = MAC1およびMAC SA = PEのMACを用いてIP1用のユニキャストARP要求/ NSメッセージを送信することができる。これにより、MAC2への移動が偽装されている場合に合法的な所有者が反応し、PEに別の確認メッセージを発行させると、今回はMac DA = MAC2になります。両方の場合、正当な所有者とスピーファーは確認メッセージに返信し続けています。その後、PEはM-Second Timer内の重複IPを検出し、次のように応答が発生します。
* If the IP1->MAC1 pair was previously owned by the spoofer and the new IP1->MAC2 was from a valid CE, then the issued Confirm message would trigger a response from the spoofer.
* IP1-> MAC1ペアが以前にスプーファーと新しいIP1-> MAC2が所有していた場合は、有効なCEからのものであった場合、発行された確認メッセージはスポーファーからの応答を引き起こします。
* If it were the other way around, that is, IP1->MAC1 was previously owned by a valid CE, the Confirm message would trigger a response from the CE.
* それが他の方法であったならば、つまりIP1-> MAC1が以前に有効なCEによって所有されていた場合、確認メッセージはCEからの応答を引き起こします。
Either way, if this process continues, then duplicate detection will kick in.
いずれにせよ、このプロセスが続くと、重複した検出が停止します。
c. Upon detecting a duplicate IP situation:
c. 重複したIPの状況を検出すると：
1. The entry in duplicate detected state cannot be updated with new dynamic or EVPN-learned entries for the same IP. The operator MAY override the entry, though, with a static IP->MAC.
1. 重複した検出状態のエントリは、同じIPの新しい動的またはEVPN学習エントリで更新できません。演算子は、静的IP-> MACを使用して、エントリをオーバーライドすることがあります。
2. The PE SHOULD alert the operator and stop responding to ARP/ NS for the duplicate IP until a corrective action is taken.
2. PEはオペレータに警告し、是正措置が取られるまで重複したIPのARP / NSへの応答を停止する必要があります。
3. Optionally, the PE MAY associate an "anti-spoofing-mac" (AS-MAC) to the duplicate IP in the Proxy ARP/ND table. The PE will send a GARP/unsolicited-NA message with IP1->AS-MAC to the local CEs as well as an RT2 (with IP1->AS-MAC) to the remote PEs. This will update the ARP/ND caches on all the CEs in the BD; hence, all the CEs in the BD will use the AS-MAC as MAC DA when sending traffic to IP1. This procedure prevents the spoofer from attracting any traffic for IP1. Since the AS-MAC is a managed MAC address known by all the PEs in the BD, all the PEs MAY apply filters to drop and/or log any frame with MAC DA = AS-MAC. The advertisement of the AS-MAC as a "drop-MAC" (by using an indication in the RT2) that can be used directly in the BD to drop frames is for further study.
3. 任意選択で、PEは、プロキシARP / NDテーブル内の「AS - MAC」（AS - MAC）を重複IPに関連付けることができる。PEは、RT2（IP1-> AS-MAC）をリモートPESに（IP1-> AS-MAC）にIP1-> AS-MACを使用してGARP /迷惑なNAメッセージを送信します。これにより、BD内のすべてのCEのARP / NDキャッシュが更新されます。したがって、BD内のすべてのCEは、IP1にトラフィックを送信するときにMAC DAとAS-MACを使用します。この手順は、スポーファーがIP1のトラフィックを引き付けるのを防ぎます。AS-MACはBD内のすべてのPEによって既知の管理されたMACアドレスであるため、すべてのPESはMac DA = AS-MACを使用して任意のフレームをドロップおよび/または記録するためにフィルタを適用することができます。BDに直接使用することができる「DROP-MAC」とのAS-MACの広告（RT2で表示することによって）は、フレームをドロップするためのものです。
d. The duplicate IP situation will be cleared when a corrective action is taken by the operator or, alternatively, after a HOLD-DOWN timer (default value of 540 seconds).
d. 重複したIPシチュラルは、訂正措置がオペレータによって、あるいはホールドダウンタイマーの後に（デフォルト値540秒）の後にクリアされます。
The values of M, N, and HOLD-DOWN timer SHOULD be a configurable administrative option to allow for the required flexibility in different scenarios.
M、N、およびHold-Down Timerの値は、さまざまなシナリオで必要な柔軟性を可能にするための設定可能な管理オプションである必要があります。
For Proxy ND, the duplicate IP detection described in this section SHOULD only monitor IP moves for IP->MACs learned from NA messages with O Flag = 1. NA messages with O Flag = 0 would not override the ND cache entries for an existing IP; therefore, the procedure in this section would not detect duplicate IPs. This duplicate IP detection for IPv6 SHOULD be disabled when the IPv6 "anycast" capability is activated in a given BD.
プロキシNDの場合、このセクションで説明されている重複IP検出は、o flag = 1のNAメッセージから学習したIP-> MacのIP移動のみを監視する必要があります。;したがって、このセクションの手順は重複するIPを検出しません。IPv6のこの重複IP検出は、IPv6 "Anycast"機能が与えられたBDでアクティブになったときに無効にする必要があります。
The solution described in this document provides the following benefits:
この文書に記載されているソリューションには、次のような利点があります。
a. May completely suppress the flooding of the ARP/ND messages in the EVPN network, assuming that all the CE IP->MAC addresses local to the PEs are known or provisioned on the PEs from a management system. Note that in this case, the unknown unicast flooded traffic can also be suppressed, since all the expected unicast traffic will be destined to known MAC addresses in the PE BDs.
a. PESのローカルのすべてのCE IP-> MACアドレスが管理システムからPES上で既知またはプロビジョニングされていると仮定して、EVPNネットワーク内のARP / NDメッセージのフラッディングを完全に抑制することができます。この場合、予想されるすべてのユニキャストトラフィックは、PE BDS内の既知のMACアドレスを指示するため、未知のユニキャストフラッドトラフィックを抑制することができます。
b. Significantly reduces the flooding of the ARP/ND messages in the EVPN network, assuming that some or all the CE IP->MAC addresses are learned on the data plane by snooping ARP/ND messages issued by the CEs.
b. CESによって発行されたARP / NDメッセージをスヌーピングすることによって、一部またはすべてのCE IP-> MACアドレスがデータプレーン上で学習されていると仮定して、EVPNネットワーク内のARP / NDメッセージのフラッディングを大幅に削減します。
c. Provides a way to refresh periodically the CE IP->MAC entries learned through the data plane so that the IP->MAC entries are not withdrawn by EVPN when they age out unless the CE is not active anymore. This option helps reducing the EVPN control plane overhead in a network with active CEs that do not send packets frequently.
c. データプレーンを通して学習されたCE IP-> MACエントリを定期的に更新する方法を提供し、CEがアクティブになっていない限りEVPNによってEVPNによって引き出されないようにします。このオプションは、パケットを頻繁に送信しないアクティブなCESを持つネットワーク内のEVPNコントロールプレーンオーバーヘッドを減らすのに役立ちます。
d. Provides a mechanism to detect duplicate IP addresses and avoid ARP/ND-spoof attacks or the effects of duplicate addresses due to human errors.
d. 重複したIPアドレスを検出し、ヒューマンエラーによるARP / NDスプーフ攻撃や重複アドレスの影響を避けるためのメカニズムを提供します。
Four deployment scenarios with different levels of ARP/ND control are available to operators using this solution depending on their requirements to manage ARP/ND: all dynamic learning, all dynamic learning with Proxy ARP/ND, hybrid dynamic learning and static provisioning with Proxy ARP/ND, and all static provisioning with Proxy ARP/ND.
ARP / NDを使用するための要件に応じて、さまざまなレベルのARP / NDコントロールを使用した4つの展開シナリオが、ARP / NDを管理するための要件に応じてオペレータに使用できます。/ ND、およびプロキシARP / NDを使用したすべての静的プロビジョニング。
In this scenario for minimum security and mitigation, EVPN is deployed in the BD with the Proxy ARP/ND function shutdown. PEs do not intercept ARP/ND requests and flood all requests issued by the CEs as a conventional Layer 2 network among those CEs would suffice. While no ARP/ND mitigation is used in this scenario, the operator can still take advantage of EVPN features such as control plane learning and all-active multihoming in the peering network.
最小限のセキュリティと緩和のためにこのシナリオでは、EVPNはProxy ARP / ND関数のシャットダウンを使用してBDに展開されています。PESはARP / ND要求を遮断し、CESによって発行されたすべての要求が従来のレイヤ2ネットワークとしてすべての要求をあふれさせません。このシナリオではARP / ND緩和が使用されていない間、オペレータは依然として操作プレーン学習やピアリングネットワークにおける全アクティブマルチホームなどのEVPN機能を利用することができます。
Although this option does not require any of the procedures described in this document, it is added as a baseline/default option for completeness. This option is equivalent to VPLS as far as ARP/ND is concerned. The options described in Sections 5.2, 5.3, and 5.4 are only possible in EVPN networks in combination with their Proxy ARP/ND capabilities.
このオプションではこの文書に記載されている手順は必要ありませんが、完全性のためのベースライン/デフォルトオプションとして追加されます。このオプションは、ARP / NDに関する限りVPLSと同等です。セクション5.2,5.3、および5.4で説明されているオプションは、EVPNネットワークでプロキシARP / ND機能と組み合わせて可能です。
This scenario minimizes flooding while enabling dynamic learning of IP->MAC entries. The Proxy ARP/ND function is enabled in the BDs of the EVPN PEs so that the PEs snoop ARP/ND messages issued by the CEs and respond to CE ARP Requests / NS messages.
このシナリオは、IP-> MACエントリの動的な学習を可能にしながらフラッディングを最小限に抑えます。プロキシARP / ND関数は、EVPN PEのBDSで有効になっているため、CESによって発行されたPESスヌープ/ NDメッセージがCESによって呼び出され、CE ARP要求/ NSメッセージに応答します。
PEs will flood requests if the entry is not in their Proxy table. Any unknown source IP->MAC entries will be learned and advertised in EVPN, and traffic to unknown entries is discarded at the ingress PE.
エントリがプロキシテーブルにない場合、PESはリクエストをフラッディングします。Unknown Source IP-> Macエントリは学習され、EVPNでアドバタイズされ、インクレスへのトラフィックは入力PEで破棄されます。
This scenario makes use of the Learning, Reply, and Maintenance sub-functions, with an optional use of the Unicast-forward and duplicate IP detection sub-functions. The Flood handling sub-function uses default flooding for unknown ARP Requests / NS messages.
このシナリオは、ユニキャストフォワードおよび重複IP検出サブ関数をオプションの使用して、学習、返信、およびメンテナンスサブ機能を利用しています。フラッド処理サブファンクションは、未知のARP要求/ NSメッセージのデフォルトフラッディングを使用します。
Some IXPs and other operators want to protect particular hosts on the BD while allowing dynamic learning of CE addresses. For example, an operator may want to configure static IP->MAC entries for management and infrastructure hosts that provide critical services. In this scenario, static entries are provisioned from the management plane for protected IP->MAC addresses, and dynamic learning with Proxy ARP/ ND is enabled as described in Section 5.2 on the BD.
いくつかのIXPSおよび他の事業者は、CEアドレスの動的学習を可能にしながらBD上の特定のホストを保護したいと考えています。たとえば、オペレータは、重要なサービスを提供する管理およびインフラストラクチャホストの静的IP-> MACエントリを設定することをお勧めします。このシナリオでは、保護されたIP> MACアドレスの管理プレーンから静的エントリがプロビジョニングされ、BDのセクション5.2で説明されているように、プロキシARP / NDを使用した動的学習が可能になります。
This scenario makes use of the same sub-functions as in Section 5.2 but with static entries added by the Learning sub-function.
このシナリオはセクション5.2と同じサブ機能を利用していますが、学習サブ機能によって追加された静的エントリを使用しています。
For a solution that maximizes security and eliminates flooding and unknown unicast in the peering network, all IP->MAC entries are provisioned from the management plane. The Proxy ARP/ND function is enabled in the BDs of the EVPN PEs so that the PEs intercept and respond to CE requests. Dynamic learning and ARP/ND snooping is disabled so that ARP Requests and NS messages to unknown IPs are discarded at the ingress PE. This scenario provides an operator the most control over IP->MAC entries and allows an operator to manage all entries from a management system.
セキュリティを最大化し、ピアリングネットワークでフラッディングおよび不明なユニキャストを排除するソリューションの場合、すべてのIP-> MACエントリが管理プレーンからプロビジョニングされます。PESがCE要求に傍受されて応答するように、EVPN PEのBDSでプロキシARP / ND機能が有効になります。動的ラーニングとARP / NDスヌーピングはディセーブルされ、ARP要求とUnknown IPSへのNSメッセージは入力PEで破棄されます。このシナリオは、オペレータにIP-> MACエントリを最も制御し、オペレータが管理システムからすべてのエントリを管理できるようにします。
In this scenario, the Learning sub-function is limited to static entries, the Maintenance sub-function will not require any procedures due to the static entries, and the Flood handling sub-function will completely suppress unknown ARP Requests / NS messages as well as GARP and unsolicited-NA messages.
このシナリオでは、学習サブ機能は静的エントリに限定されています。メンテナンスサブ関数は静的エントリのために手続きを必要とせず、フラッド処理サブ関数は未知のARP要求/ NSメッセージを完全に抑制します。GARPと迷惑なNAメッセージ。
Nowadays, almost all IXPs install some security rules in order to protect the peering network (BD). These rules are often called port security. Port security summarizes different operational steps that limit the access to the IXP-LAN and the customer router and controls the kind of traffic that the routers are allowed to exchange (e.g., Ethernet, IPv4, and IPv6). Due to this, the deployment scenario as described in Section 5.4, "All Static Provisioning with Proxy ARP/ ND", is the predominant scenario for IXPs.
今日では、ほとんどすべてのIXPSはピアリングネットワーク（BD）を保護するためにいくつかのセキュリティ規則をインストールします。これらの規則はポートセキュリティと呼ばれます。Port Securityは、IXP-LANとカスタマールーターへのアクセスを制限し、ルータが交換することを許可されているトラフィックの種類（例えば、イーサネット、IPv4、およびIPv6）を制御するさまざまな操作手順を要約します。これにより、展開シナリオは5.4項「Proxy ARP / NDを備えたすべての静的プロビジョニング」で説明されているような展開シナリオで、IXPSの優勢なシナリオです。
In addition to the "All Static Provisioning" behavior, in IXP networks it is recommended to configure the Reply sub-function to "discard" ARP Requests / NS messages with unrecognized options.
「すべての静的プロビジョニング」の動作に加えて、IXPネットワークでは、認識されていないオプションを使用してARP Requests / NSメッセージを「破棄」するように返信サブ機能を設定することをお勧めします。
At IXPs, customers usually follow a certain operational life cycle. For each step of the operational life cycle, specific operational procedures are executed.
IXPSでは、顧客は通常特定の運用上のライフサイクルに従います。オペレーショナルライフサイクルの各ステップに対して、特定の動作手順が実行されます。
The following describes the operational procedures that are needed to guarantee port security throughout the life cycle of a customer with focus on EVPN features:
以下に、EVPN機能に焦点を当てている顧客のライフサイクルを通じてポートセキュリティを保証するために必要な運用手順について説明します。
1. A new customer is connected the first time to the IXP:
1. 新しい顧客が初めてIXPに接続されています。
Before the connection between the customer router and the IXP-LAN is activated, the MAC of the router is allowlisted on the IXP's switch port. All other MAC addresses are blocked. Pre-defined IPv4 and IPv6 addresses of the IXP peering network space are configured at the customer router. The IP->MAC static entries (IPv4 and IPv6) are configured in the management system of the IXP for the customer's port in order to support Proxy ARP/ND.
カスタマールータとIXP-LANの間の接続が有効になる前に、ルータのMacがIXPのスイッチポートで許可されています。他のすべてのMACアドレスがブロックされています。IXPピアリングネットワークスペースの事前定義IPv4およびIPv6アドレスは、カスタマールータに設定されています。IP-> MAC静的エントリ（IPv4とIPv6）は、プロキシARP / NDをサポートするために、顧客のポートのIXPの管理システムで構成されています。
In case a customer uses multiple ports aggregated to a single logical port (LAG), some vendors randomly select the MAC address of the LAG from the different MAC addresses assigned to the ports. In this case, the static entry will be used and associated to a list of allowed MACs.
顧客が単一の論理ポート（LAG）に集約された複数のポートを使用する場合、一部のベンダはポートに割り当てられているさまざまなMACアドレスからラグのMACアドレスをランダムに選択します。この場合、静的エントリは使用され、許可されたMACのリストに関連付けられます。
2. Replacement of customer router:
2. カスタマールータの交換：
If a customer router is about to be replaced, the new MAC address(es) must be installed in the management system in addition to the MAC address(es) of the currently connected router. This allows the customer to replace the router without any active involvement of the IXP operator. For this, static entries are also used. After the replacement takes place, the MAC address(es) of the replaced router can be removed.
カスタマールーターが置き換えられようとしている場合は、現在接続されているルータのMACアドレスに加えて、新しいMACアドレスを管理システムにインストールする必要があります。これにより、顧客はIXP演算子のアクティブな関与なしにルータを交換することができます。このためには、静的エントリも使用されます。交換が行われた後、交換されたルータのMACアドレスを削除することができます。
3. Decommissioning a customer router:
3. カスタマールーターを廃止する：
If a customer router is decommissioned, the router is disconnected from the IXP PE. Right after that, the MAC address(es) of the router and IP->MAC bindings can be removed from the management system.
カスタマールータが廃止されている場合、ルータはIXP PEから切断されます。その直後に、ルータとIP-> MACバインディングのMACアドレスを管理システムから削除できます。
DCs normally have different requirements than IXPs in terms of Proxy ARP/ND. Some differences are listed below:
DCSは通常、ARP / NDの点でIXPSとは異なる要件を持ちます。いくつかの違いは以下のとおりです。
a. The required mobility in virtualized DCs makes the "Dynamic Learning" or "Hybrid Dynamic and Static Provisioning" models more appropriate than the "All Static Provisioning" model.
a. 仮想化されたDCのために必要なモビリティは、「すべての静的プロビジョニング」モデルよりも適切な「動的学習」または「ハイブリッド動的プロビジョニング」モデルをより適切にします。
b. IPv6 "anycast" may be required in DCs, while it is typically not a requirement in IXP networks. Therefore, if the DC needs IPv6 anycast addresses, the "anycast" capability will be explicitly enabled in the Proxy ND function and hence the Proxy ND sub-functions modified accordingly. For instance, if IPv6 "anycast" is enabled in the Proxy ND function, the duplicate IP detection procedure in Section 3.7 must be disabled.
b. IPv6 "Anycast"はDCSで必要な場合がありますが、通常はIXPネットワークの要件ではありません。したがって、DCがIPv6 Anycastアドレスを必要とすると、プロキシND関数で「エニーキャスト」機能が明示的に有効になり、それに応じて変更されたプロキシNDサブ関数があります。たとえば、プロキシND関数でIPv6 "Anycast"が有効になっている場合は、セクション3.7の重複IP検出手順を無効にする必要があります。
c. DCs may require special options on ARP/ND as opposed to the address resolution function, which is the only one typically required in IXPs. Based on that, the Reply sub-function may be modified to forward or discard unknown options.
c. DCSは、アドレス解決関数とは対照的に、ARP / ND上で特別なオプションを必要とします。これは、IXPSで通常必要とされる唯一のものです。それに基づいて、返信サブ機能は未知のオプションを転送または破棄するように変更されてもよい。
The security considerations of [RFC7432] and [RFC9047] apply to this document too. Note that EVPN does not inherently provide cryptographic protection (including confidentiality protection).
[RFC7432]と[RFC9047]のセキュリティ上の考慮事項もこの文書にも適用されます。EVPNは本質的に暗号保護（機密保護保護を含む）を提供していないことに注意してください。
The procedures in this document reduce the amount of ARP/ND message flooding, which in itself provides a protection to "slow path" software processors of routers and Tenant Systems in large BDs. The ARP/ND requests that are replied to by the Proxy ARP/ND function (hence not flooded) are normally targeted to existing hosts in the BD. ARP/ND requests targeted to absent hosts are still normally flooded; however, the suppression of unknown ARP Requests and NS messages described in Section 3.6 can provide an additional level of security against ARP Requests / NS messages issued to non-existing hosts.
この文書の手順はARP / NDメッセージフラッディングの量を減らします。これは、それ自体が大型BDSのルータおよびテナントシステムの「スローパス」ソフトウェアプロセッサを保護します。プロキシARP / ND関数（しっかりしていない）で返信されるARP / ND要求は、通常、BD内の既存のホストを対象としています。存在しないホストをターゲットとしたARP / ND要求は、通常はあふれています。ただし、セクション3.6に記載されている未知のARP要求およびNSメッセージの抑制は、既存のホストに対して発行されたARP要求/ NSメッセージに対する追加レベルのセキュリティを提供できます。
While the unicast-forward and/or flood suppression sub-functions provide an added security mechanism for the BD, they can also increase the risk of blocking the service for a CE if the EVPN PEs cannot provide the ARP/ND resolution that the CE needs.
ユニキャストフォワードおよび/または洪水抑制サブ機能はBDのための追加されたセキュリティメカニズムを提供しているが、EVPN PEがCEが必要とするARP / ND解像度を提供できない場合には、CEのサービスをブロックするリスクを高めることもできる。。
The solution also provides protection against Denial-of-Service (DoS) attacks that use ARP/ND spoofing as a first step. The duplicate IP detection and the use of an AS-MAC as explained in Section 3.7 protects the BD against ARP/ND spoofing.
この解決策はまた、最初のステップとしてARP / NDスプーフィングを使用するサービス拒否（DOS）攻撃に対する保護を提供します。3.7節で説明されているIP検出とAS-MACの使用は、ARP / NDスプーフィングに対してBDを保護します。
The Proxy ARP/ND function specified in this document does not allow for the learning of an IP address mapped to multiple MAC addresses in the same table unless the "anycast" capability is enabled (and only in case of Proxy ND). When "anycast" is enabled in the Proxy ND function, the number of allowed entries for the same IP address MUST be limited by the operator to prevent DoS attacks that attempt to fill the Proxy ND table with a significant number of entries for the same IP.
この文書で指定されているプロキシARP / ND関数は、「エニーキャスト」機能が有効になっていない限り（およびプロキシNDの場合にのみ）同じテーブル内の複数のMACアドレスにマッピングされているIPアドレスの学習を可能にしません。プロキシND関数で "Anycast"が有効になっている場合、同じIPアドレスの許容エントリ数は、プロキシNDテーブルを埋めようとしたDOS攻撃を同じIPの有効なエントリを含むのを防ぐために、オペレータによって制限される必要があります。。
This document provides some examples and guidelines that can be used by IXPs in their EVPN BDs. When EVPN and its associated Proxy ARP/ND function are used in IXP networks, they provide ARP/ND security and mitigation. IXPs must still employ additional security mechanisms that protect the peering network as per the established BCPs such as the ones described in [EURO-IX-BCP]. For example, IXPs should disable all unneeded control protocols and block unwanted protocols from CEs so that only IPv4, ARP, and IPv6 Ethertypes are permitted on the peering network. In addition, port security features and ACLs can provide an additional level of security.
このドキュメントは、EVPN BDSのIXPSによって使用できる例とガイドラインを提供します。EVPNとその関連するプロキシARP / ND機能がIXPネットワークで使用されている場合、それらはARP / NDセキュリティと軽減を提供します。IXPSは、[EURO-IX-BCP]に記載されているもののような確立されたBCPに従ってピアリングネットワークを保護する追加のセキュリティメカニズムを依然として使用している必要があります。たとえば、IXPSは、すべての不要なコントロールプロトコルを無効にし、CESから不要なプロトコルをブロックする必要があります。これにより、IPv4、ARP、およびIPv6 EtherTypesがピアリングネットワーク上で許可されます。さらに、ポートセキュリティ機能とACLは追加レベルのセキュリティを提供できます。
Finally, it is worth noting that the Proxy ARP/ND solution in this document will not work if there is a mechanism securing ARP/ND exchanges among CEs because the PE is not able to secure the "proxied" ND messages.
最後に、PEが「プロキシされた」NDメッセージを保護することができないため、CES間でARP / ND交換を確保するメカニズムがある場合は、このドキュメントのプロキシARP / NDソリューションが機能しないことは注目に値します。
This document has no IANA actions.
この文書にはIANAの行動がありません。
[RFC0826] Plummer, D., "An 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>.
[RFC0826] Plummer、D.「イーサネット・アドレス解決プロトコル：またはネットワーク・プロトコル・アドレスをイーサネット・ハードウェア上の伝送のための48.ビジョン・イーサネット・アドレスの変換」、STD 37、RFC 826、DOI 10.17487 / RFC0826、1982年11月、<https：//www.rfc-editor.org/info/rfc826>。
[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>。
[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 / RFC4861、2007年9月、<https：//www.rfc-editor.org/info/rfc4861>。
[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アドレス競合検出」、RFC 5227、DOI 10.17487 / RFC5227、2008年7月、<https：//www.rfc-editor.org/info/rfc5277>。
[RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 2015, <https://www.rfc-editor.org/info/rfc7432>.
[RFC7432] Sajassi、A.、ED。、Aggarwal、R.、Bitar、N.、Isaac、A.、Uttaro、J.、Drake、J.、およびW.HenderickX、「BGP MPLSベースのイーサネットVPN」、RFC 7432、DOI 10.17487 / RFC7432、2015年2月、<https：//www.rfc-editor.org/info/rfc7432>。
[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>。
[RFC9047] Rabadan, J., Ed., Sathappan, S., Nagaraj, K., and W. Lin, "Propagation of ARP/ND Flags in an Ethernet Virtual Private Network (EVPN)", RFC 9047, DOI 10.17487/RFC9047, June 2021, <https://www.rfc-editor.org/info/rfc9047>.
[RFC9047]ラバダン、J.、ED。、Sathappan、S.、Nagaraj、K.、およびW. Lin、「イーサネット仮想プライベートネットワークにおけるARP / NDフラグの伝播（EVPN）」、RFC 9047、DOI 10.17487 /RFC9047、2021年6月、<https://www.rfc-editor.org/info/rfc9047>。
[EURO-IX-BCP] Euro-IX, "European Internet Exchange Association", <https://www.euro-ix.net/en/forixps/set-ixp/ixp-bcops>.
[EURO-IX-BCP]ユーロ-IX、「ヨーロッパのインターネット交換協会」、<https：//www.euro-ix.net/en/forixps/set-ixp/ixp-bcops>。
[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>。
[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-編集者.ORG / INFO / RFC6820>。
[RFC6957] Costa, F., Combes, J-M., Ed., Pougnard, X., and H. Li, "Duplicate Address Detection Proxy", RFC 6957, DOI 10.17487/RFC6957, June 2013, <https://www.rfc-editor.org/info/rfc6957>.
[RFC6957] Costa、F.、Combes、JM、ED。、Pougnard、X.、およびH.Li、「重複アドレス検出プロキシ」、RFC 6957、DOI 10.17487 / RFC6957、2013年6月、<HTTPS：// WWW.rfc-editor.org / info / rfc6957>。
Acknowledgments
謝辞
The authors want to thank Ranganathan Boovaraghavan, Sriram Venkateswaran, Manish Krishnan, Seshagiri Venugopal, Tony Przygienda, Robert Raszuk, and Iftekhar Hussain for their review and contributions. Thank you to Oliver Knapp as well for his detailed review.
著者らは、Ranganathan Bovaraghavan、Sriram Venkateswaran、Manish Krishnan、Seshagiri Venugal、Tony Przygienda、Robert Raszuk、およびIftekhar Hussainに、レビューと貢献を感謝します。彼の詳細レビューのためにも、Oliver Knappにもありがとう。
Contributors
貢献者
In addition to the authors listed on the front page, the following coauthors have also contributed to this document:
フロントページにリストされている作者に加えて、次のCoAuthorsもこの文書に貢献しています。
Wim Henderickx Nokia
WIM Henderickx Nokia.
Daniel Melzer DE-CIX Management GmbH
Daniel Melzer De-Cix Management GmbH.
Erik Nordmark Zededa
エリックノルドマークゼダマ
Authors' Addresses
著者の住所
Jorge Rabadan (editor) Nokia 777 Middlefield Road Mountain View, CA 94043 United States of America
Jorge Rabadan（編集）ノキア777ミドルフィールドロードマウンテンビュー、CA 94043アメリカ
Email: jorge.rabadan@nokia.com
Senthil Sathappan Nokia 701 E. Middlefield Road Mountain View, CA 94043 United States of America
Senthil Sathappan Nokia 701 E.ミドルフィールドロードマウンテンビュー、CA 94043アメリカ
Email: senthil.sathappan@nokia.com
Kiran Nagaraj Nokia 701 E. Middlefield Road Mountain View, CA 94043 United States of America
Kiran Nagaraj Nokia 701 E. Middlefield Road Mountain View、CA 94043アメリカ合衆国
Email: kiran.nagaraj@nokia.com
Greg Hankins Nokia
Greg Hankins Nokia.
Email: greg.hankins@nokia.com
Thomas King DE-CIX Management GmbH
Thomas King De-Cix Management GmbH.
Email: thomas.king@de-cix.net