RFC 7348: 仮想拡張LAN(VXLAN): レイヤ3ネットワーク上に仮想化レイヤ2ネットワークをオーバーレイするためのフレームワーク

要旨

本文書は、複数のテナントを収容する仮想化データセンター内のオーバーレイ・ネットワークのニーズに対応するために使われる仮想拡張ローカル・エリア・ネットワーク(VXLAN)を説明する。この方式と関連プロトコルは、クラウド・サービス・プロバイダやエンタープライズ・データセンターのネットワークで使用することができる。本文書は、インターネット・コミュニティの利益のために、展開されたVXLANプロトコルを文書化する。

本文書の位置付け

本文書はインターネット標準化過程の仕様書ではない。情報提供を目的として公開する。

本文書はインターネット・エンジニアリング・タスク・フォース(IETF)の成果物である。IETFコミュニティのコンセンサスを表すものである。文書は公開レビューを受けており、インターネット・エンジニアリング・ステアリング・グループ(IESG)によって公開が承認されている。IESGによって承認されたすべての文書が、あらゆるレベルのインターネット標準の候補となるわけではない。RFC 5741のセクション2を参照のこと。

文書の現在の位置付け、正誤表、フィードバックの提供方法に関する情報は、<http://www.rfc-editor.org/info/rfc7938>で入手できる。

著作権表示

Copyright (c) 2014 IETFトラストおよび文書の著者として特定された人物。無断転載を禁じる。

