[要約] RFC 9047は、イーサネット仮想プライベートネットワーク(EVPN)内でARP/NDフラグの伝播を扱う文書です。この文書の目的は、EVPN環境における効率的なIPアドレス解決とホストの到達可能性情報の伝播を改善する方法を提供することです。主に、大規模なデータセンターやサービスプロバイダーネットワークでの利用が想定されています。
Internet Engineering Task Force (IETF) J. Rabadan, Ed.
Request for Comments: 9047 S. Sathappan
Category: Standards Track K. Nagaraj
ISSN: 2070-1721 Nokia
W. Lin
Juniper
June 2021
Propagation of ARP/ND Flags in an Ethernet Virtual Private Network (EVPN)
イーサネット仮想プライベートネットワークにおけるARP / NDフラグの伝播（EVPN）
Abstract
概要
This document defines an Extended Community that is advertised along with an Ethernet Virtual Private Network (EVPN) Media Access Control (MAC) / IP Advertisement route and carries information relevant to the Address Resolution Protocol (ARP) / Neighbor Discovery (ND) resolution so that an EVPN Provider Edge (PE) implementing a proxy-ARP/ND function in broadcast domains (BDs) or an ARP/ND function on Integrated Routing and Bridging (IRB) interfaces can reply to ARP Requests or Neighbor Solicitation (NS) messages with the correct information.
このドキュメントは、イーサネット仮想プライベートネットワーク（EVPN）メディアアクセス制御（MAC）/ IP広告ルートと共にアドバタイズされた拡張コミュニティを定義し、アドレス解決プロトコル（ARP）/ Noiby Discovery（ND）解像度に関連する情報をキャリアする。ブロードキャストドメイン（BDS）またはARP / ND機能のEVPNプロバイダエッジ（PE）または統合ルーティングおよびブリッジング（IRB）インターフェイスのARP / ND機能を実装することで、ARP要求またはネイバー勧誘（NS）メッセージに返信できます。正しい情報
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/rfc9047.
この文書の現在のステータス、任意のエラータ、およびフィードバックを提供する方法は、https：//www.rfc-editor.org/info/rfc9047で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2021 IETF信頼と文書著者として識別された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
このドキュメントは、このドキュメントの発行日に有効なBCP 78およびIETFドキュメントに関連するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象となります。 これらのドキュメントは、このドキュメントに関するお客様の権利と制限について説明しているため、注意深く確認してください。 このドキュメントから抽出されたコードコンポーネントには、Trust LegalProvisionsのセクション4.eで説明されているSimplifiedBSD Licenseテキストが含まれている必要があり、Simplified BSDLicenseで説明されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction
1.1. Terminology and Conventions
2. The EVPN ARP/ND Extended Community
3. Use of the EVPN ARP/ND Extended Community
3.1. Transmission of the EVPN ARP/ND Extended Community
3.2. Reception of the EVPN ARP/ND Extended Community
4. Security Considerations
5. IANA Considerations
6. References
6.1. Normative References
6.2. Informative References
Acknowledgments
Authors' Addresses
An EVPN MAC/IP Advertisement route can optionally carry IPv4 or IPv6 addresses associated with a MAC address. Remote PE routers can use this information to populate their ARP or ND tables on IRB interfaces or their proxy-ARP/ND tables in BDs. PEs can then reply locally (act as an ARP/ND proxy, as per [RFC7432]) to IPv4 ARP Requests and IPv6 Neighbor Solicitation messages and reduce or suppress the flooding produced by the address resolution procedure. However, the information conveyed in the EVPN MAC/IP Advertisement route may not be enough for the remote PE to reply to local ARP or ND requests. For example, if a PE learns an IPv6 address and MAC address combination ND entry via EVPN (denoted by IPv6->MAC), the PE would not know if that particular IPv6->MAC pair belongs to a router or a host or if that address is an anycast address, as this information is not carried in the EVPN MAC/IP Advertisement routes.
EVPN MAC / IPアドバタイズメントルートは、オプションでMACアドレスに関連付けられているIPv4またはIPv6アドレスを携帯できます。リモートPEルータはこの情報を使用して、BDS内のIRBインタフェースまたはそれらのProxy-ARP / NDテーブルにARPまたはNDテーブルを入力できます。その後、PESはローカルに返信することができます（[RFC7432]に従って、[ARP / NDプロキシとして実行）、IPv4 ARP要求およびIPv6の依頼メッセージおよびIPv6の勧誘メッセージを減らし、アドレス解決手順によって生成されたフラッディングを減らすか抑制します。しかしながら、EVPN MAC / IP広告経路で伝達された情報は、リモートPEがローカルARPまたはND要求に応答するのに十分ではないかもしれない。たとえば、PEがEVPNを介してIPv6アドレスとMACアドレスの組み合わせ（IPv6-> Macで示されている）を学習した場合、その特定のIPv6-> MACのペアがルータまたはホストに属しているかどうかはわかりません。この情報はEVPN MAC / IPアドバタイズメントルートでは実行されていないため、Addressはエニーキャストアドレスです。
This document defines an Extended Community that is advertised along with an EVPN MAC/IP Advertisement route and carries information relevant to the ARP/ND resolution so that an EVPN PE implementing a proxy-ARP/ND function can reply to ARP Requests or Neighbor Solicitations with the correct information. In particular, the flags defined in [RFC4861] can now be conveyed along with a MAC/IP Advertisement route so that an egress EVPN PE can issue Neighbor Advertisement (NA) messages with the correct flag information.
このドキュメントはEVPN MAC / IP広告ルートと共に宣伝されている拡張コミュニティを定義し、ARP / ND解決に関連する情報を伝送して、プロキシARP / ND機能を実装するEVPN PEがARP要求または隣接勧誘に応答できるようにすることができる。正しい情報。特に、[RFC4861]で定義されているフラグは、EGRESS EVPN PEが正しいフラグ情報を使用してネイバー広告（NA）メッセージを発行できるように、MAC / IPアドバタイズメントルートと共に伝えられます。
The flags are carried in the EVPN Address Resolution Protocol and Neighbor Discovery (ARP/ND) Extended Community, as described in the following sections.
次のセクションで説明されているように、フラグはEVPNアドレス解決プロトコルおよびネイバーディスカバリ（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", "MAY", および "OPTIONAL" はBCP 14 [RFC2119] [RFC8174]で説明されているように、すべて大文字の場合にのみ解釈されます。
EVPN: Ethernet Virtual Private Networks, as in [RFC7432]
EVPN：[RFC7432]のように、イーサネット仮想プライベートネットワーク
BD: Broadcast Domain, also described in [RFC7432]
BD：[RFC7432]にも記載されているブロードキャストドメイン
ARP: Address Resolution Protocol
ARP：アドレス解決プロトコル
ND: Neighbor Discovery protocol, specified in [RFC4861]
ND：[RFC4861]に指定されたネイバーディスカバリープロトコル
PE: Provider Edge router
PE：プロバイダエッジルータ
CE: Customer Edge router
CE：カスタマーエッジルータ
IRB: Integrated Routing and Bridging interface
IRB：統合ルーティングとブリッジングインタフェース
Proxy-ARP/ND: A function on the EVPN PEs by which received ARP Requests or NS messages are replied to locally by the PE, without the need to flood the requests to remote PEs in the BD. In order to reply to ARP Requests or NS messages, the PE does a lookup on an ARP/ND table, which is a collection of IP->MAC entries learned by the PE.
proxy-arp / nd：ARP要求またはNSメッセージを受信したEVPN PES上の関数は、BD内のリモートPEに要求をフラッディングする必要なしに、PEによってローカルに返信されます。ARP要求またはNSメッセージに返信するには、PEはARP / NDテーブルで検索を行います。これはPEによって学習されたIP-> MACエントリの集まりです。
IP->MAC: An IP address and MAC address combination that represents a given host and is added to an ARP table or ND table. This document uses IP->MAC generically for IPv4 and IPv6 addresses. When something is specific to IPv4, the document will use IPv4->MAC; likewise, IPv6->MAC will be used when something is specific to IPv6 entries only.
IP-> Mac：特定のホストを表すIPアドレスとMACアドレスの組み合わせとARPテーブルまたはNDテーブルに追加されます。このドキュメントでは、IPv4アドレスとIPv6アドレスのIP-> MACを一般的に使用します。何かがIPv4に固有の場合、ドキュメントはIPv4-> Macを使用します。同様に、IPv6-> Macは、IPv6エントリのみに固有のものがある場合に使用されます。
Familiarity with the terminology in [RFC4861] and [RFC7432] is expected.
[RFC4861]および[RFC7432]の用語に精通していることが期待されています。
This document defines a transitive EVPN Extended Community (Type field value of 0x06) with a Sub-Type of 0x08, as allocated by IANA. It is advertised along with EVPN MAC/IP Advertisement routes that carry an IPv4 or IPv6 address.
このドキュメントは、IANAによって割り当てられているように、推移的なEVPN拡張コミュニティ（0x06の型フィールド値0x06）を定義します。IPv4またはIPv6アドレスを持つEVPN MAC / IPアドバタイズメントルートと一緒に宣伝されています。
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=0x06 | Sub-Type=0x08 |Flags (1 octet)| Reserved=0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved=0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Flags field:
flagsフィールド：
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| |I| |O|R|
+-+-+-+-+-+-+-+-+
The following flags are defined in the Flags field, the third octet of the Extended Community:
次のフラグは、拡張コミュニティの3番目のオクテットであるFlagsフィールドに定義されています。
R: Router flag (corresponds to Bit 23 of the Extended Community)
R：ルータフラグ（拡張コミュニティのビット23に対応）
Bit 7 of the Flags field is defined as the "Router flag". When set, the R flag indicates that the IPv6->MAC pair advertised in the MAC/IP Advertisement route, along with the Extended Community, belongs to an IPv6 router. If the R flag is zero, the IPv6->MAC pair belongs to a host. The receiving PE implementing the ND function will use this information in Neighbor Advertisement messages for the associated IPv6 address. This flag has no meaning for ARP IPv4->MAC entries and MUST be ignored when the Extended Community is received with an EVPN MAC/IP Advertisement route for an IPv4->MAC pair.
flagsフィールドのビット7は「ルータフラグ」として定義されています。設定すると、Rフラグは、MAC / IPアドバタイズメントルートでアドバタイズされたIPv6-> MACペアが拡張コミュニティとともにIPv6ルータに属していることを示します。Rフラグがゼロの場合、IPv6-> MACペアはホストに属します。ND関数を実装する受信側PEは、関連するIPv6アドレスのためにネイバーアドバタイズメッセージ内のこの情報を使用します。このフラグはARP IPv4-> MACエントリの意味はありません。これは、拡張コミュニティがIPv4-> MACペアのEVPN MAC / IPアドバタイズメントルートで受信されたときに無視される必要があります。
O: Override flag (corresponds to Bit 22 of the Extended Community)
O：フラグを上書きする（拡張コミュニティのビット22に対応）
Bit 6 of the Flags field is defined as the "Override flag". An egress PE will normally advertise IPv6->MAC pairs with the O flag set, and only when IPv6 "anycast" is enabled in the BD or interface will the PE send an IPv6->MAC pair with the O flag = 0. The ingress PE will install the ND entry with the received O flag and will always use this O flag value when replying to a Neighbor Solicitation for the IPv6 address. Similarly to the Router Flag, the Override flag has no meaning for ARP IPv4->MAC entries and MUST be ignored when the Extended Community is received with an EVPN MAC/IP Advertisement route for an IPv4->MAC pair.
Flagsフィールドのビット6は、「オーバーライドフラグ」として定義されています。EGRESS PEは通常、oフラグ・セットを使用してIPv6-> MACペアをアドバタイズします.BDまたはインタフェースでIPv6 "Anercast"が有効になっている場合にのみ、PEはOFF6-> MACペアをOFF = 0に送信します。入力PEは、受信したOフラグを使用してNDエントリをインストールし、IPv6アドレスの隣接勧誘に返信するときは、常にこのOフラグ値を使用します。ルータフラグと同様に、オーバーライドフラグはARP IPv4-> MACエントリに対して意味がありません。これは、拡張コミュニティがIPv4-> MACペアのEVPN MAC / IPアドバタイズメントルートで受信されたときに無視されなければなりません。
I: Immutable ARP/ND Binding flag (corresponds to Bit 20 of the Extended Community)
I：不変ARP / NDバインディングフラグ（拡張コミュニティのビット20に対応）
Bit 4 of the Flags field is defined as the "Immutable ARP/ND Binding flag". When set, the egress PE indicates that the IP->MAC pair that was sent in an EVPN MAC/IP Advertisement route (along with the Extended Community) is a configured ARP/ND entry. In this case, the IP address in the EVPN MAC/IP Advertisement route can only be bound together with the MAC address specified in the same route, and not with any other MAC addresses received in a different route without the I flag set.
FLAGSフィールドのビット4は、「不変ARP / NDバインディングフラグ」として定義されています。設定すると、EGRESS PEはEVPN MAC / IPアドバタイズメントルートで送信されたIP-> MACペアが（拡張コミュニティと共に）設定されたARP / NDエントリであることを示します。この場合、EVPN MAC / IPアドバタイズメントルートのIPアドレスは、同じ経路で指定されたMACアドレスとともに互いにバインドでき、Iフラグセットなしで異なる経路で受信された他のMACアドレスでは使用できません。
Bits 0-3 and 5 are not assigned by this document. They MUST be set to zero and ignored on receipt.
このドキュメントによってビット0~3と5が割り当てられていません。それらはゼロに設定され、受信時に無視されなければなりません。
The reserved fields are set to 0 and ignored by the receiver.
予約フィールドは0に設定され、受信側によって無視されます。
This section describes the relevant procedures when advertising and processing the EVPN ARP/ND Extended Community. In all the procedures below, a "PE" must be interpreted as a "PE that supports the proxy-ARP/ND (introduced by [RFC7432]) and implements the propagation of the ARP/ND flags that this document specifies".
このセクションでは、EVPN ARP / ND拡張コミュニティを広告し処理するときの関連手順について説明します。以下のすべての手順で、「PE」は「PROX-ARP / ND（[RFC7432]によって導入されているPE PE）として解釈され、このドキュメントが指定したARP / NDフラグの伝播を実装しています。
When an IP->MAC entry is not learned via EVPN, a PE may learn IP->MAC pairs in the management plane (this will create static entries in the ARP/ND or proxy-ARP/ND table) or by snooping ARP or NA messages coming from the CE (this will create dynamic entries). Those static and dynamic IP->MAC entries will be advertised in EVPN MAC/IP Advertisement routes that use the EVPN ARP/ND Extended Community as follows:
IP-> MACエントリがEVPNを介して学んでいない場合、PEは管理プレーン内のIP-> MACペアを学習することができます（これにより、ARP / NDまたはProxy-ARP / NDテーブルに静的エントリが作成されます）、またはスヌーピングARPによってCEからのNAメッセージ（これは動的エントリを作成します）。これらの静的および動的IP-> MACエントリは、EVPN ARP / ND拡張コミュニティを次のように使用するEVPN MAC / IPアドバタイズメントルートでアドバタイズされます。
* Advertised MAC/IP Advertisement routes for IPv6->MAC entries MUST include one (and only one) ARP/ND Extended Community with the R and O flag values associated with the entry. Those flag values are either dynamically learned (from NA messages) or configured in case of static entries.
* IPv6-> MACエントリのアドバタイズされたMAC / IPアドバタイズメントルートには、エントリに関連付けられているRフラグ値とOフラグ値を持つ1つの（および1つだけ）ARP / ND拡張コミュニティを含める必要があります。これらのフラグ値は、動的に（NAメッセージから）または静的エントリの場合に設定されています。
* MAC/IP Advertisement routes for IPv4->MAC entries MAY include one ARP/ND Extended Community. If the EVPN ARP/ND Extended Community is advertised along with an EVPN IPv4/MAC Advertisement route, the R and O flags SHOULD be set to zero.
* IPv4-> MACエントリのMAC / IPアドバタイズメントルートには、1つのARP / ND拡張コミュニティが含まれる場合があります。EVPN ARP / ND拡張コミュニティがEVPN IPv4 / MAC広告経路とともに広告されている場合は、RフラグとOフラグをゼロに設定する必要があります。
* If an IP->MAC pair is static (it has been configured), the corresponding MAC/IP Advertisement route MUST be sent along with an ARP/ND Extended Community with the I flag set.
* IP-> MACペアが静的（設定されている）の場合、対応するMAC / IPアドバタイズメントルートは、Iフラグセットを使用してARP / ND拡張コミュニティとともに送信されなければなりません。
* This Extended Community does not change the procedures described in [RFC7432]. Specifically, the procedures for advertising the MAC Mobility Extended Community along with the MAC/IP Advertisement route are not changed.
* この拡張コミュニティは[RFC7432]に記載されている手順を変更しません。具体的には、MAC / IP広告経路とともにMACモビリティ拡張コミュニティを広告する手順は変更されていない。
In addition to the procedures specified in [RFC7432], a PE receiving a MAC/IP Advertisement route will process the EVPN ARP/ND Extended Community as follows:
[RFC7432]で指定された手順に加えて、MAC / IPアドバタイズメントルートを受信したPEは、次のようにEVPN ARP / ND Extended Communityを処理します。
* Only one EVPN ARP/ND Extended Community is expected to be received along with an EVPN MAC/IP Advertisement route. If more than one ARP/ND Extended Community is received, the PE MUST consider only the first one on the list for processing purposes and MUST NOT propagate the rest of the ARP/ND Extended Communities.
* EVPN MAC / IP広告経路とともに受信される予定のEVPN ARP / ND拡張コミュニティは1つだけです。複数のARP / ND拡張コミュニティが受信された場合、PEは処理目的でリスト上の最初のもののみを考慮し、残りのARP / ND拡張コミュニティを伝播してはなりません。
* The R, O, and I flags MUST be ignored if they are advertised along with an EVPN MAC/IP Advertisement route that does not contain an IP (IPv4 or IPv6) address. Otherwise, they are processed as follows.
* r、o、およびiフラグは、IP（IPv4またはIPv6）アドレスを含まないEVPN MAC / IPアドバタイズメントルートと共にアドバタイズされている場合は無視されなければなりません。そうでなければ、それらは次のように処理されます。
* R and O flag processing:
* RとOフラグ処理：
- If the EVPN MAC/IP Advertisement route contains an IPv6 address and the EVPN ARP/ND Extended Community, the PE MUST add the R and O flag values to the ND entry in the ND or proxy-ND table and propagate the value of the R and O flags from the ARP/ND Extended Community to the Neighbor Advertisements when replying to a solicitation for the IPv6 address.
- EVPN MAC / IPアドバタイズメントルートにIPv6アドレスとEVPN ARP / ND拡張コミュニティが含まれている場合、PEはNDまたはProxy-NDテーブルのNDエントリにRフラグ値を追加し、Rの値を伝播する必要があります。IPv6アドレスの勧誘に返信するときに、ARP / ND拡張コミュニティから隣接アドバージョン名へのoフラグ。
- If no EVPN ARP/ND Extended Community is received along with the route, the PE will add the default R and O flags to the entry. The default R flag SHOULD be an administrative choice. The default O flag SHOULD be 1.
- RouteとともにEVPN ARP / ND拡張コミュニティが受信されない場合、PEはデフォルトのRフラグとOフラグをエントリに追加します。デフォルトのRフラグは管理者選択であるべきです。デフォルトのOフラグは1です。
- A PE MUST ignore the received R and O flags for an EVPN MAC/IP Advertisement route that contains an IPv4->MAC pair.
- PEは、IPv4-> MACペアを含むEVPN MAC / IPアドバタイズメントルートの受信RフラグとOフラグを無視する必要があります。
* I flag processing:
* 私は処理にフラグを付けます：
- A PE receiving an EVPN MAC/IP Advertisement route containing an IP->MAC and the I flag set SHOULD install the IP->MAC entry in the ARP/ND or proxy-ARP/ND table as an "immutable binding". This immutable binding entry will override an existing non-immutable binding for the same IP->MAC. The absence of the EVPN ARP/ND Extended Community in a MAC/IP Advertisement route indicates that the IP->MAC entry is not an "immutable binding".
- IP-> MACとIフラグセットを含むEVPN MAC / IPアドバタイズメントルートを受信したPEは、ARP / NDまたはProxy-ARP / NDテーブルにIP-> MACエントリを「不変バインディング」としてインストールする必要があります。この不変バインディングエントリは、同じIP-> MACに対して既存の不変バインドを上書きします。MAC / IPアドバタイズメントルートでEVPN ARP / ND拡張コミュニティがないことは、IP-> MACエントリが「不変バインディング」ではないことを示しています。
- Receiving multiple EVPN MAC/IP Advertisement routes with the I flag set to 1 for the same IP but a different MAC address is considered a misconfiguration or a transient error condition. If this happens in the network, a PE receiving multiple routes (with the I flag set to 1 for the same IP and a different MAC address) SHOULD update the IP->MAC entry with the latest received information. Note that if a configured IP1->MAC1 changes to point to a new MAC address, i.e., IP1->MAC2, the EVPN MAC/IP Advertisement route for IP1->MAC1 will be withdrawn before the EVPN MAC/IP Advertisement route for IP1->MAC2 is advertised.
- 同じIPに対して1に設定されているが、異なるMACアドレスを1に設定した複数のEVPN MAC / IPアドバタイズメントルートを受信するが、異なるMACアドレスが誤構成または一時的なエラー状態と見なされる。これがネットワークで起こると、複数のルートを受信するPE（iフラグが同じIPに設定され、異なるMACアドレスに設定されている）は、最新の受信した情報を使用してIP-> MACエントリを更新する必要があります。構成されたIP1-> MAC1が新しいMACアドレス、つまりIP1-> MAC2を指すように変更された場合、IP1-> MAC1のEVPN MAC / IPアドバタイズメントルートは、IP1のEVPN MAC / IPアドバタイズメントルートの前に引き出されます。 - > MAC2が宣伝されています。
- A PE originating an EVPN MAC/IP Advertisement route for IP1->MAC1 with the I flag set to 1 MAY also originate the route with the "Sticky/static flag" set (in the MAC Mobility Extended Community). In such a case, the IP1->MAC1 binding is not only immutable but it cannot move as well. Even so, if an update for the same immutable and static IP1->MAC1 is received from a different PE, one of the two routes will be selected. This is analogous to the case described in Section 15.2 of [RFC7432] when two MAC/IP routes with the static flag set are received, and the PE likewise MUST alert the operator of such a situation.
- iフラグが1に設定されたIP1→MAC1のEVPN MAC / IP広告経路を発信するPEは、（Mac Mobility Extendedコミュニティで）「Sticky / Static Flag」セットを使用してルートを発信することもできます。そのような場合、IP1-> MAC1の結合は不変だけではなく、それも動くことはできません。したがって、同じ不変および静的IP1-> MAC1の更新が異なるPEから受信された場合、2つの経路のうちの1つが選択されます。これは、静的フラグセットを持つ2つのMAC / IPルートを受信した場合に、[RFC7432]のセクション15.2で説明されている場合と似ています。これは同様にそのような状況のオペレータに警告する必要があります。
In a situation where a host (with an IP->MAC that is configured as immutable binding in the attached PE) is allowed to move between PEs (that is, the associated MAC is non-static), PEs can receive multiple MAC/IP Advertisement routes for the same IP->MAC. In such situations, MAC mobility procedures as in [RFC7432] dictate the reachability of the MAC.
（接続されているPEで不変のバインディングとして構成されているIP-> MACを持つ）ホストがPE間（つまり、関連するMacは非静的）の間の移動を許可されている場合、PESは複数のMAC / IPを受信できます。同じIP-> MACの広告経路。そのような状況では、[RFC7432]のようなMACモビリティ手順は、MACの到達可能性を決定します。
As an example of the use of the I flag, consider PE1, PE2, and PE3 attached to the same BD. PE1 originates an EVPN MAC/IP Advertisement route for IP1->MAC1 with the I flag set to 1 later on, PE2 also originates an EVPN MAC/IP Advertisement route IP1->MAC1 with a higher sequence number and the I flag set to 1. Then all the EVPN PEs attached to the same BD SHOULD retain their IP1->MAC1 ARP/ND binding but update MAC1's forwarding destination to PE2. For some reason, if PE3 originates an EVPN MAC/IP Advertisement route for IP1->MAC2 with the I flag set to 0 (even with a higher sequence number), then the EVPN PEs in the BD will not update their IP1->MAC1 ARP/ND bindings since IP1 is bound to MAC1 (MAC2 SHOULD still be programmed in the Layer 2 BDs). This is considered a misconfiguration in PE3.
Iフラグの使用例として、同じBDに接続されているPE1、PE2、およびPE3を検討してください。PE1はIP1-> MAC1のEVPN MAC / IPアドバタイズメントルートを起源にし、IP1フラグが1に設定されている場合、PE2はEVPN MAC / IPアドバタイズメントルートIP1-> MAC1をより高いシーケンス番号で発信し、Iフラグは1に設定されています。。次に、同じBDに接続されているすべてのEVPN PEは、IP1-> MAC1 ARP / NDバインディングを保持しますが、MAC1の転送先をPE2に更新する必要があります。何らかの理由で、PE3がIP1-> MAC2のEVPN MAC / IPアドバタイズメントルートを0に設定した場合（シーケンス番号が高い場合でも）、BDのEVPN PEはIP1-> MAC1を更新しません。IP1がMAC1にバインドされているため、ARP / NDバインディングは（MAC2は依然としてレイヤ2 BDSでプログラムする必要があります）。これはPE3の誤構成と見なされます。
When the I flag is set to 1, a given IP is assumed to be always bound to the same MAC address; therefore, the mobility procedures described in [EXTENDED-MOBILITY] for "Host IP move to a new MAC" will not apply.
Iフラグが1に設定されている場合、所定のIPは常に同じMACアドレスにバインドされると仮定される。したがって、「Host-Mobility」で説明されているモビリティ手順は「新しいMacに移行する」には適用されません。
The same security considerations described in [RFC7432] apply to this document. In general, it is worth noting that the use of proxy-ARP/ ND in EVPN BDs may add some security risks. Attackers can make use of ARP/ND messages to create state in all the PEs attached to the same BD as the attacker and exhaust resources in those PEs. Therefore, additional security mechanisms may be needed. Some examples of such additional security mechanisms are limiting the number of proxy-ARP/ND entries per BD and/or per port or closely monitoring the rate at which hosts create dynamic proxy-ARP/ND entries.
[RFC7432]で説明されているのと同じセキュリティ上の考慮事項がこの文書に適用されます。一般的に、EVPN BDSのProxy-ARP / NDの使用はいくつかのセキュリティリスクを追加する可能性があることが注目に値します。攻撃者はARP / NDメッセージを利用して、攻撃者と同じBDに接続されているすべてのPESで状態を作成することができます。したがって、追加のセキュリティメカニズムが必要になる場合があります。そのような追加のセキュリティメカニズムのいくつかの例は、BDおよび/またはポートごとのプロキシ-ARP / NDエントリの数を制限するか、ホストが動的プロキシ-ARP / NDエントリを作成するレートを厳密に監視しています。
In addition, this document adds pieces of information that impact the way ARP/ND entries are installed in ARP/ND and/or proxy-ARP/ND tables and, therefore, impacts the resolution protocols for IPv4 and IPv6 addresses. For instance, if a given IPv6->MAC binding is configured with the wrong R or O flags (intentionally or not) on a given PE, the rest of the PEs attached to the same BD will install the wrong information for the IPv6->MAC. This will cause all the PEs in the BD to reply to Neighbor Solicitations for the IPv6 with NA messages containing the wrong R and O flags. For example, as specified in [RFC4861], the receiver of an NA message with O not set will not update its existing cache entry for the IP->MAC; hence, the communication between the owner of the IP address and the receiver of the NA message with the wrong O flag will fail. Similarly, the receiver of an NA message with the wrong R flag may update its Default Router List by incorrectly adding or removing an entry, which could, for example, lead to sending traffic to a node that is not a router, causing the traffic to be dropped.
さらに、この文書はARP / NDエントリがARP / NDおよび/またはProxy-ARP / NDテーブルにインストールされている方法に影響を与える情報を追加し、したがって、IPv4アドレスとIPv6アドレスの解像度プロトコルに影響します。たとえば、特定のIPv6-> MACバインディングが、特定のPE上で（意図的にまたはox）の間違ったRまたはOフラグで設定されている場合、同じBDに接続されている残りのPESはIPv6->に間違った情報をインストールします。マック。これにより、BD内のすべてのPESがIPv6の隣接勧誘に、間違ったRフラグとOフラグを含むNAメッセージを返信します。たとえば、[RFC4861]で指定されているように、ONのNOSメッセージの受信者はIP-> Macの既存のキャッシュエントリを更新しません。したがって、IPアドレスの所有者とNAメッセージの受信者との間の通信が誤ったoフラグで失敗する。同様に、誤ったRフラグを伴うNAメッセージの受信者は、エントリを誤って追加または削除することによって、そのデフォルトのルータリストを更新することができ、たとえばルータではないノードにトラフィックを送信し、トラフィックを実行することができる。落とした。
The I flag, or Immutable ARP/ND Binding flag, is a useful security tool, allowing an operator to ensure a given IP address is always bound to the same MAC and that information is distributed to all the PEs attached to the same BD. ARP/ND spoofing attacks, in which a malicious host injects Gratuitous ARPs or unsolicited NAs for that IP address with a different MAC address, will not succeed in programming the ARP/ND and proxy-ARP/ND tables and therefore the spoofer will not receive the traffic.
Iフラグ、または不変のARP / NDバインディングフラグは有用なセキュリティツールで、オペレータが特定のIPアドレスを常に同じMACにバインドされ、その情報は同じBDに接続されているすべてのPEに配布されます。悪意のあるホストが異なるMACアドレスを持つIPアドレスの無償のARPまたは迷惑なNAを挿入するARP / NDスプーフィング攻撃は、ARP / NDおよびProxy-ARP / NDテーブルをプログラミングすることで成功しません。したがって、スピーファーは受信しませんトラフィック
IANA has changed the name for Sub-Type Value 0x08 in the "EVPN Extended Community Sub-Types" registry [IANA-BGP-EXT-COMM] to the following:
IANAは、「EVPN拡張コミュニティサブタイプ」レジストリ[IANA-BGP-EXT-COMM]のサブタイプ値0x08の名前を次のように変更しました。
+================+===========================+===========+
| Sub-Type Value | Name | Reference |
+================+===========================+===========+
| 0x08 | ARP/ND Extended Community | RFC 9047 |
+----------------+---------------------------+-----------+
Table 1: Updated Value in the "EVPN Extended Community Sub-Types" Registry
表1：「EVPN拡張コミュニティサブタイプ」レジストリの更新値
IANA has created the "ARP/ND Extended Community Flags" registry, where the following initial allocations have been made:
IANAは「ARP / ND拡張コミュニティフラグ」レジストリを作成しました。ここで、次の最初の割り当てが行われました。
+===============+===================================+===========+
| Flag Position | Name | Reference |
+===============+===================================+===========+
| 0-3 | Unassigned | |
+---------------+-----------------------------------+-----------+
| 4 | Immutable ARP/ND Binding Flag (I) | RFC 9047 |
+---------------+-----------------------------------+-----------+
| 5 | Unassigned | |
+---------------+-----------------------------------+-----------+
| 6 | Override Flag (O) | RFC 9047 |
+---------------+-----------------------------------+-----------+
| 7 | Router Flag (R) | RFC 9047 |
+---------------+-----------------------------------+-----------+
Table 2: Initial Values of the "ARP/ND Extended Community Flags" Registry
表2：「ARP / ND Extended Community Flags」レジストリの初期値
The registration policy for this registry is Standards Action [RFC8126]. This registry is located in the "Border Gateway Protocol (BGP) Extended Communities" registry [IANA-BGP-EXT-COMM].
このレジストリの登録ポリシーは標準アクション[RFC8126]です。このレジストリは、「BGP）拡張コミュニティ」レジストリ[IANA-BGP-EXT-COMM]にあります。
Note that the flag position 5 is left unassigned and not used in this specification since it was previously requested by [EVPN-IP-MAC-PROXY].
なお、フラグ位置5は、以前は[EVPN - IP - MAC - Proxy]によって要求されているため、この仕様では未割り当てされずに使用されない。
[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、「RFCSで使用するためのキーワード」、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）の隣接発見（IPv6）」、RFC 4861、DOI 10.17487 / RFC4861、2007年9月、<https：//www.rfc-editor.org/info/rfc4861>。
[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>。
[EVPN-IP-MAC-PROXY] Bickhart, R., Lin, W., Drake, J., Rabadan, J., and A. Lo, "Proxy IP->MAC Advertisement in EVPNs", Work in Progress, Internet-Draft, draft-rbickhart-evpn-ip-mac-proxy-adv-01, 24 January 2020, <https://tools.ietf.org/html/draft-rbickhart-evpn-ip-mac-proxy-adv-01>.
[EVPN-IP-Mac-Proxy] Bickhart、R.、Lin、W.、Drake、J.、Rabadan、J.、A. LO、「プロキシIP-> Mac広告」、進行中、インターネット--draft、draft-rbickhart-evpn-ip-mac-proxy-adv-01,2020 <https://tools.ietf.org/html/draft-rbickhart-evpn-ip-mac-proxy-adv-01>。
[EXTENDED-MOBILITY] Malhotra, N., Ed., Sajassi, A., Pattekar, A., Lingala, A., Rabadan, J., and J. Drake, "Extended Mobility Procedures for EVPN-IRB", Work in Progress, Internet-Draft, draft-ietf-bess-evpn-irb-extended-mobility-05, 15 March 2021, <https://tools.ietf.org/html/draft-ietf-bess-evpn-irb-extended-mobility-05>.
[拡張モビリティ] Malhotra、N.、Ed。、Sajassi、A.、Pattekar、A.、Lingala、A.、Rabadan、J.、J. Drake、「EVPN-IRBの拡張モビリティ手順」進捗状況、インターネットドラフト、ドラフト-IETF-Bess-EVPN-IRB-Extended-Mobility-05,15,15、<https：//tools.ietf.org/html/draft-ietf-bess-evpn-irb-estended - モビリティ-05>。
[IANA-BGP-EXT-COMM] IANA, "Border Gateway Protocol (BGP) Extended Communities", <https://www.iana.org/assignments/bgp-extended-communities>.
[IANA-BGP-EXT-COMM] IANA、「BORDER GATEWAYプロトコル（BGP）拡張コミュニティ」、<https：//www.iana.org/ashignments/bgp-extended-Communities>。
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.
[RFC8126]綿、M.、Leiba、B.およびT.Narten、「RFCSのIANAに関する考察のためのガイドライン」、BCP 26、RFC 8126、DOI 10.17487 / RFC8126、2017年6月、<HTTPS：// WWW.rfc-editor.org / info / rfc8126>。
Acknowledgments
謝辞
The authors would like to thank Ali Sajassi for his feedback.
彼のフィードバックのためにAli Sajassiに感謝します。
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.ミドルフィールドロードマウンテンビュー、CA 94043アメリカ
Email: kiran.nagaraj@nokia.com
Wen Lin Juniper Networks
WEN LINジュニパーネットワーク
Email: wlin@juniper.net