トンネリング

トンネリング

トンネリングとは共用ネットワークの 2 点間で仮想の専用線を構築する技術のことをいう。 トンネリングはトンネリング用のプロトコルを用いてパケットをカプセル化させることで実現させている。

トンネリングプロトコルにはいくつか種類が存在する。(Wikipediaより)

• IP in IP
• SIT/IPv6
• GRE (RFC1701)
• OpenVPN (参考 RFC8922 3.4.3)
• SSTP (Secure Socket Tunneling Protocol)
• IPSec (Internet Protocol Security)
• VXLAN (Virtual Extensible Local Area Network)

IP in IP

IP in IP のカプセル化の方法は単純であり、IP パケットに別の IP パケットでカプセル化を行う。

(RFC1853より)

外側の IP ヘッダについて以下のようになる。

• Type Of Service

  元の IP ヘッダの内容をコピーする。また、必要に応じて変更されることもある。

• Identification

  新しく作成する。

• Don't Fragment

  元の IP ヘッダの内容をコピーする。

• More Fragments

  フラグメンテーションが発生する場合は必要である。

• Time To Live

  RFC3232 (RFC1700)で決められたデフォルト値を使用

• Protocol

  次のヘッダ。トンネルヘッダが存在しない場合であれば、内部 IPv4 となる。

• Source address

  データグラムの送信に使用されるインターフェースに関連付けられた IP アドレス。

• Destination address

  カプセル化を解除する宛先 IP アドレス

• Options

  元の IP ヘッダからコピーしない。新しいものが追加されることがある。

SIT/IPv6

IPv6 同士で通信を行う際に途中で IPv4 で通信を行わないといけない場面が生じた際に、IPv4 でやりとりするためにカプセル化を行う。 カプセル化を行うことで IPv4 としてデータをやりとりができるようになる。

GRE

GRE は Generic Routing Encapsulation の略であり、以下のような形式をとる。

GRE ヘッダは以下の構造をしている(RFC2784はまだ(2023 年 1 月現在)Proposed Standard なので[RFC1701][rfc1071]で記述されている構造)。

• C (1bits)

  Checksum Presentの略であり、1 となっていればChecksumが存在することを意味する。

• R (1bits)

  Routing Presentの略であり、1 となっていればOffsetとRoutingが存在することを意味する。

• K (1bits)

  Key Presentの略であり、1 となっていればKeyが存在することを意味する。

• S (1bits)

  Sequence Number Presentの略であり、1 となっていればSequence Numberが存在することを意味する。

• s (1bits)

  Strict Source Routeの略であり、1 となっていればStrict Source routeであることを意味する。 Strict Source route とは送信者がパケットが通過する経路を指定することを意味している。

• Recur (3bits)

  Recursion Controlの略であり、再帰制御で許容される追加のカプセル化の数を格納する(間違っているかも)。基本的には 0 が入る

  Details

  原文

  Recursion control contains a three bit unsigned integer which contains the number of additional encapsulations which are permissible. This SHOULD default to zero.

• Flags (5bits)

  予約されたものであり、現在は全て 0 が入る。

• Ver (3bits)

  Version Numberの略であり、必ず 0 を入れる必要がある。

• Protocol Type (16bits)

  ペイロードパケットのプロトコルタイプが格納されている。一般的にはイーサネットプロトコルタイプが格納される。 定義されているプロトコルタイプは以下である。

  Protocol Family	PTYPE
  Reserved	0000
  SNA	0004
  OSI network layer	00FE
  PUP	0200
  XNS	0600
  IP	0800
  Chaos	0804
  RFC 826 ARP	0806
  Frame Relay ARP	0808
  VINES	0BAD
  VINES Echo	0BAE
  VINES Loopback	0BAF
  DECnet (Phase IV)	6003
  Transparent Ethernet Bridging	6558
  Raw Frame Relay	6559
  Apollo Domain	8019
  Ethertalk (Appletalk)	809B
  Novell IPX	8137
  RFC 1144 TCP/IP compression	876B
  IP Autonomous Systems	876C
  Secure Data	876D
  Reserved	FFFF

• Offset (16bits)

  Routing フィールドの先頭から、検査されるアクティブ Source Route Entry の最初のバイト(8bit)までのバイトオフセットを示す(間違っているかも)。

  Details

  原文

  The offset field indicates the octet offset from the start of the Routing field to the first octet of the active Source Route Entry to be examined. This field is present if the Routing Present or the Checksum Present bit is set to 1, and contains valid information only if the Routing Present bit is set to 1.

