[要約] 要約： RFC 7348は、仮想化されたレイヤ2ネットワークをレイヤ3ネットワーク上にオーバーレイするためのVXLANのフレームワークについて説明しています。目的： VXLANは、スケーラビリティと柔軟性を提供するために、仮想化されたネットワーク環境でのレイヤ2通信をサポートすることを目的としています。
Independent Submission M. Mahalingam
Request for Comments: 7348 Storvisor
Category: Informational D. Dutt
ISSN: 2070-1721 Cumulus Networks
K. Duda
Arista
P. Agarwal
Broadcom
L. Kreeger
Cisco
T. Sridhar
VMware
M. Bursell
Intel
C. Wright
Red Hat
August 2014
Virtual eXtensible Local Area Network (VXLAN): A Framework for Overlaying Virtualized Layer 2 Networks over Layer 3 Networks
Virtual eXtensible Local Area Network（VXLAN）：仮想化されたレイヤー2ネットワークをレイヤー3ネットワークにオーバーレイするためのフレームワーク
Abstract
概要
This document describes Virtual eXtensible Local Area Network (VXLAN), which is used to address the need for overlay networks within virtualized data centers accommodating multiple tenants. The scheme and the related protocols can be used in networks for cloud service providers and enterprise data centers. This memo documents the deployed VXLAN protocol for the benefit of the Internet community.
このドキュメントでは、仮想eXtensible Local Area Network（VXLAN）について説明します。VXLANは、複数のテナントを収容する仮想化データセンター内のオーバーレイネットワークのニーズに対処するために使用されます。このスキームと関連プロトコルは、クラウドサービスプロバイダーとエンタープライズデータセンターのネットワークで使用できます。このメモは、インターネットコミュニティのために配備されたVXLANプロトコルを文書化しています。
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/rfc7348.
このドキュメントの現在のステータス、エラッタ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7348で入手できます。
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 ....................................................3
1.1. Acronyms and Definitions ...................................4
2. Conventions Used in This Document ...............................4
3. VXLAN Problem Statement .........................................5
3.1. Limitations Imposed by Spanning Tree and VLAN Ranges .......5
3.2. Multi-tenant Environments ..................................5
3.3. Inadequate Table Sizes at ToR Switch .......................6
4. VXLAN ...........................................................6
4.1. Unicast VM-to-VM Communication .............................7
4.2. Broadcast Communication and Mapping to Multicast ...........8
4.3. Physical Infrastructure Requirements .......................9
5. VXLAN Frame Format .............................................10
6. VXLAN Deployment Scenarios .....................................14
6.1. Inner VLAN Tag Handling ...................................18
7. Security Considerations ........................................18
8. IANA Considerations ............................................19
9. References .....................................................19
9.1. Normative References ......................................19
9.2. Informative References ....................................20
10. Acknowledgments ...............................................21
Server virtualization has placed increased demands on the physical network infrastructure. A physical server now has multiple Virtual Machines (VMs) each with its own Media Access Control (MAC) address. This requires larger MAC address tables in the switched Ethernet network due to potential attachment of and communication among hundreds of thousands of VMs.
サーバーの仮想化により、物理ネットワークインフラストラクチャに対する要求が高まっています。これで、物理サーバーに複数の仮想マシン（VM）があり、それぞれに独自のメディアアクセス制御（MAC）アドレスがあります。数十万のVMが接続されたり、VM間で通信したりする可能性があるため、スイッチドイーサネットネットワークではより大きなMACアドレステーブルが必要です。
In the case when the VMs in a data center are grouped according to their Virtual LAN (VLAN), one might need thousands of VLANs to partition the traffic according to the specific group to which the VM may belong. The current VLAN limit of 4094 is inadequate in such situations.
データセンター内のVMが仮想LAN（VLAN）に従ってグループ化されている場合、VMが属している特定のグループに従ってトラフィックを分割するために数千のVLANが必要になることがあります。現在のVLAN制限の4094は、このような状況では不十分です。
Data centers are often required to host multiple tenants, each with their own isolated network domain. Since it is not economical to realize this with dedicated infrastructure, network administrators opt to implement isolation over a shared network. In such scenarios, a common problem is that each tenant may independently assign MAC addresses and VLAN IDs leading to potential duplication of these on the physical network.
多くの場合、データセンターは、それぞれが独自の分離されたネットワークドメインを持つ複数のテナントをホストする必要があります。専用インフラストラクチャでこれを実現するのは経済的でないため、ネットワーク管理者は共有ネットワーク上で分離を実装することを選択します。このようなシナリオでは、一般的な問題として、各テナントが個別にMACアドレスとVLAN IDを割り当て、物理ネットワーク上で重複する可能性があります。
An important requirement for virtualized environments using a Layer 2 physical infrastructure is having the Layer 2 network scale across the entire data center or even between data centers for efficient allocation of compute, network, and storage resources. In such networks, using traditional approaches like the Spanning Tree Protocol (STP) for a loop-free topology can result in a large number of disabled links.
レイヤー2物理インフラストラクチャを使用する仮想化環境の重要な要件は、コンピューティング、ネットワーク、およびストレージリソースを効率的に割り当てるために、データセンター全体またはデータセンター間でレイヤー2ネットワークを拡張することです。このようなネットワークでは、スパニングツリープロトコル（STP）などの従来のアプローチをループのないトポロジに使用すると、多数の無効なリンクが発生する可能性があります。
The last scenario is the case where the network operator prefers to use IP for interconnection of the physical infrastructure (e.g., to achieve multipath scalability through Equal-Cost Multipath (ECMP), thus avoiding disabled links). Even in such environments, there is a need to preserve the Layer 2 model for inter-VM communication.
最後のシナリオは、ネットワークオペレーターが物理インフラストラクチャの相互接続にIPを使用することを好む場合です（たとえば、等コストマルチパス（ECMP）によってマルチパススケーラビリティを実現し、無効なリンクを回避します）。このような環境でも、VM間通信のためにレイヤー2モデルを保持する必要があります。
The scenarios described above lead to a requirement for an overlay network. This overlay is used to carry the MAC traffic from the individual VMs in an encapsulated format over a logical "tunnel".
上記のシナリオは、オーバーレイネットワークの要件につながります。このオーバーレイは、個々のVMからのMACトラフィックを、カプセル化された形式で論理的な「トンネル」を介して伝送するために使用されます。
This document details a framework termed "Virtual eXtensible Local Area Network (VXLAN)" that provides such an encapsulation scheme to address the various requirements specified above. This memo documents the deployed VXLAN protocol for the benefit of the Internet community.
このドキュメントでは、「仮想eXtensible Local Area Network（VXLAN）」と呼ばれるフレームワークについて詳しく説明します。このフレームワークは、上記で指定されたさまざまな要件に対処するためのカプセル化スキームを提供します。このメモは、インターネットコミュニティのために配備されたVXLANプロトコルを文書化しています。
ACL Access Control List
ACLアクセス制御リスト
ECMP Equal-Cost Multipath
ECMP等コストマルチパス
IGMP Internet Group Management Protocol
IGMPインターネットグループ管理プロトコル
IHL Internet Header Length
IHLインターネットヘッダーの長さ
MTU Maximum Transmission Unit
MTU最大伝送ユニット
PIM Protocol Independent Multicast
PIMプロトコルに依存しないマルチキャスト
SPB Shortest Path Bridging
SPB最短パスブリッジング
STP Spanning Tree Protocol
STPスパニングツリープロトコル
ToR Top of Rack
ToR Top of Rack
TRILL Transparent Interconnection of Lots of Links
多くのリンクのTRILL透過的な相互接続
VLAN Virtual Local Area Network
VLAN仮想ローカルエリアネットワーク
VM Virtual Machine
VM仮想マシン
VNI VXLAN Network Identifier (or VXLAN Segment ID)
VNI VXLANネットワーク識別子（またはVXLANセグメントID）
VTEP VXLAN Tunnel End Point. An entity that originates and/or terminates VXLAN tunnels
VTEP VXLANトンネルエンドポイント。 VXLANトンネルを開始または終了するエンティティ
VXLAN Virtual eXtensible Local Area Network
VXLAN Virtual eXtensible Local Area Network
VXLAN Segment VXLAN Layer 2 overlay network over which VMs communicate
VXLANセグメントVMが通信するVXLANレイヤー2オーバーレイネットワーク
VXLAN Gateway an entity that forwards traffic between VXLANs
VXLANゲートウェイは、VXLAN間でトラフィックを転送するエンティティ
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 RFC 2119 [RFC2119]で説明されているように解釈されます。
This section provides further details on the areas that VXLAN is intended to address. The focus is on the networking infrastructure within the data center and the issues related to them.
このセクションでは、VXLANが対処することを目的とした領域の詳細について説明します。データセンター内のネットワークインフラストラクチャとそれに関連する問題に焦点を当てています。
Current Layer 2 networks use the IEEE 802.1D Spanning Tree Protocol (STP) [802.1D] to avoid loops in the network due to duplicate paths. STP blocks the use of links to avoid the replication and looping of frames. Some data center operators see this as a problem with Layer 2 networks in general, since with STP they are effectively paying for more ports and links than they can really use. In addition, resiliency due to multipathing is not available with the STP model. Newer initiatives, such as TRILL [RFC6325] and SPB [802.1aq], have been proposed to help with multipathing and surmount some of the problems with STP. STP limitations may also be avoided by configuring servers within a rack to be on the same Layer 3 network, with switching happening at Layer 3 both within the rack and between racks. However, this is incompatible with a Layer 2 model for inter-VM communication.
現在のレイヤー2ネットワークは、IEEE 802.1Dスパニングツリープロトコル（STP）[802.1D]を使用して、パスの重複によるネットワークのループを回避しています。 STPはリンクの使用をブロックして、フレームの複製とループを回避します。一部のデータセンターオペレーターは、STPを使用すると、実際に使用できるよりも多くのポートとリンクに効果的に料金を支払っているので、これを一般にレイヤー2ネットワークの問題と見なしています。また、マルチパスによる復元力はSTPモデルでは利用できません。 TRILL [RFC6325]やSPB [802.1aq]などの新しいイニシアチブは、マルチパスを支援し、STPの問題のいくつかを克服するために提案されています。ラック内のサーバーを同じレイヤー3ネットワーク上に構成し、切り替えがラック内とラック間でレイヤー3で行われるようにすることで、STP制限を回避することもできます。ただし、これはVM間通信のレイヤー2モデルと互換性がありません。
A key characteristic of Layer 2 data center networks is their use of Virtual LANs (VLANs) to provide broadcast isolation. A 12-bit VLAN ID is used in the Ethernet data frames to divide the larger Layer 2 network into multiple broadcast domains. This has served well for many data centers that require fewer than 4094 VLANs. With the growing adoption of virtualization, this upper limit is seeing pressure. Moreover, due to STP, several data centers limit the number of VLANs that could be used. In addition, requirements for multi-tenant environments accelerate the need for larger VLAN limits, as discussed in Section 3.3.
レイヤー2データセンターネットワークの重要な特徴は、仮想LAN（VLAN）を使用してブロードキャストを分離することです。 12ビットのVLAN IDは、イーサネットデータフレームで使用され、より大きなレイヤ2ネットワークを複数のブロードキャストドメインに分割します。これは、4094未満のVLANを必要とする多くのデータセンターに適しています。仮想化の採用が拡大するにつれて、この上限にはプレッシャーがかかっています。さらに、STPにより、いくつかのデータセンターでは、使用できるVLANの数が制限されています。さらに、セクション3.3で説明するように、マルチテナント環境の要件は、より大きなVLAN制限の必要性を加速させます。
Cloud computing involves on-demand elastic provisioning of resources for multi-tenant environments. The most common example of cloud computing is the public cloud, where a cloud service provider offers these elastic services to multiple customers/tenants over the same physical infrastructure.
クラウドコンピューティングには、マルチテナント環境用のリソースのオンデマンドの弾性プロビジョニングが含まれます。クラウドコンピューティングの最も一般的な例は、パブリッククラウドです。クラウドサービスプロバイダーは、これらの柔軟なサービスを同じ物理インフラストラクチャ上の複数の顧客/テナントに提供します。
Isolation of network traffic by a tenant could be done via Layer 2 or Layer 3 networks. For Layer 2 networks, VLANs are often used to segregate traffic -- so a tenant could be identified by its own VLAN, for example. Due to the large number of tenants that a cloud provider might service, the 4094 VLAN limit is often inadequate. In addition, there is often a need for multiple VLANs per tenant, which exacerbates the issue.
テナントによるネットワークトラフィックの分離は、レイヤー2またはレイヤー3ネットワークを介して行うことができます。レイヤー2ネットワークの場合、VLANはトラフィックの分離によく使用されます。たとえば、テナントは独自のVLANで識別できます。クラウドプロバイダーがサービスを提供する可能性がある多数のテナントが原因で、4094のVLAN制限は多くの場合不十分です。さらに、多くの場合、テナントごとに複数のVLANが必要になるため、問題が悪化します。
A related use case is cross-pod expansion. A pod typically consists of one or more racks of servers with associated network and storage connectivity. Tenants may start off on a pod and, due to expansion, require servers/VMs on other pods, especially in the case when tenants on the other pods are not fully utilizing all their resources. This use case requires a "stretched" Layer 2 environment connecting the individual servers/VMs.
関連するユースケースは、クロスポッド拡張です。ポッドは通常、関連するネットワークおよびストレージ接続を備えたサーバーの1つ以上のラックで構成されます。特に他のポッドのテナントがすべてのリソースを完全に利用していない場合は、テナントがポッドから開始し、拡張のために、他のポッドにサーバー/ VMが必要になります。この使用例では、個々のサーバー/ VMを接続する「ストレッチ」レイヤー2環境が必要です。
Layer 3 networks are not a comprehensive solution for multi-tenancy either. Two tenants might use the same set of Layer 3 addresses within their networks, which requires the cloud provider to provide isolation in some other form. Further, requiring all tenants to use IP excludes customers relying on direct Layer 2 or non-IP Layer 3 protocols for inter VM communication.
レイヤー3ネットワークもマルチテナンシーの包括的なソリューションではありません。 2つのテナントがネットワーク内で同じレイヤー3アドレスのセットを使用する場合があるため、クラウドプロバイダーは他の形式で分離を提供する必要があります。さらに、すべてのテナントがIPを使用する必要があるため、VM間通信に直接レイヤー2または非IPレイヤー3プロトコルを使用している顧客は除外されます。
Today's virtualized environments place additional demands on the MAC address tables of Top-of-Rack (ToR) switches that connect to the servers. Instead of just one MAC address per server link, the ToR now has to learn the MAC addresses of the individual VMs (which could range in the hundreds per server). This is needed because traffic to/from the VMs to the rest of the physical network will traverse the link between the server and the switch. A typical ToR switch could connect to 24 or 48 servers depending upon the number of its server-facing ports. A data center might consist of several racks, so each ToR switch would need to maintain an address table for the communicating VMs across the various physical servers. This places a much larger demand on the table capacity compared to non-virtualized environments.
今日の仮想化環境では、サーバーに接続するトップオブラック（ToR）スイッチのMACアドレステーブルに追加の要求が課されます。サーバーリンクごとに1つのMACアドレスだけでなく、ToRは個々のVMのMACアドレスを学習する必要があります（サーバーごとに数百にも及ぶ可能性があります）。これは、VMとの間の物理ネットワークの残りの部分へのトラフィックがサーバーとスイッチ間のリンクを通過するために必要です。一般的なToRスイッチは、サーバーに面したポートの数に応じて、24台または48台のサーバーに接続できます。データセンターは複数のラックで構成される場合があるため、各ToRスイッチは、さまざまな物理サーバー間で通信するVMのアドレステーブルを維持する必要があります。これにより、仮想化されていない環境と比較して、テーブルの容量に対する要求がはるかに大きくなります。
If the table overflows, the switch may stop learning new addresses until idle entries age out, leading to significant flooding of subsequent unknown destination frames.
テーブルがオーバーフローした場合、スイッチは、アイドルエントリが期限切れになるまで新しいアドレスの学習を停止し、その後の不明な宛先フレームが大幅にフラッディングする可能性があります。
VXLAN (Virtual eXtensible Local Area Network) addresses the above requirements of the Layer 2 and Layer 3 data center network infrastructure in the presence of VMs in a multi-tenant environment. It runs over the existing networking infrastructure and provides a means to "stretch" a Layer 2 network. In short, VXLAN is a Layer 2 overlay scheme on a Layer 3 network. Each overlay is termed a VXLAN segment. Only VMs within the same VXLAN segment can communicate with each other. Each VXLAN segment is identified through a 24-bit segment ID, termed the "VXLAN Network Identifier (VNI)". This allows up to 16 M VXLAN segments to coexist within the same administrative domain.
VXLAN（Virtual eXtensible Local Area Network）は、マルチテナント環境でVMが存在する場合のレイヤー2およびレイヤー3データセンターネットワークインフラストラクチャの上記の要件に対応します。既存のネットワークインフラストラクチャ上で動作し、レイヤ2ネットワークを「拡張」する手段を提供します。つまり、VXLANは、レイヤー3ネットワーク上のレイヤー2オーバーレイ方式です。各オーバーレイはVXLANセグメントと呼ばれます。同じVXLANセグメント内のVMのみが相互に通信できます。各VXLANセグメントは、「VXLANネットワーク識別子（VNI）」と呼ばれる24ビットのセグメントIDによって識別されます。これにより、最大16 MのVXLANセグメントを同じ管理ドメイン内で共存させることができます。
The VNI identifies the scope of the inner MAC frame originated by the individual VM. Thus, you could have overlapping MAC addresses across segments but never have traffic "cross over" since the traffic is isolated using the VNI. The VNI is in an outer header that encapsulates the inner MAC frame originated by the VM. In the following sections, the term "VXLAN segment" is used interchangeably with the term "VXLAN overlay network".
VNIは、個々のVMが発信した内部MACフレームのスコープを識別します。したがって、トラフィックはVNIを使用して分離されるため、セグメント間でMACアドレスが重複している可能性がありますが、トラフィックが「クロスオーバー」することはありません。 VNIは、VMから発信された内部MACフレームをカプセル化する外部ヘッダーにあります。以下のセクションでは、「VXLANセグメント」という用語は、「VXLANオーバーレイネットワーク」という用語と同じ意味で使用されています。
Due to this encapsulation, VXLAN could also be called a tunneling scheme to overlay Layer 2 networks on top of Layer 3 networks. The tunnels are stateless, so each frame is encapsulated according to a set of rules. The end point of the tunnel (VXLAN Tunnel End Point or VTEP) discussed in the following sections is located within the hypervisor on the server that hosts the VM. Thus, the VNI- and VXLAN-related tunnel / outer header encapsulation are known only to the VTEP -- the VM never sees it (see Figure 1). Note that it is possible that VTEPs could also be on a physical switch or physical server and could be implemented in software or hardware. One use case where the VTEP is a physical switch is discussed in Section 6 on VXLAN deployment scenarios.
このカプセル化により、VXLANは、レイヤー3ネットワークの上にレイヤー2ネットワークをオーバーレイするトンネリングスキームとも呼ばれます。トンネルはステートレスであるため、各フレームは一連のルールに従ってカプセル化されます。次のセクションで説明するトンネルのエンドポイント（VXLANトンネルエンドポイントまたはVTEP）は、VMをホストするサーバーのハイパーバイザー内にあります。したがって、VNIおよびVXLAN関連のトンネル/外部ヘッダーのカプセル化はVTEPだけが知っています-VMはそれを認識しません（図1を参照）。 VTEPが物理スイッチまたは物理サーバー上にあり、ソフトウェアまたはハードウェアに実装されている可能性があることに注意してください。 VTEPが物理スイッチである1つの使用例については、VXLAN展開シナリオのセクション6で説明します。
The following sections discuss typical traffic flow scenarios in a VXLAN environment using one type of control scheme -- data plane learning. Here, the association of VM's MAC to VTEP's IP address is discovered via source-address learning. Multicast is used for carrying unknown destination, broadcast, and multicast frames.
次のセクションでは、データプレーン学習という1種類の制御方式を使用したVXLAN環境での一般的なトラフィックフローシナリオについて説明します。ここでは、VMのMACとVTEPのIPアドレスとの関連付けは、ソースアドレス学習によって発見されます。マルチキャストは、未知の宛先、ブロードキャスト、およびマルチキャストフレームを運ぶために使用されます。
In addition to a learning-based control plane, there are other schemes possible for the distribution of the VTEP IP to VM MAC mapping information. Options could include a central authority-/directory-based lookup by the individual VTEPs, distribution of this mapping information to the VTEPs by the central authority, and so on. These are sometimes characterized as push and pull models, respectively. This document will focus on the data plane learning scheme as the control plane for VXLAN.
学習ベースのコントロールプレーンに加えて、VTEP IPからVM MACへのマッピング情報の配布には、他の方式も可能です。オプションには、個々のVTEPによる中央機関/ディレクトリベースの検索、中央機関によるVTEPへのこのマッピング情報の配布などが含まれます。これらは、それぞれプッシュモデルとプルモデルとして特徴付けられる場合があります。このドキュメントでは、VXLANのコントロールプレーンとしてのデータプレーン学習スキームに焦点を当てます。
Consider a VM within a VXLAN overlay network. This VM is unaware of VXLAN. To communicate with a VM on a different host, it sends a MAC frame destined to the target as normal. The VTEP on the physical host looks up the VNI to which this VM is associated. It then determines if the destination MAC is on the same segment and if there is a mapping of the destination MAC address to the remote VTEP. If so, an outer header comprising an outer MAC, outer IP header, and VXLAN header (see Figure 1 in Section 5 for frame format) are prepended to the original MAC frame. The encapsulated packet is forwarded towards the remote VTEP. Upon reception, the remote VTEP verifies the validity of the VNI and whether or not there is a VM on that VNI using a MAC address that matches the inner destination MAC address. If so, the packet is stripped of its encapsulating headers and passed on to the destination VM. The destination VM never knows about the VNI or that the frame was transported with a VXLAN encapsulation.
VXLANオーバーレイネットワーク内のVMについて考えます。このVMはVXLANを認識しません。別のホスト上のVMと通信するために、通常のようにターゲット宛てのMACフレームを送信します。物理ホストのVTEPは、このVMが関連付けられているVNIを検索します。次に、宛先MACが同じセグメント上にあるかどうか、および宛先MACアドレスのリモートVTEPへのマッピングがあるかどうかを判別します。その場合、外部MAC、外部IPヘッダー、およびVXLANヘッダーで構成される外部ヘッダー（フレーム形式については、セクション5の図1を参照）が元のMACフレームの前に付加されます。カプセル化されたパケットは、リモートVTEPに転送されます。受信すると、リモートVTEPはVNIの有効性を検証し、そのVNIに内部宛先MACアドレスと一致するMACアドレスを使用してVMが存在するかどうかを検証します。その場合、パケットはカプセル化されているヘッダーが取り除かれ、宛先VMに渡されます。宛先VMは、VNIについて、またはフレームがVXLANカプセル化で転送されたことを決して知りません。
In addition to forwarding the packet to the destination VM, the remote VTEP learns the mapping from inner source MAC to outer source IP address. It stores this mapping in a table so that when the destination VM sends a response packet, there is no need for an "unknown destination" flooding of the response packet.
パケットを宛先VMに転送することに加えて、リモートVTEPは内部ソースMACから外部ソースIPアドレスへのマッピングを学習します。宛先VMが応答パケットを送信するときに、応答パケットの「不明な宛先」フラッディングが発生しないように、このマッピングをテーブルに格納します。
Determining the MAC address of the destination VM prior to the transmission by the source VM is performed as with non-VXLAN environments except as described in Section 4.2. Broadcast frames are used but are encapsulated within a multicast packet, as detailed in the Section 4.2.
ソースVMによる送信の前に宛先VMのMACアドレスを決定することは、セクション4.2で説明されている場合を除いて、非VXLAN環境と同様に実行されます。ブロードキャストフレームが使用されますが、セクション4.2で詳しく説明するように、マルチキャストパケット内にカプセル化されます。
Consider the VM on the source host attempting to communicate with the destination VM using IP. Assuming that they are both on the same subnet, the VM sends out an Address Resolution Protocol (ARP) broadcast frame. In the non-VXLAN environment, this frame would be sent out using MAC broadcast across all switches carrying that VLAN.
IPを使用して宛先VMと通信しようとしているソースホスト上のVMを検討してください。両方が同じサブネット上にあると仮定すると、VMはアドレス解決プロトコル（ARP）ブロードキャストフレームを送信します。非VXLAN環境では、このフレームは、そのVLANを伝送するすべてのスイッチにわたってMACブロードキャストを使用して送信されます。
With VXLAN, a header including the VXLAN VNI is inserted at the beginning of the packet along with the IP header and UDP header. However, this broadcast packet is sent out to the IP multicast group on which that VXLAN overlay network is realized.
VXLANでは、VXLAN VNIを含むヘッダーがIPヘッダーとUDPヘッダーと共にパケットの先頭に挿入されます。ただし、このブロードキャストパケットは、そのVXLANオーバーレイネットワークが実現されているIPマルチキャストグループに送信されます。
To effect this, we need to have a mapping between the VXLAN VNI and the IP multicast group that it will use. This mapping is done at the management layer and provided to the individual VTEPs through a management channel. Using this mapping, the VTEP can provide IGMP membership reports to the upstream switch/router to join/leave the VXLAN-related IP multicast groups as needed. This will enable pruning of the leaf nodes for specific multicast traffic addresses based on whether a member is available on this host using the specific multicast address (see [RFC4541]). In addition, use of multicast routing protocols like Protocol Independent Multicast - Sparse Mode (PIM-SM see [RFC4601]) will provide efficient multicast trees within the Layer 3 network.
これを有効にするには、VXLAN VNIとそれが使用するIPマルチキャストグループ間のマッピングが必要です。このマッピングは管理層で行われ、管理チャネルを通じて個々のVTEPに提供されます。このマッピングを使用して、VTEPはIGMPメンバーシップレポートをアップストリームスイッチ/ルーターに提供し、必要に応じてVXLAN関連のIPマルチキャストグループに参加/脱退できます。これにより、特定のマルチキャストアドレスを使用してこのホストでメンバーが使用可能かどうかに基づいて、特定のマルチキャストトラフィックアドレスのリーフノードのプルーニングが可能になります（[RFC4541]を参照）。さらに、Protocol Independent Multicast-Sparse Mode（PIM-SM see [RFC4601]）などのマルチキャストルーティングプロトコルを使用すると、レイヤ3ネットワーク内に効率的なマルチキャストツリーが提供されます。
The VTEP will use (*,G) joins. This is needed as the set of VXLAN tunnel sources is unknown and may change often, as the VMs come up / go down across different hosts. A side note here is that since each VTEP can act as both the source and destination for multicast packets, a protocol like bidirectional PIM (BIDIR-PIM -- see [RFC5015]) would be more efficient.
VTEPは（*、G）結合を使用します。これは、VXLANトンネルソースのセットが不明であり、さまざまなホスト間でVMが起動/停止するときに頻繁に変更される可能性があるために必要です。ここでの付記は、各VTEPがマルチキャストパケットの送信元と宛先の両方として機能できるため、双方向PIM（BIDIR-PIM-[RFC5015]を参照）などのプロトコルがより効率的であることです。
The destination VM sends a standard ARP response using IP unicast. This frame will be encapsulated back to the VTEP connecting the originating VM using IP unicast VXLAN encapsulation. This is possible since the mapping of the ARP response's destination MAC to the VXLAN tunnel end point IP was learned earlier through the ARP request.
宛先VMは、IPユニキャストを使用して標準のARP応答を送信します。このフレームは、IPユニキャストVXLANカプセル化を使用して、元のVMを接続するVTEPにカプセル化されます。 ARP応答の宛先MACのVXLANトンネルエンドポイントIPへのマッピングは、ARP要求を通じて以前に学習されたため、これが可能です。
Note that multicast frames and "unknown MAC destination" frames are also sent using the multicast tree, similar to the broadcast frames.
マルチキャストフレームと「不明なMAC宛先」フレームも、ブロードキャストフレームと同様に、マルチキャストツリーを使用して送信されることに注意してください。
When IP multicast is used within the network infrastructure, a multicast routing protocol like PIM-SM can be used by the individual Layer 3 IP routers/switches within the network. This is used to build efficient multicast forwarding trees so that multicast frames are only sent to those hosts that have requested to receive them.
ネットワークインフラストラクチャ内でIPマルチキャストを使用する場合、PIM-SMなどのマルチキャストルーティングプロトコルを、ネットワーク内の個々のレイヤー3 IPルーター/スイッチで使用できます。これは、効率的なマルチキャスト転送ツリーを構築するために使用され、マルチキャストフレームは受信を要求したホストにのみ送信されます。
Similarly, there is no requirement that the actual network connecting the source VM and destination VM should be a Layer 3 network: VXLAN can also work over Layer 2 networks. In either case, efficient multicast replication within the Layer 2 network can be achieved using IGMP snooping.
同様に、ソースVMと宛先VMを接続する実際のネットワークがレイヤー3ネットワークである必要はありません。VXLANはレイヤー2ネットワーク上でも機能します。どちらの場合でも、レイヤ2ネットワーク内での効率的なマルチキャストレプリケーションは、IGMPスヌーピングを使用して実現できます。
VTEPs MUST NOT fragment VXLAN packets. Intermediate routers may fragment encapsulated VXLAN packets due to the larger frame size. The destination VTEP MAY silently discard such VXLAN fragments. To ensure end-to-end traffic delivery without fragmentation, it is RECOMMENDED that the MTUs (Maximum Transmission Units) across the physical network infrastructure be set to a value that accommodates the larger frame size due to the encapsulation. Other techniques like Path MTU discovery (see [RFC1191] and [RFC1981]) MAY be used to address this requirement as well.
VTEPはVXLANパケットをフラグメント化してはなりません（MUST NOT）。中間ルーターは、フレームサイズが大きいため、カプセル化されたVXLANパケットをフラグメント化することがあります。宛先VTEPは、そのようなVXLANフラグメントを警告なく破棄する場合があります。断片化のないエンドツーエンドのトラフィック配信を保証するには、物理ネットワークインフラストラクチャ全体のMTU（最大転送単位）を、カプセル化によるより大きなフレームサイズに対応する値に設定することをお勧めします。パスMTUディスカバリー（[RFC1191]および[RFC1981]を参照）などの他の手法を使用して、この要件に対処することもできます（MAY）。
The VXLAN frame format is shown below. Parsing this from the bottom of the frame -- above the outer Frame Check Sequence (FCS), there is an inner MAC frame with its own Ethernet header with source, destination MAC addresses along with the Ethernet type, plus an optional VLAN. See Section 6 for further details of inner VLAN tag handling.
VXLANフレーム形式を以下に示します。フレームの下部からこれを解析すると、外側のフレームチェックシーケンス（FCS）の上に、イーサネットタイプとともに送信元、宛先MACアドレス、およびオプションのVLANを備えた独自のイーサネットヘッダーを持つ内部MACフレームがあります。内部VLANタグの処理の詳細については、セクション6を参照してください。
The inner MAC frame is encapsulated with the following four headers (starting from the innermost header):
内部MACフレームは、次の4つのヘッダー（最も内側のヘッダーから開始）でカプセル化されます。
VXLAN Header: This is an 8-byte field that has:
VXLANヘッダー：これは8バイトのフィールドです。
- Flags (8 bits): where the I flag MUST be set to 1 for a valid VXLAN Network ID (VNI). The other 7 bits (designated "R") are reserved fields and MUST be set to zero on transmission and ignored on receipt.
- フラグ（8ビット）：有効なVXLANネットワークID（VNI）の場合、Iフラグを1に設定する必要があります。他の7ビット（「R」と指定）は予約フィールドであり、送信時にゼロに設定し、受信時に無視する必要があります。
- VXLAN Segment ID/VXLAN Network Identifier (VNI): this is a 24-bit value used to designate the individual VXLAN overlay network on which the communicating VMs are situated. VMs in different VXLAN overlay networks cannot communicate with each other.
- VXLANセグメントID / VXLANネットワーク識別子（VNI）：これは、通信するVMが配置されている個々のVXLANオーバーレイネットワークを指定するために使用される24ビットの値です。異なるVXLANオーバーレイネットワーク内のVMは相互に通信できません。
- Reserved fields (24 bits and 8 bits): MUST be set to zero on transmission and ignored on receipt.
- 予約フィールド（24ビットおよび8ビット）：送信時にゼロに設定し、受信時に無視する必要があります。
Outer UDP Header: This is the outer UDP header with a source port provided by the VTEP and the destination port being a well-known UDP port.
外部UDPヘッダー：これは、VTEPによって提供される送信元ポートと既知のUDPポートである宛先ポートを持つ外部UDPヘッダーです。
- Destination Port: IANA has assigned the value 4789 for the VXLAN UDP port, and this value SHOULD be used by default as the destination UDP port. Some early implementations of VXLAN have used other values for the destination port. To enable interoperability with these implementations, the destination port SHOULD be configurable.
- 宛先ポート：IANAはVXLAN UDPポートに値4789を割り当てており、この値はデフォルトで宛先UDPポートとして使用されるべきです（SHOULD）。 VXLANの初期の実装には、宛先ポートに他の値を使用しているものがあります。これらの実装との相互運用性を有効にするには、宛先ポートを構成可能にする必要があります（SHOULD）。
- Source Port: It is recommended that the UDP source port number be calculated using a hash of fields from the inner packet -- one example being a hash of the inner Ethernet frame's headers. This is to enable a level of entropy for the ECMP/load-balancing of the VM-to-VM traffic across the VXLAN overlay. When calculating the UDP source port number in this manner, it is RECOMMENDED that the value be in the dynamic/private port range 49152-65535 [RFC6335].
- 送信元ポート：UDP送信元ポート番号は、内部パケットのフィールドのハッシュを使用して計算することをお勧めします。1つの例は、内部イーサネットフレームのヘッダーのハッシュです。これは、VXLANオーバーレイ全体でのVM-to-VMトラフィックのECMP /ロードバランシングのエントロピーレベルを有効にするためです。この方法でUDPソースポート番号を計算する場合、値がダイナミック/プライベートポートの範囲49152〜65535 [RFC6335]内にあることが推奨されます。
- UDP Checksum: It SHOULD be transmitted as zero. When a packet is received with a UDP checksum of zero, it MUST be accepted for decapsulation. Optionally, if the encapsulating end point includes a non-zero UDP checksum, it MUST be correctly calculated across the entire packet including the IP header, UDP header, VXLAN header, and encapsulated MAC frame. When a decapsulating end point receives a packet with a non-zero checksum, it MAY choose to verify the checksum value. If it chooses to perform such verification, and the verification fails, the packet MUST be dropped. If the decapsulating destination chooses not to perform the verification, or performs it successfully, the packet MUST be accepted for decapsulation.
- UDPチェックサム：0として送信する必要があります。 UDPチェックサムがゼロのパケットを受信した場合、カプセル化解除を受け入れる必要があります。オプションで、カプセル化エンドポイントにゼロ以外のUDPチェックサムが含まれている場合、IPヘッダー、UDPヘッダー、VXLANヘッダー、およびカプセル化されたMACフレームを含むパケット全体で正しく計算される必要があります。カプセル化を解除するエンドポイントは、ゼロ以外のチェックサムを持つパケットを受信すると、チェックサム値を確認することを選択できます。そのような検証を実行することを選択し、検証が失敗した場合、パケットはドロップされなければなりません（MUST）。カプセル化解除の宛先が検証を実行しないことを選択した場合、または検証を正常に実行した場合、パケットはカプセル化解除のために受け入れられなければなりません（MUST）。
Outer IP Header: This is the outer IP header with the source IP address indicating the IP address of the VTEP over which the communicating VM (as represented by the inner source MAC address) is running. The destination IP address can be a unicast or multicast IP address (see Sections 4.1 and 4.2). When it is a unicast IP address, it represents the IP address of the VTEP connecting the communicating VM as represented by the inner destination MAC address. For multicast destination IP addresses, please refer to the scenarios detailed in Section 4.2.
外部IPヘッダー：これは、通信元のVM（内部ソースMACアドレスで表される）が実行されているVTEPのIPアドレスを示すソースIPアドレスを持つ外部IPヘッダーです。宛先IPアドレスは、ユニキャストまたはマルチキャストIPアドレスにすることができます（セクション4.1および4.2を参照）。ユニキャストIPアドレスの場合は、通信するVMに接続するVTEPのIPアドレスを表し、内部宛先MACアドレスで表されます。マルチキャスト宛先IPアドレスについては、セクション4.2で詳述されているシナリオを参照してください。
Outer Ethernet Header (example): Figure 1 is an example of an inner Ethernet frame encapsulated within an outer Ethernet + IP + UDP + VXLAN header. The outer destination MAC address in this frame may be the address of the target VTEP or of an intermediate Layer 3 router. The outer VLAN tag is optional. If present, it may be used for delineating VXLAN traffic on the LAN.
外部イーサネットヘッダー（例）：図1は、外部イーサネット+ IP + UDP + VXLANヘッダー内にカプセル化された内部イーサネットフレームの例です。このフレームの外部宛先MACアドレスは、ターゲットVTEPまたは中間レイヤ3ルーターのアドレスです。外部VLANタグはオプションです。存在する場合は、LAN上のVXLANトラフィックの輪郭を描くために使用できます。
0 1 2 3 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
０ １ ２ ３ ０ １ ２ ３ ４ ５ ６ ７ ８ ９ ０ １ ２ ３ ４ ５ ６ ７ ８ ９ ０ １ ２ ３ ４ ５ ６ ７ ８ ９ ０ １
Outer Ethernet Header:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Outer Destination MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Outer Destination MAC Address | Outer Source MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Outer Source MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|OptnlEthtype = C-Tag 802.1Q | Outer.VLAN Tag Information |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ethertype = 0x0800 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Outer IPv4 Header:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| IHL |Type of Service| Total Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identification |Flags| Fragment Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time to Live |Protocl=17(UDP)| Header Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Outer Source IPv4 Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Outer Destination IPv4 Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Outer UDP Header:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port | Dest Port = VXLAN Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| UDP Length | UDP Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
VXLAN Header:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R|R|R|R|I|R|R|R| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VXLAN Network Identifier (VNI) | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Inner Ethernet Header:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Inner Destination MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Inner Destination MAC Address | Inner Source MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Inner Source MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|OptnlEthtype = C-Tag 802.1Q | Inner.VLAN Tag Information |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Payload:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ethertype of Original Payload | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Original Ethernet Payload |
| |
|(Note that the original Ethernet Frame's FCS is not included) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Frame Check Sequence:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| New FCS (Frame Check Sequence) for Outer Ethernet Frame |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: VXLAN Frame Format with IPv4 Outer Header
図1：IPv4外部ヘッダーを含むVXLANフレーム形式
The frame format above shows tunneling of Ethernet frames using IPv4 for transport. Use of VXLAN with IPv6 transport is detailed below.
上記のフレーム形式は、IPv4を使用して転送するイーサネットフレームのトンネリングを示しています。 IPv6トランスポートでのVXLANの使用について、以下で詳しく説明します。
0 1 2 3 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
０ １ ２ ３ ０ １ ２ ３ ４ ５ ６ ７ ８ ９ ０ １ ２ ３ ４ ５ ６ ７ ８ ９ ０ １ ２ ３ ４ ５ ６ ７ ８ ９ ０ １
Outer Ethernet Header:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Outer Destination MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Outer Destination MAC Address | Outer Source MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Outer Source MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|OptnlEthtype = C-Tag 802.1Q | Outer.VLAN Tag Information |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ethertype = 0x86DD |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Outer IPv6 Header:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| Traffic Class | Flow Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload Length | NxtHdr=17(UDP)| Hop Limit |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Outer Source IPv6 Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Outer Destination IPv6 Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Outer UDP Header:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port | Dest Port = VXLAN Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| UDP Length | UDP Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
VXLAN Header:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R|R|R|R|I|R|R|R| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VXLAN Network Identifier (VNI) | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Inner Ethernet Header:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Inner Destination MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Inner Destination MAC Address | Inner Source MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Inner Source MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|OptnlEthtype = C-Tag 802.1Q | Inner.VLAN Tag Information |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Payload:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ethertype of Original Payload | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Original Ethernet Payload |
| |
|(Note that the original Ethernet Frame's FCS is not included) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Frame Check Sequence:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| New FCS (Frame Check Sequence) for Outer Ethernet Frame |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: VXLAN Frame Format with IPv6 Outer Header
図2：IPv6外部ヘッダーを含むVXLANフレーム形式
VXLAN is typically deployed in data centers on virtualized hosts, which may be spread across multiple racks. The individual racks may be parts of a different Layer 3 network or they could be in a single Layer 2 network. The VXLAN segments/overlay networks are overlaid on top of these Layer 2 or Layer 3 networks.
VXLANは通常、仮想化されたホスト上のデータセンターに展開され、複数のラックに分散する場合があります。個々のラックは、異なるレイヤー3ネットワークの一部である場合と、単一のレイヤー2ネットワーク内にある場合があります。 VXLANセグメント/オーバーレイネットワークは、これらのレイヤー2またはレイヤー3ネットワークの上にオーバーレイされます。
Consider Figure 3, which depicts two virtualized servers attached to a Layer 3 infrastructure. The servers could be on the same rack, on different racks, or potentially across data centers within the same administrative domain. There are four VXLAN overlay networks identified by the VNIs 22, 34, 74, and 98. Consider the case of VM1-1 in Server 1 and VM2-4 on Server 2, which are on the same VXLAN overlay network identified by VNI 22. The VMs do not know about the overlay networks and transport method since the encapsulation and decapsulation happen transparently at the VTEPs on Servers 1 and 2. The other overlay networks and the corresponding VMs are VM1-2 on Server 1 and VM2-1 on Server 2, both on VNI 34; VM1-3 on Server 1 and VM2-2 on Server 2 on VNI 74; and finally VM1-4 on Server 1 and VM2-3 on Server 2 on VNI 98.
レイヤー3インフラストラクチャに接続された2つの仮想化サーバーを示す図3を検討してください。サーバーは、同じラック、異なるラック、または同じ管理ドメイン内のデータセンター全体に配置できます。 VNI 22、34、74、および98によって識別される4つのVXLANオーバーレイネットワークがあります。VNI22によって識別される同じVXLANオーバーレイネットワーク上にある、サーバー1のVM1-1およびサーバー2のVM2-4の場合を考えてください。カプセル化とカプセル解放はサーバー1と2のVTEPで透過的に行われるため、VMはオーバーレイネットワークとトランスポート方式を認識しません。他のオーバーレイネットワークと対応するVMは、サーバー1のVM1-2とサーバー2のVM2-1です。 、VNI 34の両方で; VNI 74上のサーバー1上のVM1-3およびサーバー2上のVM2-2。最後に、サーバー1のVM1-4およびVNI 98のサーバー2のVM2-3。
+------------+-------------+
| Server 1 |
| +----+----+ +----+----+ |
| |VM1-1 | |VM1-2 | |
| |VNI 22 | |VNI 34 | |
| | | | | |
| +---------+ +---------+ |
| |
| +----+----+ +----+----+ |
| |VM1-3 | |VM1-4 | |
| |VNI 74 | |VNI 98 | |
| | | | | |
| +---------+ +---------+ |
| Hypervisor VTEP (IP1) |
+--------------------------+
|
|
|
| +-------------+
| | Layer 3 |
|---| Network |
| |
+-------------+
|
|
+-----------+
|
|
+------------+-------------+
| Server 2 |
| +----+----+ +----+----+ |
| |VM2-1 | |VM2-2 | |
| |VNI 34 | |VNI 74 | |
| | | | | |
| +---------+ +---------+ |
| |
| +----+----+ +----+----+ |
| |VM2-3 | |VM2-4 | |
| |VNI 98 | |VNI 22 | |
| | | | | |
| +---------+ +---------+ |
| Hypervisor VTEP (IP2) |
+--------------------------+
Figure 3: VXLAN Deployment - VTEPs across a Layer 3 Network
図3：VXLANの導入-レイヤー3ネットワーク全体のVTEP
One deployment scenario is where the tunnel termination point is a physical server that understands VXLAN. An alternate scenario is where nodes on a VXLAN overlay network need to communicate with nodes on legacy networks that could be VLAN based. These nodes may be physical nodes or virtual machines. To enable this communication, a network can include VXLAN gateways (see Figure 4 below with a switch acting as a VXLAN gateway) that forward traffic between VXLAN and non-VXLAN environments.
導入シナリオの1つは、トンネル終端ポイントがVXLANを理解する物理サーバーである場合です。別のシナリオは、VXLANオーバーレイネットワーク上のノードが、VLANベースのレガシーネットワーク上のノードと通信する必要がある場合です。これらのノードは、物理ノードまたは仮想マシンです。この通信を可能にするために、ネットワークには、VXLANと非VXLAN環境の間でトラフィックを転送するVXLANゲートウェイ（スイッチがVXLANゲートウェイとして機能する下の図4を参照）を含めることができます。
Consider Figure 4 for the following discussion. For incoming frames on the VXLAN connected interface, the gateway strips out the VXLAN header and forwards it to a physical port based on the destination MAC address of the inner Ethernet frame. Decapsulated frames with the inner VLAN ID SHOULD be discarded unless configured explicitly to be passed on to the non-VXLAN interface. In the reverse direction, incoming frames for the non-VXLAN interfaces are mapped to a specific VXLAN overlay network based on the VLAN ID in the frame. Unless configured explicitly to be passed on in the encapsulated VXLAN frame, this VLAN ID is removed before the frame is encapsulated for VXLAN.
以下の説明では、図4を検討してください。 VXLAN接続インターフェースの着信フレームの場合、ゲートウェイはVXLANヘッダーを取り除き、内部イーサネットフレームの宛先MACアドレスに基づいて物理ポートに転送します。内部VLAN IDを持つカプセル化解除されたフレームは、非VXLANインターフェイスに渡されるように明示的に構成されていない限り、破棄する必要があります（SHOULD）。逆方向では、非VXLANインターフェイスの着信フレームは、フレーム内のVLAN IDに基づいて特定のVXLANオーバーレイネットワークにマッピングされます。カプセル化されたVXLANフレームで渡されるように明示的に構成されていない限り、このVLAN IDは、フレームがVXLAN用にカプセル化される前に削除されます。
These gateways that provide VXLAN tunnel termination functions could be ToR/access switches or switches higher up in the data center network topology -- e.g., core or even WAN edge devices. The last case (WAN edge) could involve a Provider Edge (PE) router that terminates VXLAN tunnels in a hybrid cloud environment. In all these instances, note that the gateway functionality could be implemented in software or hardware.
VXLANトンネル終端機能を提供するこれらのゲートウェイは、ToR /アクセススイッチや、データセンターネットワークトポロジの上位にあるスイッチ（コア、WANエッジデバイスなど）である可能性があります。最後のケース（WANエッジ）には、ハイブリッドクラウド環境でVXLANトンネルを終端するプロバイダーエッジ（PE）ルーターが含まれる場合があります。これらすべての場合において、ゲートウェイ機能はソフトウェアまたはハードウェアに実装できることに注意してください。
+---+-----+---+ +---+-----+---+
| Server 1 | | Non-VXLAN |
(VXLAN enabled)<-----+ +---->| server |
+-------------+ | | +-------------+
| |
+---+-----+---+ | | +---+-----+---+
|Server 2 | | | | Non-VXLAN |
(VXLAN enabled)<-----+ +---+-----+---+ +---->| server |
+-------------+ | |Switch acting| | +-------------+
|---| as VXLAN |-----|
+---+-----+---+ | | Gateway |
| Server 3 | | +-------------+
(VXLAN enabled)<-----+
+-------------+ |
|
+---+-----+---+ |
| Server 4 | |
(VXLAN enabled)<-----+
+-------------+
Figure 4: VXLAN Deployment - VXLAN Gateway
図4：VXLANの導入-VXLANゲートウェイ
Inner VLAN Tag Handling in VTEP and VXLAN gateway should conform to the following:
VTEPおよびVXLANゲートウェイでの内部VLANタグの処理は、以下に準拠する必要があります。
Decapsulated VXLAN frames with the inner VLAN tag SHOULD be discarded unless configured otherwise. On the encapsulation side, a VTEP SHOULD NOT include an inner VLAN tag on tunnel packets unless configured otherwise. When a VLAN-tagged packet is a candidate for VXLAN tunneling, the encapsulating VTEP SHOULD strip the VLAN tag unless configured otherwise.
内部VLANタグを持つカプセル化解除されたVXLANフレームは、特に構成されていない限り破棄する必要があります。カプセル化側では、VTEPは、特に構成されていない限り、トンネルパケットに内部VLANタグを含めるべきではありません（SHOULD NOT）。 VLANタグ付きパケットがVXLANトンネリングの候補である場合、特に構成されていない限り、カプセル化VTEPはVLANタグを削除する必要があります（SHOULD）。
Traditionally, Layer 2 networks can only be attacked from 'within' by rogue end points -- either by having inappropriate access to a LAN and snooping on traffic, by injecting spoofed packets to 'take over' another MAC address, or by flooding and causing denial of service. A MAC-over-IP mechanism for delivering Layer 2 traffic significantly extends this attack surface. This can happen by rogues injecting themselves into the network by subscribing to one or more multicast groups that carry broadcast traffic for VXLAN segments and also by sourcing MAC-over-UDP frames into the transport network to inject spurious traffic, possibly to hijack MAC addresses.
従来、レイヤー2ネットワークへの攻撃は、不正なエンドポイントの「内部」からのみ可能です-LANへの不適切なアクセスとトラフィックのスヌーピング、スプーフィングされたパケットを挿入して別のMACアドレスを「引き継ぐ」、またはフラッディングとサービス拒否。レイヤー2トラフィックを配信するためのMAC-over-IPメカニズムは、この攻撃対象を大幅に拡大します。これは、VXLANセグメントのブロードキャストトラフィックを伝送する1つ以上のマルチキャストグループにサブスクライブして不正ネットワークが自身をネットワークに注入したり、MAC-over-UDPフレームをトランスポートネットワークに送信してスプリアストラフィックを注入したり、MACアドレスをハイジャックしたりすることによって発生する可能性があります。
This document does not incorporate specific measures against such attacks, relying instead on other traditional mechanisms layered on top of IP. This section, instead, sketches out some possible approaches to security in the VXLAN environment.
このドキュメントでは、そのような攻撃に対する特定の対策を組み込んでおらず、代わりにIPの上に階層化された他の従来のメカニズムに依存しています。代わりに、このセクションでは、VXLAN環境でのセキュリティに対するいくつかの可能なアプローチを概説します。
Traditional Layer 2 attacks by rogue end points can be mitigated by limiting the management and administrative scope of who deploys and manages VMs/gateways in a VXLAN environment. In addition, such administrative measures may be augmented by schemes like 802.1X [802.1X] for admission control of individual end points. Also, the use of the UDP-based encapsulation of VXLAN enables configuration and use of the 5-tuple-based ACL (Access Control List) functionality in physical switches.
不正なエンドポイントによる従来のレイヤ2攻撃は、VXLAN環境でVM /ゲートウェイを展開および管理する人の管理および管理範囲を制限することで軽減できます。さらに、このような管理手段は、個々のエンドポイントのアドミッションコントロールのために、802.1X [802.1X]のようなスキームによって補強される場合があります。また、VXLANのUDPベースのカプセル化を使用すると、物理スイッチで5タプルベースのACL（アクセス制御リスト）機能を構成して使用できます。
Tunneled traffic over the IP network can be secured with traditional security mechanisms like IPsec that authenticate and optionally encrypt VXLAN traffic. This will, of course, need to be coupled with an authentication infrastructure for authorized end points to obtain and distribute credentials.
IPネットワーク上のトンネルトラフィックは、VXLANトラフィックを認証し、オプションで暗号化するIPsecなどの従来のセキュリティメカニズムで保護できます。もちろん、これは、資格情報を取得して配布するために、承認されたエンドポイントの認証インフラストラクチャと組み合わせる必要があります。
VXLAN overlay networks are designated and operated over the existing LAN infrastructure. To ensure that VXLAN end points and their VTEPs are authorized on the LAN, it is recommended that a VLAN be designated for VXLAN traffic and the servers/VTEPs send VXLAN traffic over this VLAN to provide a measure of security.
VXLANオーバーレイネットワークは、既存のLANインフラストラクチャ上で指定および運用されます。 VXLANエンドポイントとそのVTEPがLAN上で承認されるようにするには、VXLANトラフィック用にVLANを指定し、サーバー/ VTEPがこのVLAN経由でVXLANトラフィックを送信してセキュリティ対策を講じることをお勧めします。
In addition, VXLAN requires proper mapping of VNIs and VM membership in these overlay networks. It is expected that this mapping be done and communicated to the management entity on the VTEP and the gateways using existing secure methods.
さらに、VXLANでは、これらのオーバーレイネットワークでVNIとVMメンバーシップを適切にマッピングする必要があります。このマッピングが行われ、既存の安全な方法を使用して、VTEPの管理エンティティとゲートウェイに通信されることが期待されます。
A well-known UDP port (4789) has been assigned by the IANA in the Service Name and Transport Protocol Port Number Registry for VXLAN. See Section 5 for discussion of the port number.
よく知られているUDPポート（4789）は、IANAによってVXLANのサービス名とトランスポートプロトコルのポート番号レジストリで割り当てられています。ポート番号については、セクション5を参照してください。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。
[802.1aq] IEEE, "Standard for Local and metropolitan area networks -- Media Access Control (MAC) Bridges and Virtual Bridged Local Area Networks -- Amendment 20: Shortest Path Bridging", IEEE P802.1aq-2012, 2012.
[802.1aq] IEEE、「Local and Metropolitan Area Networks-Media Access Control（MAC）Bridges and Virtual Bridged Local Area Networks-Amendment 20：Shortest Path Bridging」、IEEE P802.1aq-2012、2012。
[802.1D] IEEE, "Draft Standard for Local and Metropolitan Area Networks/ Media Access Control (MAC) Bridges", IEEE P802.1D-2004, 2004.
[802.1D] IEEE、「ローカルおよびメトロポリタンエリアネットワーク/メディアアクセスコントロール（MAC）ブリッジのドラフト標準」、IEEE P802.1D-2004、2004。
[802.1X] IEEE, "IEEE Standard for Local and metropolitan area networks -- Port-Based Network Acces Control", IEEE Std 802.1X-2010, February 2010.
[802.1X] IEEE、「IEEE Standard for Local and Metropolitan Area Networks-Port-Based Network Acces Control」、IEEE Std 802.1X-2010、February 2010。
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, November 1990.
[RFC1191] Mogul、J。およびS. Deering、「Path MTU discovery」、RFC 1191、1990年11月。
[RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery for IP version 6", RFC 1981, August 1996.
[RFC1981] McCann、J.、Deering、S。、およびJ. Mogul、「Path MTU Discovery for IP version 6」、RFC 1981、1996年8月。
[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月。
[RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", RFC 4601, August 2006.
[RFC4601] Fenner、B.、Handley、M.、Holbrook、H。、およびI. Kouvelas、「Protocol Independent Multicast-Sparse Mode（PIM-SM）：Protocol Specification（Revised）」、RFC 4601、2006年8月。
[RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, "Bidirectional Protocol Independent Multicast (BIDIR-PIM)", RFC 5015, October 2007.
[RFC5015] Handley、M.、Kouvelas、I.、Speakman、T。、およびL. Vicisano、「Bidirectional Protocol Independent Multicast（BIDIR-PIM）」、RFC 5015、2007年10月。
[RFC6325] Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A. Ghanwani, "Routing Bridges (RBridges): Base Protocol Specification", RFC 6325, July 2011.
[RFC6325] Perlman、R.、Eastlake 3rd、D.、Dutt、D.、Gai、S。、およびA. Ghanwani、「Routing Bridges（RBridges）：Base Protocol Specification」、RFC 6325、2011年7月。
[RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. Cheshire, "Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry", BCP 165, RFC 6335, August 2011.
[RFC6335]綿、M。、エガート、L。、タッチ、J。、ウェスターランド、M。、およびS.チェシャー、「サービス名とトランスポートプロトコルのポート番号レジストリの管理のためのInternet Assigned Numbers Authority（IANA）手順"、BCP 165、RFC 6335、2011年8月。
The authors wish to thank: Ajit Sanzgiri for contributions to the Security Considerations section and editorial inputs; Joseph Cheng, Margaret Petrus, Milin Desai, Nial de Barra, Jeff Mandin, and Siva Kollipara for their editorial reviews, inputs, and comments.
著者は以下のことに感謝したいと思います。Ajit Sanzgiriは、セキュリティに関する考慮事項セクションへの貢献と編集上の入力に感謝します。編集レビュー、入力、コメントを寄せられたJoseph Cheng、Margaret Petrus、Milin Desai、Nial de Barra、Jeff Mandin、Siva Kollipara。
Authors' Addresses
著者のアドレス
Mallik Mahalingam Storvisor, Inc. 640 W. California Ave, Suite #110 Sunnyvale, CA 94086. USA
マリックマハリンガムストアバイザー、紀元前640年California Ave、Suite＃110 Sunnyvale、CA94086。彼女
EMail: mallik_mahalingam@yahoo.com
Dinesh G. Dutt Cumulus Networks 140C S. Whisman Road Mountain View, CA 94041 USA
Dinesh G. Dutt Cumulus Networks 140C S. Whisman Road Mountain View、CA 94041 USA
EMail: ddutt.ietf@hobbesdutt.com
Kenneth Duda Arista Networks 5453 Great America Parkway Santa Clara, CA 95054 USA
Kenneth Duda Arista Networks 5453 Great America Parkway Santa Clara、CA 95054 USA
EMail: kduda@arista.com
Puneet Agarwal Broadcom Corporation 3151 Zanker Road San Jose, CA 95134 USA
Puneet Agarwal Broadcom Corporation 3151 Zanker Road San Jose、CA 95134 USA
EMail: pagarwal@broadcom.com Lawrence Kreeger Cisco Systems, Inc. 170 W. Tasman Avenue San Jose, CA 95134 USA
Eメール：pagarwal@broadcom.com Lawrence Kreeger Cisco Systems、Inc. 170 W. Tasman Avenue San Jose、CA 95134 USA
EMail: kreeger@cisco.com
T. Sridhar VMware, Inc. 3401 Hillview Palo Alto, CA 94304 USA
T. Sridhar VMware、Inc. 3401 Hillview Palo Alto、CA 94304 USA
EMail: tsridhar@vmware.com
Mike Bursell Intel Bowyer's, North Road Great Yeldham Halstead Essex. C09 4QD UK
Mike Bursell Intel Bowyer's、North Road Great Yeldham Halstead Essex。 C09 4QD UK
EMail: mike.bursell@intel.com
Chris Wright Red Hat, Inc. 100 East Davie Street Raleigh, NC 27601 USA
Chris Wright Red Hat、Inc. 100 East Davie Street Raleigh、NC 27601 USA
EMail: chrisw@redhat.com