[要約] 要約：RFC 7342は、大規模データセンターでのARPとNeighbor Discovery（ND）のスケーリングに関するベストプラクティスを提供しています。 目的：このRFCの目的は、大規模データセンター環境でのARPとNDの効率的なスケーリングを実現し、ネットワークのパフォーマンスと信頼性を向上させることです。
Independent Submission L. Dunbar
Request for Comments: 7342 Huawei
Category: Informational W. Kumari
ISSN: 2070-1721 Google
I. Gashinsky
Yahoo
August 2014
Practices for Scaling ARP and Neighbor Discovery (ND) in Large Data Centers
大規模データセンターでのARPおよび近隣探索（ND）のスケーリングの実践
Abstract
概要
This memo documents some operational practices that allow ARP and Neighbor Discovery (ND) to scale in data center environments.
このメモは、ARPおよびNeighbor Discovery（ND）がデータセンター環境で拡張できるようにするいくつかの運用慣行を文書化しています。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
これは、他のRFCストリームとは無関係に、RFCシリーズへの貢献です。 RFCエディターは、このドキュメントを独自の裁量で公開することを選択し、実装または展開に対するその価値については何も述べていません。 RFC Editorによって公開が承認されたドキュメントは、どのレベルのインターネット標準の候補にもなりません。 RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7342.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7342で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2014 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://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.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。
Table of Contents
目次
1. Introduction ....................................................2
2. Terminology .....................................................4
3. Common DC Network Designs .......................................4
4. Layer 3 to Access Switches ......................................5
5. Layer 2 Practices to Scale ARP/ND ...............................5
5.1. Practices to Alleviate APR/ND Burden on L2/L3
Boundary Routers ...........................................5
5.1.1. Communicating with a Peer in a Different Subnet .....6
5.1.2. L2/L3 Boundary Router Processing of Inbound
Traffic .............................................7
5.1.3. Inter-Subnet Communications .........................8
5.2. Static ARP/ND Entries on Switches ..........................8
5.3. ARP/ND Proxy Approaches ....................................9
5.4. Multicast Scaling Issues ...................................9
6. Practices to Scale ARP/ND in Overlay Models ....................10
7. Summary and Recommendations ....................................10
8. Security Considerations ........................................11
9. Acknowledgements ...............................................11
10. References ....................................................12
10.1. Normative References .....................................12
10.2. Informative References ...................................13
This memo documents some operational practices that allow ARP/ND to scale in data center environments.
このメモは、ARP / NDがデータセンター環境で拡張できるようにするいくつかの運用慣行を文書化しています。
As described in [RFC6820], the increasing trend of rapid workload shifting and server virtualization in modern data centers requires servers to be loaded (or reloaded) with different Virtual Machines (VMs) or applications at different times. Different VMs residing on one physical server may have different IP addresses or may even be in different IP subnets.
[RFC6820]で説明されているように、最新のデータセンターにおける急速なワークロードシフトとサーバー仮想化の増加する傾向により、サーバーは異なる仮想マシン（VM）またはアプリケーションで異なる時間にロード（またはリロード）される必要があります。 1つの物理サーバーに常駐する異なるVMは、異なるIPアドレスを持っている場合や、異なるIPサブネットにある場合さえあります。
In order to allow a physical server to be loaded with VMs in different subnets or allow VMs to be moved to different server racks without IP address reconfiguration, the networks need to enable multiple broadcast domains (many VLANs) on the interfaces of L2/L3 boundary routers and Top-of-Rack (ToR) switches and allow some subnets to span multiple router ports.
物理サーバーに異なるサブネットのVMをロードしたり、IPアドレスを再構成せずにVMを異なるサーバーラックに移動したりできるようにするには、ネットワークでL2 / L3境界のインターフェースで複数のブロードキャストドメイン（多くのVLAN）を有効にする必要がありますルーターとトップオブラック（ToR）スイッチにより、一部のサブネットが複数のルーターポートにまたがることができます。
Note: L2/L3 boundary routers as discussed in this document are capable of forwarding IEEE 802.1 Ethernet frames (Layer 2) without a Media Access Control (MAC) header change. When subnets span multiple ports of those routers, they still fall under the category of "single-link" subnets, specifically the multi-access link model recommended by [RFC4903]. They are different from the "multi-link" subnets described in [Multi-Link] and RFC 4903, which refer to different physical media with the same prefix connected to one router. Within the "multi-link" subnet described in RFC 4903, Layer 2 frames from one port cannot be natively forwarded to another port without a header change.
注：このドキュメントで説明されているL2 / L3境界ルータは、メディアアクセスコントロール（MAC）ヘッダーを変更せずにIEEE 802.1イーサネットフレーム（レイヤ2）を転送できます。サブネットがこれらのルーターの複数のポートにまたがる場合でも、それらは「シングルリンク」サブネットのカテゴリー、特に[RFC4903]によって推奨されるマルチアクセスリンクモデルに分類されます。これらは、[マルチリンク]およびRFC 4903で説明されている「マルチリンク」サブネットとは異なります。これらのサブネットは、1つのルーターに接続された同じプレフィックスを持つ異なる物理メディアを指します。 RFC 4903で説明されている「マルチリンク」サブネット内では、ヘッダーを変更しないと、あるポートからのレイヤー2フレームを別のポートにネイティブに転送できません。
Unfortunately, when the combined number of VMs (or hosts) in all those subnets is large, this can lead to address resolution (i.e., IPv4 ARP and IPv6 ND) scaling issues. There are three major issues associated with ARP/ND address resolution protocols when subnets span multiple L2/L3 boundary router ports:
残念ながら、これらすべてのサブネットのVM（またはホスト）の合計数が多いと、アドレス解決（つまり、IPv4 ARPおよびIPv6 ND）のスケーリングの問題が発生する可能性があります。サブネットが複数のL2 / L3境界ルーターポートにまたがる場合、ARP / NDアドレス解決プロトコルに関連する3つの主要な問題があります。
1) The ARP/ND messages being flooded to many physical link segments, which can reduce bandwidth utilization for user traffic.
1）ARP / NDメッセージが多くの物理リンクセグメントにフラッディングされるため、ユーザートラフィックの帯域幅使用率を削減できます。
2) The ARP/ND processing load impact on the L2/L3 boundary routers.
2）L2 / L3境界ルーターへのARP / ND処理負荷の影響。
3) In IPv4, every end station in a subnet receiving ARP broadcast messages from all other end stations in the subnet. IPv6 ND has eliminated this issue by using multicast.
3）IPv4では、サブネット内のすべての端末は、サブネット内の他のすべての端末からARPブロードキャストメッセージを受信します。 IPv6 NDは、マルチキャストを使用することでこの問題を解消しました。
Since the majority of data center servers are moving towards 1G or 10G ports, the bandwidth taken by ARP/ND messages, even when flooded to all physical links, becomes negligible compared to the link bandwidth. In addition, IGMP/MLD (Internet Group Management Protocol and Multicast Listener Discovery) snooping [RFC4541] can further reduce the ND multicast traffic to some physical link segments.
データセンターサーバーの大部分は1Gまたは10Gポートに移行しているため、すべての物理リンクにフラッディングされた場合でも、ARP / NDメッセージが使用する帯域幅は、リンクの帯域幅と比較すると無視できます。さらに、IGMP / MLD（インターネットグループ管理プロトコルおよびマルチキャストリスナーディスカバリ）スヌーピング[RFC4541]は、一部の物理リンクセグメントへのNDマルチキャストトラフィックをさらに削減できます。
As modern servers' computing power increases, the processing taken by a large amount of ARP broadcast messages becomes less significant to servers. For example, lab testing shows that 2000 ARP requests per second only takes 2% of a single-core CPU server. Therefore, the impact of ARP broadcasts to end stations is not significant on today's servers.
最近のサーバーのコンピューティング能力が向上するにつれて、大量のARPブロードキャストメッセージで行われる処理はサーバーにとってそれほど重要ではなくなります。たとえば、ラボのテストでは、1秒あたり2000 ARP要求はシングルコアCPUサーバーの2％しか使用しないことが示されています。したがって、エンドステーションへのARPブロードキャストの影響は、今日のサーバーでは重要ではありません。
Statistics provided by Merit Network [ARMD-Statistics] have shown that the major impact of a large number of mobile VMs in a data center is on the L2/L3 boundary routers, i.e., issue 2 above.
Merit Network [ARMD-Statistics]が提供する統計によると、データセンター内の多数のモバイルVMの主な影響はL2 / L3境界ルーター、つまり上記の問題2にあることがわかりました。
This memo documents some simple practices that can scale ARP/ND in a data center environment, especially in reducing processing loads to L2/L3 boundary routers.
このメモは、特にL2 / L3境界ルーターへの処理負荷を軽減する際に、データセンター環境でARP / NDを拡張できるいくつかの簡単な方法を文書化しています。
This document reuses much of the terminology from [RFC6820]. Many of the definitions are presented here to aid the reader.
このドキュメントでは、[RFC6820]の用語の多くを再利用しています。ここでは、読者を支援するために、定義の多くを示します。
ARP: IPv4 Address Resolution Protocol [RFC826]
ARP：IPv4アドレス解決プロトコル[RFC826]
Aggregation Switch: A Layer 2 switch interconnecting ToR switches
集約スイッチ：ToRスイッチを相互接続するレイヤー2スイッチ
Bridge: IEEE802.1Q-compliant device. In this document, the term "Bridge" is used interchangeably with "Layer 2 switch"
ブリッジ：IEEE802.1Q準拠デバイス。このドキュメントでは、「ブリッジ」という用語は「レイヤ2スイッチ」と同じ意味で使用されています。
DC: Data Center
DC：データセンター
DA: Destination Address
DA：宛先アドレス
End Station: VM or physical server, whose address is either the destination or the source of a data frame
エンドステーション：アドレスがデータフレームの宛先またはソースであるVMまたは物理サーバー
EoR: End-of-Row switches in a data center
EoR：データセンターの行末スイッチ
NA: IPv6 Neighbor Advertisement
NA：IPv6ネイバーアドバタイズメント
ND: IPv6 Neighbor Discovery [RFC4861]
ND：IPv6近隣探索[RFC4861]
NS: IPv6 Neighbor Solicitation
NS：IPv6近隣要請
SA: Source Address
SA：送信元アドレス
ToR: Top-of-Rack Switch (also known as access switch)
ToR：トップオブラックスイッチ（別名アクセススイッチ）
UNA: IPv6 Unsolicited Neighbor Advertisement
UNA：IPv6非送信請求ネイバーアドバタイズメント
VM: Virtual Machine
VM：仮想マシン
Subnet: Refers to the multi-access link subnet referenced by RFC 4903
サブネット：RFC 4903で参照されるマルチアクセスリンクサブネットを指します
Some common network designs for a data center include:
データセンターの一般的なネットワーク設計には次のものがあります。
1) Layer 3 connectivity to the access switch,
1）アクセススイッチへのレイヤー3接続
2) Large Layer 2, and
2）大きなレイヤー2、および
3) Overlay models.
3）オーバーレイモデル。
There is no single network design that fits all cases. The following sections document some of the common practices to scale address resolution under each network design.
すべてのケースに適合する単一のネットワーク設計はありません。次のセクションでは、各ネットワーク設計でアドレス解決を拡張するためのいくつかの一般的な方法について説明します。
This network design configures Layer 3 to the access switches, effectively making the access switches the L2/L3 boundary routers for the attached VMs.
このネットワーク設計は、アクセススイッチにレイヤー3を構成し、接続されたVMのL2 / L3境界ルーターをアクセススイッチにします。
As described in [RFC6820], many data centers are architected so that ARP/ND broadcast/multicast messages are confined to a few ports (interfaces) of the access switches (i.e., ToR switches).
[RFC6820]で説明されているように、ARP / NDブロードキャスト/マルチキャストメッセージがアクセススイッチ（つまり、ToRスイッチ）のいくつかのポート（インターフェース）に限定されるように、多くのデータセンターが設計されています。
Another variant of the Layer 3 solution is a Layer 3 infrastructure configured all the way to servers (or even to the VMs), which confines the ARP/ND broadcast/multicast messages to the small number of VMs within the server.
レイヤー3ソリューションのもう1つのバリアントは、サーバー（またはVM）に至るまで構成されたレイヤー3インフラストラクチャで、サーバー内の少数のVMにARP / NDブロードキャスト/マルチキャストメッセージを制限します。
Advantage: Both ARP and ND scale well. There is no address resolution issue in this design.
利点：ARPとNDの両方が適切に拡張されます。この設計にはアドレス解決の問題はありません。
Disadvantage: The main disadvantage of this network design occurs during VM movement. During VM movement, either VMs need an address change or switches/routers need a configuration change when the VMs are moved to different locations.
欠点：このネットワーク設計の主な欠点は、VMの移動中に発生します。 VMの移動中、VMを別の場所に移動する場合は、VMのアドレスを変更するか、スイッチ/ルーターの構成を変更する必要があります。
Summary: This solution is more suitable to data centers that have a static workload and/or network operators who can reconfigure IP addresses/subnets on switches before any workload change. No protocol changes are suggested.
概要：このソリューションは、静的なワークロードを持つデータセンターや、ワークロードが変更される前にスイッチのIPアドレス/サブネットを再構成できるネットワークオペレーターに適しています。プロトコルの変更は提案されていません。
The ARP/ND broadcast/multicast messages in a Layer 2 domain can negatively affect the L2/L3 boundary routers, especially with a large number of VMs and subnets. This section describes some commonly used practices for reducing the ARP/ND processing required on L2/L3 boundary routers.
レイヤー2ドメインのARP / NDブロードキャスト/マルチキャストメッセージは、特にVMとサブネットが多数ある場合、L2 / L3境界ルーターに悪影響を与える可能性があります。このセクションでは、L2 / L3境界ルーターで必要なARP / ND処理を削減するためによく使用される方法について説明します。
Scenario: When the originating end station doesn't have its default gateway MAC address in its ARP/ND cache and needs to communicate with a peer in a different subnet, it needs to send ARP/ND requests to its default gateway router to resolve the router's MAC address. If there are many subnets on the gateway router and a large number of end stations in those subnets that don't have the gateway MAC address in their ARP/ND caches, the gateway router has to process a very large number of ARP/ND requests. This is often CPU intensive, as ARP/ND messages are usually processed by the CPU (and not in hardware).
シナリオ：送信元のエンドステーションのARP / NDキャッシュにデフォルトゲートウェイのMACアドレスがなく、別のサブネットのピアと通信する必要がある場合、ARP / NDリクエストをデフォルトゲートウェイルーターに送信して、ルータのMACアドレス。ゲートウェイルーターに多数のサブネットがあり、ARP / NDキャッシュにゲートウェイMACアドレスを持たないサブネットに多数のエンドステーションがある場合、ゲートウェイルーターは非常に多数のARP / ND要求を処理する必要があります。 。 ARP / NDメッセージは通常（ハードウェアではなく）CPUによって処理されるため、これは多くの場合CPUを集中的に使用します。
Note: Any centralized configuration that preloads the default MAC addresses is not included in this scenario.
注：デフォルトのMACアドレスをプリロードする一元化された構成は、このシナリオには含まれていません。
Solution: For IPv4 networks, a practice to alleviate this problem is to have the L2/L3 boundary router send periodic gratuitous ARP [GratuitousARP] messages, so that all the connected end stations can refresh their ARP caches. As a result, most (if not all) end stations will not need to send ARP requests for the gateway routers when they need to communicate with external peers.
解決策：IPv4ネットワークの場合、この問題を軽減する方法は、L2 / L3境界ルーターが定期的なgratuitous ARP [GratuitousARP]メッセージを送信するようにして、接続されているすべてのエンドステーションがARPキャッシュを更新できるようにすることです。その結果、（すべてではないにしても）ほとんどのエンドステーションは、外部ピアと通信する必要があるときにゲートウェイルーターにARP要求を送信する必要がなくなります。
For the above scenario, IPv6 end stations are still required to send unicast ND messages to their default gateway router (even with those routers periodically sending Unsolicited Neighbor Advertisements) because IPv6 requires bidirectional path validation.
上記のシナリオでは、IPv6は双方向パス検証を必要とするため、IPv6端末はデフォルトゲートウェイルーターにユニキャストNDメッセージを送信する必要があります（ルーターが定期的に非送信請求ネイバーアドバタイズを送信する場合でも）。
Advantage: This practice results in a reduction of ARP requests to be processed by the L2/L3 boundary router for IPv4.
利点：この方法により、IPv4のL2 / L3境界ルーターで処理されるARP要求が削減されます。
Disadvantage: This practice doesn't reduce ND processing on the L2/L3 boundary router for IPv6 traffic.
短所：この方法では、IPv6トラフィックのL2 / L3境界ルーターでのND処理は削減されません。
Recommendation: If the network is an IPv4-only network, then this approach can be used. For an IPv6 network, one needs to consider the work described in [RFC7048]. Note: ND and Secure Neighbor Discovery (SEND) [RFC3971] use the bidirectional nature of queries to detect and prevent security attacks.
推奨事項：ネットワークがIPv4のみのネットワークの場合、このアプローチを使用できます。 IPv6ネットワークの場合、[RFC7048]で説明されている作業を考慮する必要があります。注：NDおよびSecure Neighbor Discovery（SEND）[RFC3971]は、クエリの双方向性を使用してセキュリティ攻撃を検出および防止します。
Scenario: When an L2/L3 boundary router receives a data frame destined for a local subnet and the destination is not in the router's ARP/ND cache, some routers hold the packet and trigger an ARP/ND request to resolve the L2 address. The router may need to send multiple ARP/ND requests until either a timeout is reached or an ARP/ND reply is received before forwarding the data packets towards the target's MAC address. This process is not only CPU intensive but also buffer intensive.
シナリオ：L2 / L3境界ルーターがローカルサブネット宛のデータフレームを受信し、宛先がルーターのARP / NDキャッシュにない場合、一部のルーターはパケットを保持し、ARP / ND要求をトリガーしてL2アドレスを解決します。データパケットをターゲットのMACアドレスに転送する前に、タイムアウトになるか、ARP / ND応答が受信されるまで、ルーターは複数のARP / ND要求を送信する必要がある場合があります。このプロセスは、CPUを集中的に使用するだけでなく、バッファも集中的に使用します。
Solution: To protect a router from being overburdened by resolving target MAC addresses, one solution is for the router to limit the rate of resolving target MAC addresses for inbound traffic whose target is not in the router's ARP/ND cache. When the rate is exceeded, the incoming traffic whose target is not in the ARP/ND cache is dropped.
解決策：ターゲットMACアドレスを解決してルーターが過負荷にならないように保護するための1つの解決策は、ルーターのARP / NDキャッシュにターゲットがない受信トラフィックのターゲットMACアドレスを解決するレートをルーターが制限することです。レートを超えると、ターゲットがARP / NDキャッシュにない着信トラフィックがドロップされます。
For an IPv4 network, another common practice to alleviate pain caused by this problem is for the router to snoop ARP messages between other hosts, so that its ARP cache can be refreshed with active addresses in the L2 domain. As a result, there is an increased likelihood of the router's ARP cache having the IP-MAC entry when it receives data frames from external peers. [RFC6820] Section 7.1 provides a full description of this problem.
IPv4ネットワークの場合、この問題によって引き起こされる痛みを軽減するもう1つの一般的な方法は、ルーターが他のホスト間でARPメッセージをスヌーピングすることです。これにより、そのARPキャッシュをL2ドメインのアクティブなアドレスで更新できます。その結果、外部ピアからデータフレームを受信するときに、ルーターのARPキャッシュにIP-MACエントリが含まれる可能性が高くなります。 [RFC6820]セクション7.1は、この問題の完全な説明を提供します。
For IPv6 end stations, routers are supposed to send Router Advertisements (RAs) unicast even if they have snooped UNAs/NSs/NAs from those stations. Therefore, this practice allows an L2/L3 boundary to send unicast RAs to the target instead of multicasts. [RFC6820] Section 7.2 has a full description of this problem.
IPv6エンドステーションの場合、ルーターは、それらのステーションからUNA / NS / NAをスヌーピングした場合でも、ルーターアドバタイズ（RA）ユニキャストを送信することになっています。したがって、この方法では、L2 / L3境界がマルチキャストではなくユニキャストRAをターゲットに送信できます。 [RFC6820]セクション7.2に、この問題の詳しい説明があります。
Advantage: This practice results in a reduction of the number of ARP requests that routers have to send upon receiving IPv4 packets and the number of IPv4 data frames from external peers that routers have to hold due to targets not being in the ARP cache.
利点：この方法により、IPv4パケットの受信時にルーターが送信する必要があるARP要求の数と、ターゲットがARPキャッシュにないためにルーターが保持する必要がある外部ピアからのIPv4データフレームの数が減少します。
Disadvantage: The amount of ND processing on routers for IPv6 traffic is not reduced. IPv4 routers still need to hold data packets from external peers and trigger ARP requests if the targets of the data packets either don't exist or are not very active. In this case, IPv4 processing or IPv4 buffers are not reduced.
短所：IPv6トラフィック用のルーターでのND処理の量は減少しません。 IPv4ルーターは、データパケットのターゲットが存在しないか、あまりアクティブでない場合でも、外部ピアからのデータパケットを保持し、ARP要求をトリガーする必要があります。この場合、IPv4処理またはIPv4バッファーは削減されません。
Recommendation: If there is a higher chance of routers receiving data packets that are destined for nonexistent or inactive targets, alternative approaches should be considered.
推奨事項：存在しないターゲットまたは非アクティブなターゲットを宛先とするデータパケットをルーターが受信する可能性が高い場合は、別の方法を検討する必要があります。
The router could be hit with ARP/ND requests twice when the originating and destination stations are in different subnets attached to the same router and those hosts don't communicate with external peers often enough. The first hit is when the originating station in subnet-A initiates an ARP/ND request to the L2/L3 boundary router if the router's MAC is not in the host's cache (Section 5.1.1 above), and the second hit is when the L2/L3 boundary router initiates ARP/ND requests to the target in subnet-B if the target is not in the router's ARP/ND cache (Section 5.1.2 above).
発信ステーションと宛先ステーションが同じルーターに接続された異なるサブネットにあり、それらのホストが外部ピアと十分に頻繁に通信しない場合、ルーターはARP / ND要求で2回ヒットする可能性があります。最初のヒットは、ルーターのMACがホストのキャッシュにない場合（上記のセクション5.1.1）、サブネットAの発信ステーションがL2 / L3境界ルーターへのARP / ND要求を開始したときで、2番目のヒットは、ターゲットがルーターのARP / NDキャッシュにない場合（上記のセクション5.1.2）、L2 / L3境界ルーターは、サブネットBのターゲットへのARP / ND要求を開始します。
Again, practices described in Sections 5.1.1 and 5.1.2 can alleviate some problems in some IPv4 networks.
繰り返しますが、セクション5.1.1および5.1.2で説明されているプラクティスは、一部のIPv4ネットワークにおけるいくつかの問題を軽減することができます。
For IPv6 traffic, the practices described above don't reduce the ND processing on L2/L3 boundary routers.
IPv6トラフィックの場合、上記のプラクティスはL2 / L3境界ルーターでのND処理を削減しません。
Recommendation: Consider the recommended approaches described in Sections 5.1.1 and 5.1.2. However, any solutions that relax the bidirectional requirement of IPv6 ND disable the security that the two-way ND communication exchange provides.
推奨事項：セクション5.1.1および5.1.2で説明されている推奨アプローチを検討してください。ただし、IPv6 NDの双方向要件を緩和するソリューションは、双方向ND通信交換が提供するセキュリティを無効にします。
In a data center environment, the placement of L2 and L3 addressing may be orchestrated by Server (or VM) Management System(s). Therefore, it may be possible for static ARP/ND entries to be configured on routers and/or servers.
データセンター環境では、L2およびL3アドレッシングの配置は、サーバー（またはVM）管理システムによって調整されます。したがって、ルーターやサーバーで静的ARP / NDエントリを構成できる場合があります。
Advantage: This methodology has been used to reduce ARP/ND fluctuations in large-scale data center networks.
利点：この方法は、大規模なデータセンターネットワークにおけるARP / NDの変動を低減するために使用されています。
Disadvantage: When some VMs are added, deleted, or moved, many switches' static entries need to be updated. In a data center with virtualized servers, those events can happen frequently. For example, for an event of one VM being added to one server, if the subnet of this VM spans 15 access switches, all of them need to be updated. Network management mechanisms (SNMP, the Network Configuration Protocol (NETCONF), or proprietary mechanisms) are available to provide updates or incremental updates. However, there is no well-defined approach for switches to synchronize their content with the management system for efficient incremental updates.
欠点：一部のVMを追加、削除、または移動すると、多くのスイッチの静的エントリを更新する必要があります。仮想サーバーを備えたデータセンターでは、これらのイベントが頻繁に発生する可能性があります。たとえば、1つのVMが1つのサーバーに追加されるイベントの場合、このVMのサブネットが15のアクセススイッチにまたがる場合、それらすべてを更新する必要があります。更新または増分更新を提供するために、ネットワーク管理メカニズム（SNMP、ネットワーク構成プロトコル（NETCONF）、または独自のメカニズム）を使用できます。ただし、スイッチがコンテンツを管理システムと同期して効率的な増分更新を行うための、明確に定義されたアプローチはありません。
Recommendation: Additional work may be needed within IETF working groups (e.g., NETCONF, NVO3, I2RS, etc.) to get prompt incremental updates of static ARP/ND entries when changes occur.
推奨事項：IETFワーキンググループ（NETCONF、NVO3、I2RSなど）内で、変更が発生したときに静的ARP / NDエントリの迅速な増分更新を取得するには、追加の作業が必要になる場合があります。
RFC 1027 [RFC1027] specifies one ARP Proxy approach referred to as "Proxy ARP". However, RFC 1027 does not discuss a scaling mechanism. Since the publication of RFC 1027 in 1987, many variants of Proxy ARP have been deployed. RFC 1027's Proxy ARP technique allows a gateway to return its own MAC address on behalf of the target station.
RFC 1027 [RFC1027]は、「プロキシARP」と呼ばれる1つのARPプロキシアプローチを指定しています。ただし、RFC 1027ではスケーリングメカニズムについては説明されていません。 1987年にRFC 1027が公開されて以来、プロキシARPの多くのバリアントが展開されてきました。 RFC 1027のプロキシARP技術により、ゲートウェイはターゲットステーションに代わって独自のMACアドレスを返すことができます。
[ARP_Reduction] describes a type of "ARP Proxy" that allows a ToR switch to snoop ARP requests and return the target station's MAC if the ToR has the information in its cache. However, [RFC4903] doesn't recommend the caching approach described in [ARP_Reduction] because such a cache prevents any type of fast mobility between Layer 2 ports and breaks Secure Neighbor Discovery [RFC3971].
[ARP_Reduction]は、ToRスイッチがARP要求をスヌープし、ToRがキャッシュに情報を持っている場合にターゲットステーションのMACを返すことを可能にする「ARPプロキシ」のタイプを記述します。ただし、[RFC4903]は、[ARP_Reduction]で説明されているキャッシュアプローチを推奨しません。そのようなキャッシュは、レイヤー2ポート間のあらゆるタイプの高速モビリティを妨げ、Secure Neighbor Discovery [RFC3971]を破壊するためです。
IPv6 ND Proxy [RFC4389] specifies a proxy used between an Ethernet segment and other segments, such as wireless or PPP segments. ND Proxy [RFC4389] doesn't allow a proxy to send NA messages on behalf of the target to ensure that the proxy does not interfere with hosts moving from one segment to another. Therefore, the ND Proxy [RFC4389] doesn't reduce the number of ND messages to an L2/L3 boundary router.
IPv6 NDプロキシ[RFC4389]は、イーサネットセグメントと、ワイヤレスセグメントやPPPセグメントなどの他のセグメントとの間で使用されるプロキシを指定します。 NDプロキシ[RFC4389]では、プロキシがターゲットに代わってNAメッセージを送信して、プロキシがあるセグメントから別のセグメントに移動するホストに干渉しないようにすることはできません。したがって、NDプロキシ[RFC4389]は、L2 / L3境界ルーターへのNDメッセージの数を減らしません。
Bottom line, the term "ARP/ND Proxy" has different interpretations, depending on vendors and/or environments.
結論として、「ARP / NDプロキシ」という用語は、ベンダーや環境によって解釈が異なります。
Recommendation: For IPv4, even though those Proxy ARP variants (not RFC 1076) have been used to reduce ARP traffic in various environments, there are many issues with caching.
推奨：IPv4の場合、これらのプロキシARPバリアント（RFC 1076ではない）がさまざまな環境でARPトラフィックを削減するために使用されていても、キャッシングには多くの問題があります。
The IETF should consider making proxy recommendations for data center environments as a transition issue to help DC operators transitioning to IPv6. Section 7 of [RFC4389] ("Guidelines to Proxy Developers") should be considered when developing any new proxy protocols to scale ARP.
IETFは、DC事業者がIPv6に移行するのに役立つ移行の問題として、データセンター環境のプロキシの推奨事項を作成することを検討する必要があります。 [RFC4389]のセクション7（「プロキシ開発者向けガイドライン」）は、ARPをスケーリングするための新しいプロキシプロトコルを開発する際に検討する必要があります。
Multicast snooping (IGMP/MLD) has different implementations and scaling issues. [RFC4541] notes that multicast IGMPv2/v3 snooping has trouble with subnets that include IGMPv2 and IGMPv3. [RFC4541] also notes that MLDv2 snooping requires the use of either destination MAC (DMAC) address filtering or deeper inspection of frames/packets to allow for scaling.
マルチキャストスヌーピング（IGMP / MLD）には、さまざまな実装とスケーリングの問題があります。 [RFC4541]は、マルチキャストIGMPv2 / v3スヌーピングがIGMPv2とIGMPv3を含むサブネットで問題があることを指摘しています。 [RFC4541]はまた、MLDv2スヌーピングには、宛先MAC（DMAC）アドレスフィルタリングの使用、またはスケーリングを可能にするためのフレーム/パケットのより詳細な検査のいずれかが必要であることにも言及しています。
MLDv2 snooping needs to be re-examined for scaling within the DC. Efforts such as IGMP/MLD explicit tracking [IGMP-MLD-Tracking] for downstream hosts need to provide better scaling than IGMP/MLDv2 snooping.
MLDv2スヌーピングは、DC内のスケーリングについて再検討する必要があります。ダウンストリームホストのIGMP / MLD明示的追跡[IGMP-MLD-Tracking]などの取り組みでは、IGMP / MLDv2スヌーピングよりも優れたスケーリングを提供する必要があります。
There are several documents on using overlay networks to scale large Layer 2 networks (or avoid the need for large L2 networks) and enable mobility (e.g., [L3-VM-Mobility], [VXLAN]). Transparent Interconnection of Lots of Links (TRILL) and IEEE 802.1ah (Mac-in-Mac) are other types of overlay networks that can scale Layer 2.
オーバーレイネットワークを使用して大規模なレイヤー2ネットワークを拡張し（または大規模なL2ネットワークの必要性を回避）、モビリティを有効にする（[L3-VM-Mobility]、[VXLAN]など）に関するドキュメントがいくつかあります。多くのリンクの透過的な相互接続（TRILL）とIEEE 802.1ah（Mac-in-Mac）は、レイヤー2を拡張できる他のタイプのオーバーレイネットワークです。
Overlay networks hide the VMs' addresses from the interior switches and routers, thereby greatly reducing the number of addresses exposed to the interior switches and router. The overlay edge nodes that perform the network address encapsulation/decapsulation still handle all remote stations' addresses that communicate with the locally attached end stations.
オーバーレイネットワークは、内部スイッチおよびルーターからVMのアドレスを隠し、内部スイッチおよびルーターに公開されるアドレスの数を大幅に削減します。ネットワークアドレスのカプセル化/カプセル化解除を実行するオーバーレイエッジノードは、ローカルに接続されたエンドステーションと通信するすべてのリモートステーションのアドレスを処理します。
For a large data center with many applications, these applications' IP addresses need to be reachable by external peers. Therefore, the overlay network may have a bottleneck at the gateway node(s) in processing resolving target stations' physical addresses (MAC or IP) and the overlay edge address within the data center.
多くのアプリケーションがある大規模なデータセンターの場合、これらのアプリケーションのIPアドレスは、外部ピアから到達可能である必要があります。したがって、オーバーレイネットワークは、ターゲットステーションの物理アドレス（MACまたはIP）とデータセンター内のオーバーレイエッジアドレスの解決を処理する際に、ゲートウェイノードにボトルネックがある可能性があります。
Here are two approaches that can be used to minimize this problem:
この問題を最小限に抑えるために使用できる2つの方法を次に示します。
1. Use static mapping as described in Section 5.2.
1. セクション5.2の説明に従って、静的マッピングを使用します。
2. Have multiple L2/L3 boundary nodes (i.e., routers), with each handling a subset of stations' addresses that are visible to external peers (e.g., Gateway #1 handles a set of prefixes, Gateway #2 handles another subset of prefixes, etc.).
2. 複数のL2 / L3境界ノード（つまり、ルーター）があり、それぞれが外部ピアに見えるステーションのアドレスのサブセットを処理します（たとえば、ゲートウェイ＃1は一連のプレフィックスを処理し、ゲートウェイ＃2は別のプレフィックスのサブセットを処理するなど） 。）。
This memo describes some common practices that can alleviate the impact of address resolution on L2/L3 gateway routers.
このメモでは、L2 / L3ゲートウェイルーターでのアドレス解決の影響を軽減できるいくつかの一般的な方法について説明します。
In data centers, no single solution fits all deployments. This memo has summarized some practices in various scenarios and the advantages and disadvantages of all of these practices.
データセンターでは、単一のソリューションですべての導入に対応することはできません。このメモは、さまざまなシナリオでのいくつかのプラクティスと、これらすべてのプラクティスの長所と短所を要約しています。
In some of these scenarios, the common practices could be improved by creating and/or extending existing IETF protocols. These protocol change recommendations are:
これらのシナリオの一部では、既存のIETFプロトコルを作成および/または拡張することにより、一般的な方法を改善できます。これらのプロトコル変更の推奨事項は次のとおりです。
o Relax the bidirectional requirement of IPv6 ND in some environments. However, other issues will be introduced when the bidirectional requirement of ND is relaxed. Therefore, it is necessary to have performed a comprehensive study of possible issues prior to making those changes.
o 一部の環境でIPv6 NDの双方向要件を緩和します。ただし、NDの双方向要件が緩和されると、他の問題が発生します。したがって、これらの変更を行う前に、考えられる問題の包括的な調査を行う必要があります。
o Create an incremental "update" scheme for efficient static ARP/ND entries.
o 効率的な静的ARP / NDエントリの増分「更新」スキームを作成します。
o Develop IPv4 ARP/IPv6 ND Proxy standards for use in the data center. Section 7 of [RFC4389] ("Guidelines to Proxy Developers") should be considered when developing any new proxy protocols to scale ARP/ND.
o データセンターで使用するIPv4 ARP / IPv6 NDプロキシ標準を開発します。 [RFC4389]のセクション7（「プロキシ開発者向けガイドライン」）は、ARP / NDをスケーリングするための新しいプロキシプロトコルを開発する際に検討する必要があります。
o Consider scaling issues with IGMP/MLD snooping to determine whether or not new alternatives can provide better scaling.
o IGMP / MLDスヌーピングのスケーリングの問題を検討して、新しい代替案がより良いスケーリングを提供できるかどうかを判断します。
This memo documents existing solutions and proposes additional work that could be initiated to extend various IETF protocols to better scale ARP/ND for the data center environment.
このメモは、既存のソリューションを文書化し、さまざまなIETFプロトコルを拡張してデータセンター環境のARP / NDをより適切にスケーリングするために開始できる追加作業を提案します。
Security is a major issue for data center environments. Therefore, security should be seriously considered when developing any future protocol extensions.
セキュリティは、データセンター環境の主要な問題です。したがって、将来のプロトコル拡張を開発するときは、セキュリティを真剣に検討する必要があります。
We want to acknowledge the ARMD WG and the following people for their valuable inputs to this document: Joel Jaeggli, Dave Thaler, Susan Hares, Benson Schliesser, T. Sridhar, Ron Bonica, Kireeti Kompella, and K.K. Ramakrishnan.
このドキュメントへの貴重な情報提供について、ARMD WGと以下の人々に謝意を表します。ラーマクリシュナン。
[GratuitousARP] Cheshire, S., "IPv4 Address Conflict Detection", RFC 5227, July 2008.
[GratuitousARP] Cheshire、S。、「IPv4 Address Conflict Detection」、RFC 5227、2008年7月。
[RFC826] Plummer, D., "Ethernet Address Resolution Protocol: Or Converting Network Protocol Addresses to 48.bit Ethernet Address for Transmission on Ethernet Hardware", STD 37, RFC 826, November 1982.
[RFC826]プラムマー、D。、「イーサネットアドレス解決プロトコル：またはネットワークプロトコルアドレスを48ビットイーサネットアドレスに変換してイーサネットハードウェアで送信する」、STD 37、RFC 826、1982年11月。
[RFC1027] Carl-Mitchell, S. and J. Quarterman, "Using ARP to implement transparent subnet gateways", RFC 1027, October 1987.
[RFC1027] Carl-Mitchell、S.およびJ. Quarterman、「ARPを使用した透過サブネットゲートウェイの実装」、RFC 1027、1987年10月。
[RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005.
[RFC3971] Arkko、J.、Ed。、Kempf、J.、Zill、B.、and P. Nikander、 "SEcure Neighbor Discovery（SEND）"、RFC 3971、March 2005。
[RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery Proxies (ND Proxy)", RFC 4389, April 2006.
[RFC4389] Thaler、D.、Talwar、M。、およびC. Patel、「Neighbor Discovery Proxies（ND Proxy）」、RFC 4389、2006年4月。
[RFC4541] Christensen, M., Kimball, K., and F. Solensky, "Considerations for Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Snooping Switches", RFC 4541, May 2006.
[RFC4541] Christensen、M.、Kimball、K。、およびF. Solensky、「インターネットグループ管理プロトコル（IGMP）およびマルチキャストリスナーディスカバリ（MLD）スヌーピングスイッチに関する考慮事項」、RFC 4541、2006年5月。
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007.
[RFC4861] Narten、T.、Nordmark、E.、Simpson、W。、およびH. Soliman、「Neighbor Discovery for IP version 6（IPv6）」、RFC 4861、2007年9月。
[RFC4903] Thaler, D., "Multi-Link Subnet Issues", RFC 4903, June 2007.
[RFC4903]ターラー、D。、「マルチリンクサブネットの問題」、RFC 4903、2007年6月。
[RFC6820] Narten, T., Karir, M., and I. Foo, "Address Resolution Problems in Large Data Center Networks", RFC 6820, January 2013.
[RFC6820] Narten、T.、Kairr、M。、およびI. Foo、「大規模なデータセンターネットワークにおけるアドレス解決の問題」、RFC 6820、2013年1月。
[ARMD-Statistics] Karir, M. and J. Rees, "Address Resolution Statistics", Work in Progress, July 2011.
[ARMD-Statistics] Karir、M。およびJ. Rees、「Address Resolution Statistics」、Work in Progress、2011年7月。
[ARP_Reduction] Shah, H., Ghanwani, A., and N. Bitar, "ARP Broadcast Reduction for Large Data Centers", Work in Progress, October 2011.
[ARP_Reduction] Shah、H.、Ghanwani、A。、およびN. Bitar、「大規模データセンター向けのARPブロードキャスト削減」、作業中、2011年10月。
[IGMP-MLD-Tracking] Asaeda, H., "IGMP/MLD-Based Explicit Membership Tracking Function for Multicast Routers", Work in Progress, December 2013.
[IGMP-MLD-Tracking]浅枝浩子、「IGMP / MLDベースのマルチキャストルーター用の明示的なメンバーシップ追跡機能」、作業中、2013年12月。
[L3-VM-Mobility] Kumari, W. and J. Halpern, "Virtual Machine mobility in L3 Networks", Work in Progress, August 2011.
[L3-VM-Mobility] Kumari、W.およびJ. Halpern、「L3ネットワークにおける仮想マシンモビリティ」、Work in Progress、2011年8月。
[Multi-Link] Thaler, D. and C. Huitema, "Multi-link Subnet Support in IPv6", Work in Progress, June 2002.
[マルチリンク] Thaler、D。およびC. Huitema、「IPv6でのマルチリンクサブネットサポート」、進行中の作業、2002年6月。
[RFC1076] Trewitt, G. and C. Partridge, "HEMS Monitoring and Control Language", RFC 1076, November 1988.
[RFC1076] Trewitt、G。およびC. Partridge、「HEMS監視および制御言語」、RFC 1076、1988年11月。
[RFC7048] Nordmark, E. and I. Gashinsky, "Neighbor Unreachability Detection Is Too Impatient", RFC 7048, January 2014.
[RFC7048] Nordmark、E。およびI. Gashinsky、「Neighbor Unreachability Detection Is Too Inpatient」、RFC 7048、2014年1月。
[VXLAN] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, L., Sridhar, T., Bursell, M., and C. Wright, "VXLAN: A Framework for Overlaying Virtualized Layer 2 Networks over Layer 3 Networks", Work in Progress, April 2014.
[VXLAN] Mahalingam、M.、Dutt、D.、Duda、K.、Agarwal、P.、Kreeger、L.、Sridhar、T.、Bursell、M。、およびC. Wright、「VXLAN：A Overlaying for Frameworkレイヤ3ネットワーク上の仮想化されたレイヤ2ネットワーク」、作業中、2014年4月。
Authors' Addresses
著者のアドレス
Linda Dunbar Huawei Technologies 5340 Legacy Drive, Suite 175 Plano, TX 75024 USA
Linda Dunbar Huawei Technologies 5340 Legacy Drive、Suite 175 Plano、TX 75024 USA
Phone: (469) 277 5840 EMail: ldunbar@huawei.com
電話：（469）277 5840メール：ldunbar@huawei.com
Warren Kumari Google 1600 Amphitheatre Parkway Mountain View, CA 94043 USA
ウォーレンクマリGoogle 1600 Amphitheatre Parkway Mountain View、CA 94043 USA
EMail: warren@kumari.net
Igor Gashinsky Yahoo 45 West 18th Street 6th floor New York, NY 10011 USA
Igor Gashinsky Yahoo 45 West 18th Street 6th floor New York、NY 10011 USA
EMail: igor@yahoo-inc.com