• Checksum (16bits)

  GRE ヘッダとペイロードのチェックサムが入っている(1 の補数)

• Key (32bits)

  カプセル化により挿入されるものであり、受信者が送信元を確認することが可能。

• Sequence Number (32bits)

  カプセル化で挿入され、符号なし 32bit 数値である。パケットの送信順序を確立するために受信者が使用する可能性がある。

• Routing (可変)

  SRE(Source Route Entries)のリストが格納され、それぞれの SRE は次の形式をとる。

  

  Routing は、0x0000 タイプの address family と長さ 0 とする「NULL」SRE で終了する。

  • Address Family (16bits)

    Routing Informationのシンタックスとセマンティクスを示す。詳細については別ドキュメントに記載されいる(別ドキュメントのリンクは RFC に貼られていなかった)。

  • SRE Offset (8bits)

    Routing Informationの先頭から、検査する Source Route Entry のアクティブエントリーの最初のオクテットまでのオクテットオフセットを示す。(間違っているかも)

    Details

    原文

    The SRE Offset field indicates the octet offset from the start of the Routing Information field to the first octet of the active entry in Source Route Entry to be examined.

  • SRE Length (8bits)

    SRE のオクテット数が格納されている。これが 0 であるということは最後の SRE であることを意味する。

  • Routing Information (可変)

    パケットのルーティングに使用できるデータが含まれている。

  平成 28 年 午後 2 問 2 に GRE に関する問題が登場している。

  

  この図に送信元 IP・宛先 IP を図示すると以下のようになる。

  

  PC とサーバが専用線で直接接続されているように見える。

GRE は IP マルチキャストパケットもカプセル化することができるため、IPsec のようにマルチキャストパケットでカプセル化できないプロトコルと合わせて使用されることがある。

OpenVPN

OpenVPN は、サーバ間に暗号化されたトンネルを作成するためのオープンソースの Virtual Private Network（VPN）ソフトウェアである。 (Wikipediaより)

OpenVPN は 2 つのモードを持っている。

• Static Key
• TLS

Static Keyでは事前共有静的キーを使用し、TLSでは認証と鍵交換に SSL/TLS $+$ 証明書を使用する。

Static Key

トンネリングが開始する前に事前共有キーが生成され、OpenVPN で接続する PC 同士で共有される。このキーには 4 つの独立したキーが含まれている。

• HMAC 送信
• HMAC 受信
• 暗号化
• 復号化

HMAC は Hash-based Message Authentication Code の略で、メッセージ認証の暗号化技術の 1 つである。

Details

原文

In static key mode, a pre-shared key is generated and shared between both OpenVPN peers before the tunnel is started. This static key contains 4 independent keys: HMAC send, HMAC receive, encrypt, and decrypt. By default in static key mode, both hosts will use the same HMAC key and the same encrypt/decrypt key.

TLS

SSL セッションは双方向認証で確立される。つまり、接続する両方で証明書を提示する必要がある。 SSL/TLS 認証に成功すると、暗号化・復号化・HMAC キーのソースマテリアルを OpenSSL's RAND_bytes 関数を用いて生成し、 SSL/TLS コネクションを通して共有される。キーが双方向に使用されることはないため、各ピアには個別の送信 HMAC、受信 HMAC、パケット暗号化、およびパケット復号化キーがある。

Details

原文

In SSL/TLS mode, an SSL session is established with bidirectional authentication (i.e. each side of the connection must present its own certificate). If the SSL/TLS authentication succeeds, encryption/decryption and HMAC key source material is then randomly generated by OpenSSL's RAND_bytes function and exchanged over the SSL/TLS connection. Both sides of the connection contribute random source material. This mode never uses any key bidirectionally, so each peer has a distinct send HMAC, receive HMAC, packet encrypt, and packet decrypt key.

備考

原文はOpenVPNから引用している。

OpenVPN は次のような形式をしている。

初期化ベクトルとは暗号化の際に使用するランダムに生成されたビット列である。 または、HMAC は初期化ベクトルと暗号化した範囲から算出している。

SSTP

SSTP は Secure Socket Tunneling Protocol の略であり、Microsoftが開発したプロトコルであり、 HTTPS プロトコルを介して Point-to-Point Protocol (PPP) トラフィックをカプセル化するものである。

SSTP により、HTTPS を介した PPP トラフィックのカプセル化できるため、次の図のような関係になる(Microsoftでダウンロードできる PDF の図 1 より)。