本文書は、BCP 78および文書の発行日において有効なIETF文書に関するIETFトラストの法的規定(<https://trustee.ietf.org/license-info>)に従うものとする。これらの文書には、本文書に関するあなたの権利と制限が記載されているため、注意深く確認して欲しい。

1. はじめに

サーバの仮想化により、物理ネットワーク・インフラストラクチャへの要求が高まっている。物理サーバにはそれぞれ独自のメディア・アクセス制御(MAC)アドレスを持つ複数の仮想マシン(VM)が存在する。数十万のVMが接続され、VM間で通信が行われるため、スイッチイング・イーサネット・ネットワークは大きなMACアドレス・テーブルが必要となる。

データセンター内のVMが仮想LAN(VLAN)ごとにグループ化されている場合、VMが属するグループごとにトラフィックを分割するには、数千のVLANが必要になる。このような状況では、現在のVLAN制限である4094では不十分である。

データセンターでは、それぞれが独立したネットワーク・ドメインを持つ複数のテナントをホストすることが求められる。これを専用のインフラストラクチャで実現するのは経済的ではないため、ネットワーク管理者は共有ネットワーク上での分離を選択する。このようなシナリオでは、各テナントがMACアドレスやVLAN IDを個別に割り当てるため、物理ネットワーク上の重複の可能性という問題が発生する。

レイヤ2の物理インフラストラクチャを使用する仮想化環境にとって重要な要件は、データセンター全体、あるいはデータセンター間も、コンピューティング、ネットワーク、ストレージのリソースを効率的に割り当てるために、レイヤ2ネットワークを拡張できることにある。このようなネットワークでは、ループ・フリーのトポロジーを実現するため、スパニング・ツリー・プロトコル(STP)のような従来の手法を使用すると、多数のリンクが無駄になる可能性がある。

最後のシナリオは、ネットワーク・オペレータが物理インフラストラクチャの相互接続にIPを使用することを好む場合(例えば、イコール・コスト・マルチパス(ECMP)によるマルチパス・スケーラビリティを実現し、リンクの無効化を回避する場合)である。このような環境でも、VM間の通信にレイヤ2モデルを維持する必要がある。

上記のシナリオでは、オーバーレイ・ネットワークが必要になる。このオーバーレイは、個々のVMからのMACトラフィックをカプセル化して、論理的な「トンネル」を介して伝送するために使用される。

本文書では、上記のさまざまな要件に対応するためのカプセル化スキームを提供する「Virtual eXtensible Local Area Network (VXLAN)」と呼ばれるフレームワークについて詳しく説明する。本文書は、インターネット・コミュニティの利益のために、展開されたVXLANプロトコルについて説明する。

1.1.頭字語と定義

ACL: アクセス・コントロール・リスト

ECMP: イコール・コスト・マルチパス

IGMP: インターネット・グループ管理プロトコル

IHL: インターネット・ヘッダ長

MTU: 最大転送単位

PIM: プロトコル・インデンペンデント・マルチキャスト

SPB: 最短パス・ブリッジング

STP: スパニング・ツリー・プロトコル

ToR: トップ・オブ・ラック

TRILL: 多数リンクの透過的な相互接続

VLAN: 仮想ローカル・エリア・ネットワーク

VM: 仮想マシン

VNI: VXLANネットワーク識別子(またはVXLANセグメントID)

VTEP: VXLANトンネル・エンド・ポイント。VXLANトンネルを開始および/または終了するエンティティ

VXLAN: 仮想拡張ローカル・エリア・ネットワーク

VXLANセグメント: VMが通信するVXLANレイヤ2オーバーレイ・ネットワーク

VXLANゲートウェイ: VXLAN間でトラフィックを転送するエンティティ

2. 本文書で使用される表記

キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、「OPTIONAL」は、すべて大文字で表示される場合のみ、RFC 2119 [RFC2119]に記述されているように解釈される。

3. VXLANの問題ステートメント

このセクションでは、VXLANが対処しようとしている領域についてさらに詳しく説明する。ここでは、データセンター内のネットワーク・インフラストラクチャと関連する問題を焦点が当てる。

3.1. スパニング・ツリーとVLAN範囲が課す制限

現在のレイヤ2ネットワークでは、重複パスによるネットワークのループを回避するため、IEEE 802.1Dスパニング・ツリー・プロトコル(STP)[802.1D]が使用されている。STPは、フレームの複製とループを回避するためにリンクの使用をブロックする。一部のデータセンターのオペレータは、STPによって実際に使用しないポートとリンクの分まで料金を支払う事になるため、これをレイヤ2ネットワーク全般の問題と見なしている。さらに、STPモデルはマルチパスによるレジリエンスは期待できない。TRILL[RFC6325]やSPB[802.1aq]などの新しい方式が提案されており、マルチパスをサポートし、STPの問題の一部を克服することが期待されている。ラック内のサーバを同じレイヤ3ネットワーク上に構成し、ラック内とラック間のスイッチングをレイヤ3で行うことで、STPの制限を回避できる可能性もある。しかし、これはVM間の通信におけるレイヤ2モデルと互換性がない。

レイヤ2データセンター・ネットワークの主な特徴は、ブロードキャストの分離に仮想LAN(VLAN)を使用する点にある。12ビットのVLAN IDがイーサネット・データ・フレームで使用され、大規模なレイヤ2ネットワークを複数のブロードキャスト・ドメインに分割する。これは、必要なVLANの数が4094未満であれば、多くのデータセンターにとって十分な機能だった。仮想化の採用が進むにつれて、この上限は限界に達しつつある。さらに、STPが原因で、いくつかのデータセンターでは使用できるVLANの数が制限される。さらに、セクション3.3で説明するように、マルチテナント環境の要件により、より大きなVLAN上限の必要性が加速している。

3.2. マルチテナント環境

クラウド・コンピューティングでは、マルチテナント環境向けのリソースをオンデマンドで柔軟にプロビジョニングする。クラウド・コンピューティングの最も一般的な例はパブリック・クラウドであり、クラウド・サービス・プロバイダが同じ物理インフラ上で、複数の顧客/テナントにこれらの柔軟なサービスを提供する。

テナントによるネットワーク・トラフィックの分離は、レイヤ2またはレイヤ3ネットワークを介して行う。レイヤ2ネットワークでは、トラフィックを分離するためにVLANがよく使われるため、例えばテナントは独自のVLANで識別できる。クラウド・プロバイダはサービスを提供するテナントの数が多いため、4094という上限は不十分な場合が多い。さらに、テナントごとに複数のVLANが必要になることが多く、これが問題をさらに悪化させている。

関連するユースケースとして、Crossポッド拡張がある。ポッドは通常、関連するネットワークおよびストレージ接続機能を備えた1つ以上のサーバ・ラックで構成される。テナントはポッド上で運用を開始し、拡張により、他のポッドのサーバ/VMが必要になる。特に、他のポッド上のテナントがすべてのリソースを十分に活用していない場合である。このユースケースでは、個々のサーバ/VMを接続する「ストレッチ (stretched)」レイヤ2環境が必要となる。

レイヤ3ネットワークはマルチテナントの包括的なソリューションではない。2つのテナントが、それぞれのネットワーク内で同じレイヤ3アドレスを使用する可能性があるため、クラウド・プロバイダは別の方法で分離を提供しなければならない。さらに、すべてのテナントにIPの使用を求めると、VM間の通信にレイヤ2または非IPレイヤ3プロトコルを直接使用する顧客が排除されてしまう。

3.3. ToRスイッチのテーブル・サイズが不十分

今日の仮想化環境では、サーバに接続するトップ・オブ・ラック(ToR)スイッチのMACアドレス・テーブルにさらに多くの要求が課せられている。ToRは現在、サーバごとに1つのMACアドレスではなく、個々のVMのMACアドレス(サーバごとに数百に及ぶ可能性がある)を学習しなければならない。これは、VMから他の物理ネットワークのトラフィックがサーバとスイッチ間のリンクを通過するためである。一般的なToRスイッチは、サーバに面したポート数に応じて24台または48台のサーバを接続できる。データセンターは複数のラックで構成されているため、各ToRスイッチは、さまざまな物理サーバ間で通信するVMのアドレス・テーブルを維持しなければならない。これにより、仮想化されていない環境と比較して、テーブル容量に対する要求が大幅に高くなる。

テーブルが溢れた場合、スイッチはアイドル・エントリが期限切れになるまで新しいアドレスの学習を停止し、後続の宛先不明のフレームが大量にフラッディングされることになる。

4. VXLAN

VXLAN(Virtual eXtensible Local Area Network)は、マルチテナント環境のVMが存在する場合のレイヤ2およびレイヤ3データ センター・ネットワーク・インフラストラクチャの上記の要件に対応する。これは既存のネットワーク・インフラストラクチャ上で実行され、レイヤ2ネットワークを「拡張」する手段を提供する。つまり、VXLANはレイヤ3ネットワーク上のレイヤ2オーバーレイ方式である。各オーバーレイはVXLANセグメントと呼ばれる。同じVXLANセグメント内のVMだけが相互に通信できる。各VXLANセグメントは、「VXLANネットワーク識別子(VNI)」と呼ばれる24ビットのセグメントIDで識別する。これにより、同じ管理ドメイン内に最大1,600万のVXLANセグメントを共存させることができる。

VNIは、個々のVMが発信した内部MACフレームの範囲を識別する。したがって、セグメント間でMACアドレスが重複することがあっても、VNIによってトラフィックが分離されているため、トラフィックがセグメントを「越える(cross over)」ことはない。VNIは、VMが発信した内部MACフレームをカプセル化する外部ヘッダに含まれる。以降のセクションでは、「VXLANセグメント」という用語は、「VXLANオーバーレイ・ネットワーク」という用語と同義で使用する。

VXLANでは、このカプセル化はレイヤ3ネットワークの上にレイヤ2ネットワークをオーバーレイするトンネリング方式とも呼ばれる。トンネルはステートレスなので、各フレームは一連のルールに従ってカプセル化される。以降のセクションで説明するトンネルのエンド・ポイント(VXLANトンネル・エンド・ポイントまたはVTEP)は、VMをホストするサーバのハイパーバイザー内にある。したがって、VNIおよびVXLAN関連のトンネル/外部ヘッダのカプセル化は、VTEPのみが認識し、VMはそれを認識することはない(図1参照)。VTEPを物理スイッチや物理サーバ上に置き、ソフトウェアまたはハードウェアで実装される可能性があることに留意する。VTEPが物理スイッチであるユースケースについては、セクション6のVXLAN展開シナリオで説明する。

以下のセクションでは、データ・プレーン学習という1つのタイプの制御スキームを使用したVXLAN環境の典型的なトラフィック・フローのシナリオについて説明する。ここでは、VMのMACとVTEPのIPアドレスの関連付けは、送信元アドレス学習によって検出される。マルチキャストは、宛先不明、ブロードキャスト、マルチキャスト・フレームを伝送するために使用される。

学習ベースのコントロール・プレーンに加えて、VTEP IPからVM MACへのマッピング情報を配布するには他の方式も考えられる。オプションには、個々のVTEPによる中央機関/ディレクトリ・ベースの検索、中央機関によるVTEPへのマッピング情報の配布などがある。これらは、それぞれプッシュ・モデルとプル・モデルと呼ばれることがある。本文書では、VXLANのコントロール・プレーンとしてのデータ・プレーン学習スキームに焦点を当てる。

4.1. ユニキャストVM間の通信

VXLANオーバーレイ・ネットワーク内のVMについて考えてみる。このVMはVXLANを認識しない。別のホスト上のVMと通信するために、通常どおりターゲット宛のMACフレームを送信する。物理ホスト上のVTEPは、このVMが関連付けられているVNIを検索する。次に、宛先MACが同じセグメント上にあるかどうか、宛先MACアドレスがリモートVTEPにマッピングされているかどうかを判断する。マッピングされていれば、外部MAC、外部IPヘッダ、VXLANヘッダ(フレームのフォーマットについてはセクション5の図1を参照)で構成される外部ヘッダが元のMACフレームの先頭に追加される。カプセル化されたパケットはリモートVTEPに転送される。リモートVTEPはパケットを受信すると、VNIの有効性と内部の宛先MACアドレスと一致するMACアドレスを使用するVMがそのVNI上に存在するかどうかを検証する。存在すれば、パケットからカプセル化ヘッダを取り除かれ、宛先VMに渡される。宛先VMは、VNIやフレームがVXLANカプセル化で転送されたことを認識することはない。

パケットを宛先VMに転送することに加えて、リモートVTEPは、インナー送信元MACからアウター送信元IPアドレスへのマッピングを学習する。このマッピングはテーブルに保存され、宛先VMが応答パケットを送信する際の応答パケットへの「宛先不明」フラッディングが不要となる。

送信元VMが送信する前に宛先VMのMACアドレスを決定することは、セクション4.2で説明している点を除き、非VXLAN環境と同様に実行される。ブロードキャスト・フレームを使用するが、セクション4.2で説明しているように、マルチキャスト・パケット内にカプセル化される。

4.2. ブロードキャスト通信とマルチキャストへのマッピング

送信元ホスト上のVMが、IPを使用して宛先VMと通信しようとしている場合を考える。両者が同じサブネット上にあると仮定すると、VMはアドレス解決プロトコル(ARP)ブロードキャスト・フレームを送信する。非VXLAN環境では、このフレームはそのVLANを伝送するすべてのスイッチにMACブロードキャストを使用して送信される。

VXLANでは、IPヘッダとUDPヘッダとともに、VXLAN VNIを含むヘッダをパケットの先頭に挿入する。ただし、このブロードキャスト・パケットは、そのVXLANオーバーレイ・ネットワークを実現するIPマルチキャスト・グループに送信される。

これを実現するには、VXLAN VNIとそれが使用するIPマルチキャスト・グループとの間のマッピングが必要となる。このマッピングはマネジメント層で行われ、管理チャネルを通じて個々のVTEPに提供される。このマッピングを使用して、VTEPは上流のスイッチ/ルータにIGMPメンバーシップ・レポートを送出して、必要に応じてVXLAN関連のIPマルチキャスト・グループに参加/離脱することができる。これにより、特定のマルチキャスト・アドレスを使用するこのホストでメンバーが利用可能かどうかに基づいて、特定のマルチキャスト・トラフィック・アドレスのリーフ・ノードのプルーニングが可能になる([RFC4541]を参照)。さらに、プロトコル・インデペンデント・マルチキャストのスパース・モード(PIM-SM [RFC4601]を参照)のようなマルチキャスト・ルーティング・プロトコルを使用することで、レイヤ3ネットワーク内で効率的なマルチキャスト・ツリーを提供することができる。

VTEPは(*,G)joinを使用する。これは、VXLANトンネルの送信元が不明で、VMが異なるホスト間で起動/停止するため、頻繁に変更される可能性があるため必要である。ここでの補足として、各VTEPはマルチキャスト・パケットの送信元と宛先の両方として動作するため、双方向PIM (BIDIR-PIM -- [RFC5015]を参照)のようなプロトコルの方が効率的である。

宛先VMは、IPユニキャストを使用して標準ARP応答を送信する。このフレームは、IPユニキャストのVXLANカプセル化を使用して、発信元VMを接続するVTEPにカプセル化して返す。これは、ARP応答の宛先MACとVXLANトンネルのエンドポイントIPのマッピングが、ARP要求を通じて事前に学習しているため可能である。

マルチキャスト・フレームと「宛先不明MAC」フレームも、ブロードキャスト・フレームと同様に、マルチキャスト・ツリーを使用して送信されることに留意する。

4.3. 物理インフラの要件

IPマルチキャストがネットワーク・インフラストラクチャ内で使用されている場合、PIM-SMのようなマルチキャスト・ルーティング・プロトコルをネットワーク内の個々のレイヤ3IPルータ/スイッチで使用することができる。これは、効率的なマルチキャスト・フォワーディング・ツリーを構築するために使用され、マルチキャスト・フレームは、受信を要求したホストにのみ送信される。

同様に、送信元VMと宛先VMを接続する実際のネットワークがレイヤ3ネットワークである必要はない。VXLANはレイヤ2ネットワークでも動作する。どちらの場合でも、IGMPスヌーピングを使用して、レイヤ2ネットワーク内で効率的なマルチキャスト・レプリケーションを実現できる。

VTEPは、VXLANパケットをフラグメント化してはならない(MUST NOT)。中間ルータはフレーム・サイズが大きいため、カプセル化されたVXLANパケットをフラグメント化する場合がある。宛先VTEPは、このようなVXLANフラグメントを黙って破棄してもよい(MAY)。フラグメント化なしでエンド・ツー・エンドのトラフィック配信を確実に行うには、物理ネットワーク・インフラ全体のMTU(最大伝送単位)を、カプセル化によるフレーム・サイズの増加に対応する値に設定することが推奨される(RECOMMENDED)。パスMTU検出([RFC1191]および [RFC1981]を参照)のような他の手法を、この要件に対応するために使用してもよい(MAY)。

5. VXLANフレームのフォーマット

VXLANフレームのフォーマットを以下に示す。フレームの下(外側のフレーム・チェック・シーケンス(FCS)の上)から解析すると、インナーMACフレームには、それ自身のイーサネット・ヘッダがあり、送信元と宛先のMAC アドレス、イーサネット・タイプ、さらにオプションでVLANがある。インナーVLANタグの処理の詳細については、セクション6を参照のこと。

インナーMACフレームは、以下の4つのヘッダでカプセル化される(最も内側のヘッダから):

VXLANヘッダ: これは8バイトのフィールドで、次の内容が含まれる。

• フラグ(8ビット): 有効なVXLANネットワークID(VNI)の場合、Iフラグを1に設定しなければならない(MUST)。他の7ビット (「R」と指定)は予約フィールドで、送信時にゼロに設定され、受信時に無視しなければならない。

• VXLANセグメントID/VXLANネットワーク識別子(VNI): 通信するVMが配置されている個々のVXLANオーバーレイ・ネットワークを指定するために使用される24ビットの値である。異なるVXLANオーバーレイ・ネットワーク上のVMは相互に通信できない。

• 予約フィールド(24ビットと8ビット): 送信時にゼロに設定し、受信時に無視しなければならない(MUST)。

アウターUDPヘッダ: これは、VTEPによって提供される送信元ポートと、既知のUDPポートを宛先ポートに持つアウターUDPヘッダである。

• 宛先ポート: IANAはVXLANのUDPポートに値4789を割り当てており、デフォルトではこの値を宛先UDPポートとして使用する必要がある(SHOULD)。VXLANの初期の実装では、宛先ポートに他の値を使用していたものもある。これらの実装との相互運用性を実現するには、宛先ポートを設定可能にする必要がある(SHOULD)。

• 送信元ポート: UDP送信元ポート番号は、内部パケットのフィールドのハッシュを使用して計算することが推奨される。例えば、インナー・イーサネット・フレームのヘッダのハッシュである。これは、VXLANオーバーレイを介したVM間トラフィックのECMP/負荷分散のためのエントロピー・レベルを有効にするためである。この方法でUDP送信元ポート番号を計算する場合、値は動的/プライベート・ポート範囲 49152-65535 [RFC6335]にすることが推奨される。

• UDPチェックサム: ゼロとして送信する必要がある(SHOULD)。UDPチェックサムがゼロのパケットを受信した場合、そのパケットはカプセル化解除のために受け入れられなければならない(MUST)。オプションで、カプセル化エンドポイントがゼロ以外のUDPチェックサムを含む場合、IPヘッダ、UDPヘッダ、VXLANヘッダ、カプセル化されたMACフレームを含むパケット全体で正しく計算しなければならない(MUST)。カプセル化解除エンドポイントがゼロ以外のチェックサムを持つパケットを受信した場合、そのチェックサム値を検証することが選択できる(MAY)。そのような検証を行うことを選択し、検証に失敗した場合、パケットは破棄しなければならない(MUST)。カプセル化解除の宛先が検証を実行しないことを選択した場合、または検証が正常に実行された場合、パケットはカプセル化解除のために受け入れなければならない(MUST)。

アウターIPヘッダ: これはアウターIPヘッダで、送信元IPアドレスは、通信するVM(インナー宛先MACアドレスで表される)が実行されているVTEPのIPアドレスを示す。宛先IPアドレスは、ユニキャストまたはマルチキャストIPアドレスである(セクション4.1および4.2を参照)。ユニキャストIPアドレスの場合、インナー宛先MACアドレスで表される通信VMを接続するVTEPのIPアドレスを表す。マルチキャスト宛先IPアドレスについては、セクション4.2で詳細に説明したシナリオを参照のこと。

アウター・イーサネット・ヘッダ(例): 図1は、アウター・イーサネット + IP + UDP + VXLANヘッダでカプセル化されたインナー・イーサネット・フレームの例である。このフレームのアウター宛先MACアドレスは、ターゲットのVTEPまたは中間レイヤ3ルータのアドレスの可能性がある。アウターVLANタグはオプションである。存在する場合、LAN上のVXLANトラフィックを区別するために使用できるかも知れない。

図1: IPv4アウタ・ヘッダを使用したVXLANフレームのフォーマット

上記のフレーム・フォーマットは、トランスポートにIPv4を使用したイーサネット・フレームのトンネリングを示している。IPv6トランスポートでのVXLANの使用については、以下で詳しく説明する。

図 2: IPv6 外部ヘッダー付きVXLANフレーム フォーマット

6. VXLANの導入シナリオ

VXLANは通常、データセンターの仮想化ホストに導入されるが、そのホストは複数のラックにまたがる場合がある。個々のラックは、異なるレイヤ3ネットワークの一部である場合もあれば、1つのレイヤ2ネットワーク内の場合もある。VXLANセグメント/オーバーレイ・ネットワークは、これらのレイヤ2またはレイヤ3ネットワーク上にオーバーレイされる。

図3は、レイヤ3インフラに接続された2つの仮想化サーバを表している。サーバは同じラックにある場合もあれば、異なるラックにある場合もあり、同じ管理ドメイン内の複数のデータセンターにまたがる場合もある。VNI 22、34、74、98で識別される4つのVXLANオーバーレイ・ネットワークがある。サーバ1 のVM1-1とサーバ2のVM2-4が、VNI 22で識別される同じVXLANオーバーレイ・ネットワーク上にある場合を考えてみる。カプセル化とカプセル化解除はサーバ1と2のVTEPで透過的に行われるため、VMはオーバーレイ・ネットワークとトランスポート方式については知らない。他のオーバーレイ・ネットワークと対応するVMは、VNI 34上のサーバ1 のVM1-2とサーバ2のVM2-1、VNI 74上のサーバ1のVM1-3とサーバ2のVM2-2、そして最後にVNI 98上のサーバ1のVM1-4とサーバ2のVM2-3である。

図3: VXLANの導入- レイヤ3ネットワーク上のVTEP

1つの導入シナリオは、トンネルの終端ポイントがVXLANを認識する物理サーバの場合である。別のシナリオとしては、VXLANオーバーレイ・ネットワーク上のノードが、VLANベースのレガシー・ネットワーク上のノードと通信する必要がある場合である。これらのノードは、物理ノードまたは仮想マシンである。この通信を可能にするために、ネットワークにはVXLAN環境と非VXLAN環境の間でトラフィックを転送するVXLANゲートウェイ(下図4を参照、スイッチはVXLANゲートウェイとして機能する)を含めることができる。

以下は、図4に沿って説明する。VXLAN接続インタフェース上の着信フレームに対して、ゲートウェイはVXLANヘッダを取り除き、インナー・イーサネット・フレームの宛先MACアドレスに基づいて物理ポートに転送する。インナーVLAN IDを持つカプセル化解除されたフレームは、非VXLANインタフェースに渡すように明示的に設定されていない限り、破棄する必要がある(SHOULD)。逆方向では、非VXLANインタフェースの着信フレームは、フレーム内のVLAN IDに基づいて特定のVXLANオーバーレイ・ネットワークにマッピングされる。カプセル化されたVXLANフレームに渡されるように明示的に設定されていない限り、このVLAN IDはフレームがVXLAN用にカプセル化される前に削除される。

VXLANトンネル終端機能を提供するこれらのゲートウェイは、ToR/アクセス・スイッチ、またはデータセンター・ネットワーク・トポロジーの上位にあるスイッチ(コア・デバイスやWANエッジ・デバイスなど)の可能性がある。最後のケース(WANエッジ)では、ハイブリッド・クラウド環境でVXLANトンネルを終端するプロバイダ・エッジ(PE)ルータが含まれる可能性がある。これらすべての事例において、ゲートウェイ機能はソフトウェアまたはハードウェアで実装されていることに留意する。

図4: VXLAN導入- VXLANゲートウェイ

6.1. インナーVLANタグの処理

VTEPとVXLANゲートウェイにおけるインナーVLANタグの処理は以下に従うべきである:

インナーVLANタグを持つカプセル化解除されたVXLANフレームは、特に設定されていない限り破棄すべきである(SHOULD)。カプセル化側では、VTEPは特に設定されていない限り、トンネル・パケットにインナーVLANタグを含めるべきではない(SHOULD NOT)。賢明な方法である。VLANタグ付きパケットがVXLANトンネリングの候補の場合、カプセル化VTEPは、別の設定がない限り、VLANタグを取り除くべきである(SHOULD)。

7. セキュリティに関する考慮事項

従来、レイヤ2ネットワークは、不正なエンドポイントによって「内部」から攻撃を受ける可能性があった。LANへの不適切なアクセスにより、トラフィックをスヌーピングしたり、スプーフィングしたパケットを注入して別のMACアドレスを「乗っ取ったり」、フラッディングしてサービス拒否を引き起す。レイヤ2トラフィックを配信するためのMAC-over-IPメカニズムは、この攻撃対象領域を大幅に拡大する。それは、VXLANセグメントのブロードキャスト・トラフィックを伝送する1つ以上のマルチキャスト・グループに加入することで、ネットワークに自身を注入するならず者によって引き起こされ、またMAC-over-UDPフレームをトランスポート・ネットワークに送り込んで偽のトラフィックを挿入し、おそらくMACアドレスをハイジャックすることによって起こる可能性がある。

本文書は、このような攻撃に対する具体的な対策は盛り込まず、代わりにIPの上に階層化された他の従来のメカニズムを当てにしている。代わりにこのセクションでは、VXLAN環境におけるセキュリティの可能なアプローチをいくつか概説する。

不正なエンドポイントによる従来のレイヤ2攻撃は、VXLAN環境でVM/ゲートウェイをデプロイし、管理する人の管理および管理範囲を制限することで軽減できる。さらに、個々のエンドポイントのアドミッション・コントロール用の802.1X [802.1X]のようなスキームによって、このような管理対策を補強することができる。また、VXLANのUDPベースのカプセル化を使用することで、物理スイッチで5タプルベースのACL(アクセス制御リスト)機能の設定と使用が可能になる。

IPネットワーク上のトンネル化されたトラフィックは、VXLANトラフィックを認証し、オプションで暗号化するIPsecのような従来のセキュリティ・メカニズムで保護することができる。もちろん、認証されたエンドポイントが資格情報を取得・配布するための認証インフラと組み合わせる必要がある。

VXLANオーバーレイ・ネットワークは、既存のLANインフラ上で指定・運用される。VXLANエンドポイントとそのVTEPがLAN上で認証されていることを保証するには、VXLANトラフィック用にVLANを指定し、サーバ/VTEPがこのVLAN経由でVXLANトラフィックを送信してセキュリティ対策を講じることが推奨される。

さらに、VXLANはこれらのオーバーレイ・ネットワークにおけるVNIとVMメンバーシップを適切にマッピングする必要がある。このマッピングは、既存の安全な方法を使用して実行され、VTEPとゲートウェイの管理エンティティに伝達されることが期待される。

8. IANAの考慮事項

VXLANのサービス名とトランスポート・プロトコルのポート番号レジストリで、IANAによって既知のUDPポート(4789)が割り当てられている。ポート番号については、セクション5を参照のこと。

9. 参考文献

9.1. 引用規格

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

9.2. 参考規格

[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.1D] IEEE, "Draft Standard for Local and Metropolitan Area Networks/ Media Access Control (MAC) Bridges", 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.

[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, November 1990.

[RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery for IP version 6", RFC 1981, August 1996.

[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.

[RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", RFC 4601, August 2006.

[RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, "Bidirectional Protocol Independent Multicast (BIDIR-PIM)", RFC 5015, October 2007.

[RFC6325] Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A. Ghanwani, "Routing Bridges (RBridges): Base Protocol Specification", RFC 6325, July 2011.

[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.

10. 謝辞

著者らは、セキュリティに関する考慮事項のセクションへの貢献と編集上の入力に対してアジット・サングリに感謝の意を表す。ジョセフ・チェン、マーガレット・ペトロス、ミルン・デサイ、ニアル・デ・バハ、ジェフ・マンディン、シヴァ・コリパラの編集レビュー、意見、コメントに感謝する。

著者のアドレス

マリック・マハリンガム
Storvisor, Inc.
640 W. California Ave, Suite #110
Sunnyvale, CA 94086.
米国
Eメール: [e-mail]

ディネシュ・G・ダット
Cumulus Networks
140C S. Whisman Road
Mountain View, CA 94041
米国
Eメール: [e-mail]

ケネス・デューダ
Arista Networks
5453 Great America Parkway
Santa Clara, CA 95054
米国
Eメール: [e-mail]

プニート・アガルワル
Broadcom Corporation
3151 Zanker Road
San Jose, CA 95134
米国
Eメール: [e-mail]

ローレンス・クリーガー
Cisco Systems, Inc.
170 W. Tasman Avenue
San Jose, CA 95134
米国
Eメール: [e-mail]

T・スリダール
VMware, Inc.
3401 Hillview
Palo Alto, CA 94304
米国
Eメール: [e-mail]

マイク・バーセル
Intel
Bowyer's, North Road
Great Yeldham
Halstead
Essex. C09 4QD
イギリス
Eメール: [e-mail]

クリス・ライト
Red Hat, Inc.
100 East Davie Street
Raleigh, NC 27601
米国
Eメール: [e-mail]

更新履歴

• 2024.11.13
• 2024.11.18