SSTP パケットは次の図のような構成をとる。

• Version (8bits)

  使⽤される SSTP のバージョンの通信とネゴシエーションに使⽤されるものである。

  上位 4bit がメジャーバージョンを表し、下位 4bit がマイナーバージョンを表している。

• Reserved (7bits)

  将来の使⽤のために予約されている。0 をセットする。

• C (1bit)

  パケットが SSTP 制御パケットであるかを判断するものである。

  bit	説明
  1	制御パケット
  0	データパケット

• LengthPacket (16bits)

  次のような形式をとる。

  

  • R (4bits)

    将来の使⽤のために予約されている。0 をセットする。

  • Length (12bits)

    バイトサイズであり、4bytes の SSTP ヘッダも含まれる。

• Data (可変)

  Cが 1 であれば制御メッセージが格納され、0 であれば上位プロトコルからのペイロードが格納されている。 SSTP データ パケットは、PPP フレームをペイロードとして通信する。

SSTP 制御パケット

制御パケットはクライアントとサーバーの両⽅が制御メッセージを相互に送信するために使⽤するパケットであり、以下の形式を取る。

上位 4bytes は上記で説明したものと全く同じであるので割愛する。

• Message Type (16bits)

  メッセージのタイプを指定指定しており、次のどれかを指定する必要がある。

  Name	値
  SSTP_MSG_CALL_CONNECT_REQUEST	0x0001
  SSTP_MSG_CALL_CONNECT_ACK	0x0002
  SSTP_MSG_CALL_CONNECT_NAK	0x0003
  SSTP_MSG_CALL_CONNECTED	0x0004
  SSTP_MSG_CALL_ABORT	0x0005
  SSTP_MSG_CALL_DISCONNECT	0x0006
  SSTP_MSG_CALL_DISCONNECT_ACK	0x0007
  SSTP_MSG_ECHO_REQUEST	0x0008
  SSTP_MSG_ECHO_RESPONSE	0x0009

• Num Attributes (16bits)

  メッセージ内の属性(Attributes)の数を指定するものである。

• Attributes (可変)

  SSTP コントロール メッセージを構成する可変サイズの属性である。 全てを書くと長いのでMicrosoftの 2.2.4 章からこの属性についての説明がされている(2023/2/4 現在)。

SSTP データパケット

SSTP データパケットは、SSTP クライアントと SSTP サーバーの両⽅が上位層のペイロード(つまり、PPP フレーム)を相互に送信するために使⽤する SSTP パケットであり、以下の形式を取る。

• Data (可変)

  上位層の可変長のペイロードである。

IPsec

IPsec は IP Security の略であり、IP パケットをカプセル化するプロトコルである。IP v4, v6 のどちらでも使用できるプロトコルであり、 カプセル化セキュリティペイロード(ESP)または認証ヘッダー(AH)の 2 つのヘッダに対応している。

IPsec ではセキュアな通信を提供するために、2 つのネットワークエンティティ間で共有セキュリティ属性を確立する SA(Security Association) を用いている。

(IPsec の章において)以降の図で灰色のデータはオプションを意味している。

IP 認証ヘッダ(AH)

IP 認証ヘッダ(AH)は、IP データグラムのための完全性と認証を確認し、リプレイ攻撃の対策として使用される。

AH は次のような構成をとる。

• Next Header (8 bits)

  認証ヘッダの後の次のペイロードのタイプを識別する 8 ビットのフィールドである。IANAで定義された IP プロトコル番号のセットが使用される。

• Payload Length (8 bits)

  4 バイト単位であり、最終結果から-2 する必要がある。例えば、整合性チェック値が 96bit のアルゴリズムで決められた値が設定される場合 整合性チェック値以外の 12bytes (3)と整合性チェックの 96bits (12bytes)を足し合わせた6から-2した4が入る。

  なぜ-2 されるのかは謎。

  Details

  原文

  This 8-bit field specifies the length of AH in 32-bit words (4-byte units), minus "2". Thus, for example, if an integrity algorithm yields a 96-bit authentication value, this length field will be "4" (3 32-bit word fixed fields plus 3 32-bit words for the ICV, minus 2). For IPv6, the total length of the header must be a multiple of 8-octet units. (Note that although IPv6 [DH98] characterizes AH as an extension header, its length is measured in 32-bit words, not the 64-bit words used by other IPv6 extension headers.) See Section 2.6, "Integrity Check Value (ICV)", for comments on padding of this field, and Section 3.3.3.2.1, "ICV Padding".

• Reserved (16 bits)

  将来の使用のために予約されている。

• Security Parameters Index (SPI) (32 bits)

  受信側が受信するパケットを決定する SA を識別するために使用する任意の 32 ビット値である。 1 $\sim$ 255 までの範囲の SPI 値は、将来の使用のため Internet Assigned Numbers Authority（IANA）によって予約されている。

• Sequence Number Field (32 bits)

  パケットを送り合うたびに+1 されるシーケンス番号である。SA が確立した時は送信側・受信側は 0 から開始する。 デフォルトではリプレイ攻撃のためシーケンス番号はループしないようになっているので$2^{32}$まで増加すると新しい SA を確立する必要がある。

• Integrity Check Value-ICV (可変)

  整合性チェック値であり、このパケットの整合性を確認するために用いられる。また、必ず 32bit(IPv4)または 64bit(IPv6)である必要があるため、パディングされる場合もある。 この値は SA によって定められ、対称鍵暗号化アルゴリズム・SHA-1, SHA-256, MD5 のようなハッシュ関数が用いられる。

カプセル化セキュリティペイロード(ESP)

カプセル化セキュリティペイロード(ESP)は、IP ヘッダの後の次の層のプロトコルのヘッダの間またはカプセル化された IP ヘッダの前に挿入される。 ESP を使用することで、機密性・送信元認証・コネクションレス完全性・リプレイ攻撃防止・トラフィックの機密性を保つことができる。

ESP は次のような構造をとる。

ペイロードの詳細は次のようになる。

TFC は Traffic Flow Confidentiality の略であり、IPsec のトンネルモードの時に挿入される場合がある。

• Security Parameters Index (SPI) (32 bits)

  受信側で SA を判別するために使用され、必須のフィールドである。

• Sequence Number (32 bits)

  AH と同じであり、パケットを送り合うたびに+1 されるシーケンス番号である。SA が確立した時は送信側・受信側は 0 から開始する。

• Payload Data (可変)

  次のヘッダフィールドによって記述されるデータを含む可変長フィールドである。

• Padding (0 ~ 255 bits)

  暗号化を行った際に bit の幅を合わせるために使用される。

• Pad Length (8 bits)

  padding の長さを表し、必須フィールドである。

• Next Header (8 bits)

  ペイロードデータフィールドに含まれるデータのタイプを識別する必須の 8 ビットのフィールドで、IANA で定義されている。

• IV (オプション)

  初期化ベクトル

• Traffic Flow Confidentiality (可変)

  データの長さを隠蔽するために使用されるパディングである。

• Integrity Check Value (ICV) (可変)

  整合性を確認するために使用する値。ESP ヘッダ・ペイロード・ESP トレーラフィールドの値から算出される。

接続方法(モード)

また、IPsec には 2 種類の接続方法が存在する。

• トランスポートモード
• トンネルモード

トランスポートモードでは IP ヘッダは変更せず、ペイロード部分のみ暗号化するものであり、トンネルモードでは IP ヘッダも暗号化を行い、別の IP ヘッダを付与する。

トランポートモードでは IP ヘッダがそのままなので、送信元から宛先までの全区間で IPsec が行われている状態であるため、送信元・宛先両方が IPsec に対応している必要がある。

トンネルモードでは別の IP ヘッダを付与しているため、オリジナル IP ヘッダ(暗号化された IP ヘッダ)はそのままである。そのため、送信元と宛先の途中の一部だけ IPsec を行うということが 可能となる。

つまり、IPsec には接続方法 2 種類 $\times$ ヘッダー 2 種類で合計 4 パターン存在する。

• トランスポートモード・AH ヘッダ
• トランスポートモード・ESP ヘッダ
• トンネルモード・AH ヘッダ
• トンネルモード・ESP ヘッダ

トランスポートモード・AH ヘッダの場合の IP ヘッダは次のような形式になる。

トンネルモード・AH ヘッダの場合の IP ヘッダは次のような形式になる。

トランスポートモード・ESP ヘッダの場合の IP ヘッダは次のような形式になる。

トンネルモード・ESP ヘッダの場合の IP ヘッダは次のような形式になる。

IKEv2 (Internet Key Exchange Protocol Version 2)

IPsec の鍵交換にためのプロトコルであり、RFC7296で定義されている。

IKE はそれぞれの通信間で相互認証を実行し、カプセル化セキュリティペイロード(ESP)または認証ヘッダー(AH)の SA を効率的に確立するために 使用できる共有秘密鍵を含む IKE Security Association(SA)を確立する。

IKE メッセージを送信する側をイニシエータと呼び、応答を返す側をレスポンダと呼ぶ。

ヘッダー

IKE ヘッダーは次のような構成をとる。

• IKE SA Initiator's SPI (64 bits)

  一意の IKE SA を識別するためにイニシエーターによって選択された値。0 であってはならない。

• IKE SA Responder's SPI (64 bits)

  一意の IKE SA を識別するためにレスポンダによって選択された値。一番はじめのメッセージでは 0 でなければならない。

• Next Payload (8 bits)

  ヘッダーの直後に続くペイロードのタイプを示す。

  Next Payload Type	Notation	Value
  No Next Payload		0
  Security Association	SA	33
  Key Exchange	KE	34
  Identification - Initiator	IDi	35
  Identification - Responder	IDr	36
  Certificate	CERT	37
  Certificate Request	CERTREQ	38
  Authentication	AUTH	39
  Nonce	Ni, Nr	40
  Notify	N	41
  Delete	D	42
  Vendor ID	V	43
  Traffic Selector - Initiator	TSi	44
  Traffic Selector - Responder	TSr	45
  Encrypted and Authenticated	SK	46
  Configuration	CP	47
  Extensible Authentication	EAP	48

• Major Version (4 bits)

  使用中の IKE プロトコルのメジャーバージョンを示す。このバージョンの IKE に基づく実装では、メジャーバージョンを 2 に設定する必要がある。以前のバージョンの IKE および ISAKMP に基づく実装では、メジャーバージョンを 1 に設定する必要がある。

• Minor Version (4 bits)

  使用中の IKE プロトコルのマイナーバージョンを示す。このバージョンの IKE に基づく実装は、マイナーバージョンを 0 に設定する必要がある。受信したメッセージのマイナーバージョン番号を無視する必要がある。

• Exchange Type (8 bits)

  使用されている交換のタイプを示す。これにより、交換で各メッセージで送信されるペイロードが制限される。

  Exchange Type	Value
  Reserved	0 $\sim$ 33
  IKE_SA_INIT	34
  IKE_AUTH	35
  CREATE_CHILD_SA	36
  INFORMATIONAL	37
  IKE_SESSION_RESUME	38
  GSA_AUTH	39
  GSA_REGISTRATION	40
  GSA_REKEY	41
  Unassigned	42
  IKE_INTERMEDIATE	43
  IKE_FOLLOWUP_KE	44
  Unassigned	45 $\sim$ 239
  Private use	240 $\sim$ 255

  最新のものについてはIANAに記載されている。

• Flags (8 bits)

  メッセージに設定されている特定のオプションを示す。

  

  • X

    送信時には 0 とし、受信時は無視する必要がある。

  • R

    このビットは、このメッセージが同じメッセージ ID を含むメッセージへの応答であることを示す。このビットは、すべての要求メッセージでクリアする必要があり、すべての応答で設定する必要がある。

  • V

    このビットは、送信機が、メジャーバージョン番号フィールドに示されているものよりも高いプロトコルのメジャーバージョン番号を読み込めることを示す。 IKEv2 の実装では、送信時にこのビットを 0 にする必要があり、受信メッセージでは無視する必要がある。

  • I

    このビットは、IKE SA の元のイニシエーターが送信したメッセージで設定する必要があり、レスポンダーが送信したメッセージで 0 にする必要がある。

• Message ID (32 bits)

  失われたパケットの再送信および要求と応答のマッチングを制御するために使用されるメッセージ ID。メッセージ再生攻撃を防ぐために使用されるため、プロトコルのセキュリティに不可欠である。詳細はセクション 2.1 と 2.2 に記載されている。

• Length (32 bits)

  バイト単位の合計メッセージ（ヘッダー+ペイロード）の長さ。

通信

IKE を使用した通信は、常に IKE_SA_INIT および IKE_AUTH 交換（IKEv1 ではフェーズ 1 として知られている）で始まり、 最初の交換は通常 4 つのメッセージで構成されるが、シナリオ(AH なのか ESP なのかトンネルモードなのかトランスポートモードなのか)によって増える場合がある。

メッセージの初めは IKE_SA_INIT であり、暗号アルゴリズムやノンスをDiffie-Hellman 鍵交換方式で交換する。

2 番目のメッセージは IKE_AUTH であり、前のメッセージの認証, 身元・証明書の交換を行い、IKE SA を確立する。

最初の交換に続くすべてのメッセージは IKE_SA_INIT で決定された暗号化アルゴリズムとキーを使用して暗号化されて保護される。

すべての IKE メッセージには、固定ヘッダーの一部としてメッセージ ID が含まれている。 このメッセージ ID は、リクエストとレスポンスを照合し、メッセージの再送信を識別するために使用される。

Notation	Payload
AUTH	Authentication
CERT	Certificate
CERTREQ	Certificate Request
CP	Configuration
D	Delete
EAP	Extensible Authentication
HDR	IKE header (not a payload)
IDi	Identification - Initiator
IDr	Identification - Responder
KE	Key Exchange
Ni, Nr	Nonce
N	Notify
SA	Security Association
SK	Encrypted and Authenticated
TSi	Traffic Selector - Initiator
TSr	Traffic Selector - Responder
V	Vendor ID

イニシエータの初めのメッセージは次のような形式をしている。

このパケットの Security Association - Initiator 1 ではイニシエータが IKE SA に対してサポートしている暗号化アルゴリズムを示している。 Key Exchange - Initiator では Diffie-Hellman 値を送信している。

これに対するレスポンダの応答は次のような形式を取る。

Security Association - Responder 1 で選択した暗号スイートを表し、 Key Exchange - Responder で Diffie-Hellman 交換を終了させる。

この時点で SKEYSEED と呼ばれる値を生成することができ、IKE SA 用の鍵が全て導出することができる。 今後のメッセージはヘッダを除いて、暗号化が行われ、完全性が担保される。

イニシエータの次のメッセージは次のような形式をとる。

Identification - Initiator でイニシエータの身元を主張し、整合性は Authentication ペイロードを使用する。 証明書を Certificate ペイロードで送信し、トラストアンカーのリストを Certificate Request ペイロードで送信する場合がある。

Traffic Selector は、アドレス範囲（IPv4 または IPv6）、ポート範囲、および IP プロトコル ID で構成される。

Security Association - Initiator 2 ペイロードを使用して子 SA(IPsec SA) のネゴシエーションを開始する。

このメッセージに対するレスポンダの応答は次のような形式を取る。

レスポンダは Identification - Responder で自身身元を証明する。オプションで証明書を 1 枚以上送信し、身元認証を行うことで 2 番目のメッセージの完全性を証明する。 これにより子 SA(IPsec SA) のネゴシエーションを完了し、 IKE_AUTH の通信を行ったもの同士がすべての署名とメッセージ認証コード(MAC)が正しく計算されていることを確認する必要がある。

CREATE_CHILD_SA exchange を使用して新しい SA の作成や IKE SA や Child SA のリキーを行う。 CREATE_CHILD_SA exchange は IKE v1 ではフェーズ 2 と呼ばれている。 SA は新しい SA を生成してから古い SA を削除することでリキーが行われる。 RFC7296セクション 2.8 は、古い SA から新しい SA へのトラフィックの移動や古い SA の削除など、リキーの仕組みを説明している。

VXLAN

VXLAN は Virtual eXtensible Local Area Network の略である。 仮想 LAN（VLAN）の現在の制限は 4094 であり、現在の VM(Virtual Machine)のグループ分けには不十分である。そのため、この問題を解決する方法として VXLAN が登場した。 同じ VXLAN セグメント内の VM のみが相互に通信でき、各 VXLAN セグメントは、VXLAN Network Identifier (VNI)と呼ばれる 24 ビットのセグメント ID によって識別される。 VNI は、VM から発信された内部 MAC フレームをカプセル化する外部ヘッダーにある。

VXLAN は次のような形でカプセル化を行う。

VXLAN ヘッダは次のような形式を取る

• I, R (8 bits)

  フラグであり、有効な VXLAN であれば I は 1 である必要がある。R は予約領域であり、送信時は 0 にし、受信時には無視する。

• Reserved (24 bits, 8 bits)

  予約領域であり、送信時は 0 にし、受信時には無視する。

• VXLAN Network Identifier (VNI) (24 bits)

  セグメント ID である。

参考

• Strict Source Route
• https://www.okta.com/jp/identity-101/hmac/
• https://it-trend.jp/encryption/article/64-0091
• https://en.wikipedia.org/wiki/Secure_Socket_Tunneling_Protocol
• https://amnimo.com/column/037/
• https://www.infraexpert.com/study/ipsec6.html