GRE および IPsec での IP フラグメンテーション、MTU、MSS、PMTUD の問題の解決

概要

このドキュメントでは、IPv4 フラグメンテーションおよび Path Maximum Transmission Unit Discovery（PMTUD; パス最大転送ユニット ディスカバリ）の仕組みを示し、IPv4 トンネルの異なる組み合わせとともに使用される場合の PMTUD の動作に関連するシナリオについて説明します。インターネットで現在広く普及した IPv4 トンネルの利用により、IPv4 フラグメンテーションおよび PMTUD に関連する問題が顕在化しています。

IPv4 フラグメンテーションおよび再構成

IPv4 プロトコルは、さまざまな伝送リンク上で使用する設計になっています。IPv4 データグラムの最大長は 65535 ですが、ほとんどの伝送リンクでは Maximum Transmission Unit（MTU; 最大伝送ユニット）と呼ばれる、より小規模な最大パケット長の制限が適用されます。MTU の値は、伝送リンクのタイプに依存します。IPv4 では、ルータによる IPv4 データグラムのフラグメント化を必要に応じて許可するため、異なる MTU に対応する設計になっています。受信側ステーションには、フラグメントを元の完全なサイズの IPv4 データグラムに再構成する役割があります。

IPv4 フラグメンテーションでは、データグラムが、後に再構成が可能な多数の断片に分割されます。IPv4 ヘッダー内の「More Fragments」および「Don't Fragment」フラグとともに、IPv4 送信元、宛先、識別番号、合計長、およびフラグメントのオフセット フィールドが IPv4 フラグメンテーションおよび再構成のために使用されます。Pv4 フラグメンテーションと再構成のしくみについての詳細は、RFC 791 を参照してください。

図は IPv4 ヘッダーのレイアウトを示しています。

識別番号は 16 ビットです。これは、データグラムのフラグメントの再構成を支援するために、IPv4 データグラムの送信者によって割り当てられる値です。

フラグメント オフセットは 13 ビットであり、元の IPv4 データグラムにおけるフラグメントの位置を示します。この値は 8 バイトの倍数です。

IPv4 ヘッダーのフラグ フィールドには、制御フラグとして 3 ビット用意されています。「Don't Fragment」（DF）ビットによってパケットのフラグメント化を許可するかどうかが判断されるので、PMTUD ではこのビットが中心的な役割を果たすことに注意してください。

ビット 0 は予約済で、常に 0 に設定されています。 ビット 1 は DF ビットです（0 =「May Fragment」、1 =「Do Not Fragment」）。 ビット 2 は MF ビットです（0 =「Last Fragment」、1 =「More Fragment」）。

値	ビット 0 予約済	ビット 1 DF	ビット 2 MF
0	0	May	Last
1	0	Do not	その他（More）

次の図は、フラグメンテーションの例を示しています。IPv4フラグメントのすべての長さを加算すると、値が元のIPv4データグラム長を60超えます。全体の長さが60増えるのは、最初のフラグメントの後に1つずつ、追加の3つのIPv4ヘッダーが作成されたためです。

最初のフラグメントはオフセット 0 であり、このフラグメントの長さは 1500 です。これには、わずかに変更された元の IPv4 ヘッダーの 20 バイトが含まれます。

2 番目のフラグメントのオフセットは 185（185 X 8 = 1480）になっています。これは、このフラグメントのデータ部分が、元の IPv4 データグラムの 1480 バイト目から始まるという意味です。このフラグメントの長さは 1500 です。これには、このフラグメントのために作成された追加の IPv4 ヘッダーが含まれます。

3 番目のフラグメントのオフセットは 370（370 X 8 = 2960）になっています。これは、このフラグメントのデータ部分が、元の IPv4 データグラムの 2960 バイト目から始まるという意味です。このフラグメントの長さは 1500 です。これには、このフラグメントのために作成された追加の IPv4 ヘッダーが含まれます。

4 番目のフラグメントのオフセットは 555（555 X 8 = 4440）になっています。これは、このフラグメントのデータ部分が、元の IPv4 データグラムの 4440 バイト目から始まるという意味です。このフラグメントの長さは 700 バイトです。これには、このフラグメントのために作成された追加の IPv4 ヘッダーが含まれます。

元の IPv4 データグラムのサイズを判断できるのは、最後のフラグメントが受け取られたときだけです。

最後のフラグメント（555）でのフラグメント オフセットによって、元の IPv4 データグラムに 4440 バイトのデータ オフセット値が渡されます。続いて、最後のフラグメントからのデータ バイトを追加すると（680 = 700 - 20）、元の IPv4 データグラムのデータ部分である 5120 バイトが渡されたことになります。続いて、次の図に示すように、IPv4 ヘッダーの 20 バイトが追加され、元の IPv4 データグラムと等しいサイズになります（4440 + 680 + 20 = 5140）。

IPv4 フラグメンテーションに関する問題

IPv4 フラグメンテーションで不都合が発生する、いくつかの問題があります。IPv4 データグラムのフラグメント化は、CPU とメモリのオーバーヘッドをわずかに増大させます。これは、送信側だけではなく、送信側と受信側の間のパスにおけるルータについても当てはまります。フラグメントの作成は、単にフラグメント ヘッダーを作成し、元のデータグラムをフラグメントにコピーするだけです。フラグメントの作成に必要なすべての情報は、ただちに利用できるので、作成は非常に効率的に実行できます。

フラグメントの再構成時には、フラグメンテーションにより受信側ではそれ以上のオーバーヘッドが発生します。受信側では到着するフラグメントにメモリを割り当て、すべてのフラグメントを受け取ってから、これらを 1 つのデータグラムに結合する必要があるということが、この原因です。ホストには、このタスクに費やす時間とメモリ リソースが備わっているため、ホスト側での再構成は問題とはなりません。

ところが、パケットをできるだけ迅速に転送することが主要な機能であるルータ上での再構成は、非常に非効率的です。ルータは、時間にかかわらず、パケットに掛かりっきりになるようには設計されていません。また、再構成を実行しているルータでは、使用可能な最大バッファ（18 K）が処理のために選択されます。この理由は、最後のフラグメントが受け取られるまで、元の IPv4 パケットのサイズがわからないからです。

フラグメンテーションのもう 1 つの問題は、廃棄されたフラグメントの処理方法です。IPv4 データグラムの 1 つのフラグメントが廃棄されると、元のすべての IPv4 データグラムを再送する必要があり、これが再度フラグメント化されます。Network File System（NFS; ネットワーク ファイル システム）を使用した、この例を示します。デフォルトでは、NFS には 8192 の読み取りと書き込みのブロックサイズが用意されるので、 NFS IPv4/UDP データグラムはおよそ 8500 バイトになります（NFS、UDP、IPv4 のヘッダーを含む）。イーサネット（MTU 1500） に接続された送信側ステーションでは、8500 バイトのデータグラムを 6 つにフラグメント化する必要があります。5 つの 1500 バイトのフラグメントおよび 1 つの 1100 バイトのフラグメント）にフラグメント化する必要があります。輻輳しているリンクが原因でこの 6 つのフラグメントのいずれかが廃棄された場合 、元の完全なデータグラムを再転送する必要があります。つまり、さらに 6 つのフラグメントを作成する必要があります。このリンクで 6 つのパケットのうち 1 つがドロップされるとすると、各 NFS 8500 バイトの元の IPv4 データグラムから、少なくとも 1 つの IPv4 フラグメントがドロップされることになるため、このリンクを介して NFS データを転送できる可能性は低くなります。

パケット内のレイヤ 4（L4）からレイヤ 7（L7）の情報に基づいて、パケットをフィルタまたは操作するファイアウォールでは、IPv4 フラグメントの適切な処理に失敗する場合があります。IPv4 フラグメントの順序が入れ替わると、ファイアウォールによって 1 番目以外のフラグメントがブロックされることがあります。この理由は、これらのフラグメントではパケット フィルタに合致する情報が伝送されないからです。これは、受信側ホストでは元の IPv4 データグラムの再構成が不可能であることを意味します。不十分な情報を含む 1 番目以外のフラグメントの、フィルタへの適切な合致を許可するようにファイアウォールが設定されていると、1 番目以外のフラグメントによるファイアウォールを突破した攻撃が発生する可能性があります。また、一部のネットワーク デバイス（コンテント スイッチ モジュール など）では、L4 から L7 の情報に基づいてパケットが操作されます。パケットが複数のフラグメントにわたる場合、このデバイスでのポリシーの実行が失敗することがあります。

IPv4 フラグメンテーションの回避：TCP MSS が何をし、どのように動作するのか

TCP 最大セグメント サイズ（MSS）では、単一の TCP/IPv4 データグラムでホストが受け取るデータの最大量が定義されます。TCP/IPv4 データグラムは、IPv4 レイヤにおいてフラグメント化される場合があります。MSS 値は、TCP SYN セグメント内だけで TCP ヘッダー オプションとして送信されます。TCP 接続のそれぞれの側は、その MSS 値をもう一方の側に報告します。一般的な認識とは異なり、ホスト間で MSS 値がネゴシエートされることはありません。送信側ホストでは、単一の TCP セグメント内のデータ サイズを、受信側ホストから報告された MSS 以下の値に制限する必要があります。

もともと MSS とは、単一の IPv4 データグラム内に含まれた TCP データを格納できるように、受信側ステーションに割り当てられたバッファの大きさ（65496 K 以上）を意味するものでした。つまり、MSS は TCP の受信側で受け取るデータの最大セグメント（チャンク）でした。この TCP セグメントは、最大 64 K（最大 IPv4 データグラム サイズ）の大きさになり、ネットワーク経由で受信側ホストに転送されるように、IPv4 レイヤでフラグメント化することが可能です。受信側ホストでは、IPv4 データグラムを再構成してから、完全な TCP セグメントを TCP レイヤに渡します。

次に 挙げたいくつかのシナリオでは、MSS 値を設定する方法を示します。また、MSS 値により TCP セグメントのサイズを制限することによって、IPv4 データグラムのサイズを制限する方法も示します。

シナリオ 1 では、MSS の初期実装方法を図示します。Host A には 16 K のバッファ、Host B には 8 K のバッファが備わっています。これらのホスト間ではそれぞれの MSS 値が送受信され、互いのデータ送信のための送信 MSS が調整されます。ホストAとホストBは、インターフェイスMTUよりも大きく、送信MSSよりも小さいIPv4データグラムをフラグメント化する必要があります。これは、TCPスタックが16Kまたは8KバイトをスタックからIPv4に渡すためですイーサネットLANに接続します。

シナリオ 1

1. Host A は、MSS 値 16 K を Host B に送信します。
2. Host B は、Host A からの MSS 値 16 K を受信します。
3. Host B は、送信 MSS 値を 16 K に設定します。
4. Host B は、MSS 値 8K を Host A に送信します。
5. Host A は、Host B からの MSS 値 8 K を受信します。
6. Host A は、送信 MSS の値を 8 K に設定します。

TCP 接続のエンドポイントでの IPv4 フラグメンテーションを回避できるようにするため、MSS 値の選択が最小バッファ サイズおよび発信インターフェイスの MTU（- 40）に変更されました。MSS の数値は、MTU の数値より 40 バイト小さい値です。MSS が、20 バイトの IPv4 ヘッダーと 20 バイトの TCP ヘッダーを含まない TCP データのサイズと同じであることが、この理由です。MSS はデフォルトのヘッダー サイズに基づいています。送信者スタックでは、使用されている TCP または IPv4 オプションに応じて、IPv4 ヘッダーおよび TCP ヘッダーのための適切な値を差し引く必要があります。

MSS の動作方法は次のとおりです。まず、各ホストが送信インターフェイス MTU をそれぞれのバッファと比較し、送信する MSS として最小の値を選択します。次に、ホストは受信した MSS のサイズをそれぞれのインターフェイス MTU と再度比較し、2 つの値のより小さな値を再度選択します。

シナリオ 2 では、ローカルおよびリモート接続でのフラグメンテーションを回避するために送信側で実行されるこの追加手順を図示します。各ホストによって（ホストが他方に MSS 値を送信する前に）どのように発信インターフェイスの MTU が考慮され、これがどのようにフラグメンテーションの回避に役立つのかに注意してください。

シナリオ 2

1. Host A では、MSS バッファ（16 K）と MTU（1500 - 40 = 1460）が比較され、Host B に送信する MSS（1460）としてより低い値が使用されます。
2. Host B は、Host A の送信 MSS（1460）を受信し、これを送信インターフェイスの MTU - 40（4422）の値と比較します。
3. Host B は、Host A に送信する IPv4 データグラムの MSS  として、より低い値（1460）を設定します。
4. Host B は、MSS バッファ（8 K）と MTU（4462-40 = 4422）を比較し、Host A に送信する MSS として 4422 を使用します。
5. Host A は Host B の送信 MSS（4422）を受信し、これを送信インターフェイス MTU - 40（1460）の値と比較します。
6. Host A は、Host B に送信する IPv4 データグラムの MSS として、より低い値（1460）を設定します。

1460 が両方のホストによって、それぞれの送信 MSS として選択された値になります。多くの場合、送信 MSS の値は TCP 接続の両側で同じ値になります。

シナリオ 2 では、TCP 接続のエンドポイントにおいてフラグメンテーションは発生しません。この理由は、両方の送信インターフェイス MTU がホストにより考慮されているからです。ただし、いずれかのホストの送信インターフェイスの MTU より低い MTU を含むリンクがあると、ルータ A とルータ B の間のネットワーク内でパケットがフラグメント化される可能性があります。

PMTUD の概要

前述したように、TCP MSSはTCP接続の2つのエンドポイントでフラグメンテーションを処理しますが、これら2つのエンドポイント間に小さなMTUリンクがある場合は処理しません。エンドポイント間のパス内でのフラグメンテーションを回避するために、PMTUD が開発されました。これは、パケットの発信元から宛先までのパス上で、最も低い MTU を動的に判断するために使用されます。

注：PMTUD は TCP および UDP でのみサポートされます。その他のプロトコルでは、これをサポートしていません。PMTUD がホストでイネーブルになっており、ほぼ常にその状態であると、ホストからのすべての TCP および UDP パケットには DF ビットが設定されます。 

ホストが DF ビットを設定して完全な MSS データパケットを送信する際に、パケットに対してフラグメンテーションが必要であるとの情報を受け取ると、PMTUD は接続のための送信 MSS の値を低下させます。ホストは通常、この MTU 値を含むルーティング テーブル内に「host」（/32）エントリを作成するため、宛先の MTU 値を「覚えて」います。

ルータが、パケット サイズより低い MTU を持つリンクへ、DF ビットが設定された IPv4 データグラムの転送を試みる場合には、このルータ はパケットを廃棄し、「Fragmentation Needed and DF set」（タイプ 3、コード 4）を示すコードとともに、Internet Control Message Protocol（ICMP; インターネット制御メッセージ プロトコル）の「Destination Unreachable」メッセージをこの IPv4 データグラムの発信元に返します。 発信元のステーションでは、この ICMP メッセージを受信すると、送信 MSS を低下させ、TCP がセグメントを再伝送する場合には、この小さなセグメント サイズが使用されます。

debug ip icmp コマンドを有効にした後にルータ上に表示される可能性がある、ICMP の「Fragmentation Needed and DF set」メッセージの例をここに示します。

ICMP: dst (10.10.10.10) frag. needed and DF set 
unreachable sent to 10.1.1.1

次の図では、「Fragmentation Needed and DF set」および「Destination Unreachable」メッセージの ICMP ヘッダーの形式を示します。

RFC 1191によると、「Fragmentation Needed and DF set」を示す ICMP メッセージを返すルータでは、ICMP 仕様の RFC 792 で「unused」とラベル付けされている ICMP 追加ヘッダー フィールド下位 16 ビット内に、ネクストホップ ネットワークの MTU が含まれる必要があります。

RFC 1191 の初期の実装では、ネクストホップ MTU 情報は提供されていませんでした。この情報が提供された場合も、一部のホストではこれが無視されています。この場合、RFC 1191 には推奨される値を掲載した表も含まれます。これらの値を参照して、PMTUD 中に MTU を低下させる必要があります。次の図で示すように、送信 MSS の適切な値でより高速に着信させるため、これはホストによって使用されます。

PMTUD はすべてのパケット上で継続して実行されます。この理由は、送信側と受信側の間のパスは動的に変化することがあるからです。送信側が「Can't Fragment」ICMP メッセージを受信するたびに、ルーティング情報（PMTUD の格納場所）が更新されます。

PMTUD 中に、次の 2 つの状態が発生する可能性があります。

1.パケットは、フラグメント化されずにレシーバまですべての方法で到達できます。

注：ルータでは、DoS 攻撃から CPU を保護するために、送信する ICMP unreachable メッセージの数が 1 秒につき 2 件に制限されます。したがって、この状況で、1 秒につき 2 件以上（ホストが異なる可能性がある）の ICMP メッセ時（タイプ 3、コード 4）での応答がルータで必要だと判断されるネットワーク シナリオの場合には、no ip icmp rate-limit unreachable [df] interface コマンドを使用して ICMP メッセージのスロットリングを無効にできます。

2.送信側は、受信側へのパスに沿って、任意の（または各）ホップからICMP「Can't Fragment」メッセージを取得できます。

PMTUD は、TCP フローの両方向において、別々に実行されます。フローの片方の PMTUD では、エンド ステーションによる送信 MSS の低下がトリガーされ、もう片方のエンドステーションでは元の送信 MSS が保持される場合があります。この理由は、PMTUD をトリガするだけの大きさを持つ IPv4 データグラムが送信されていないからです。

次のシナリオ3に示すHTTP接続の良い例を示します。TCPクライアントは小さなパケットを送信し、サーバは大きなパケットを送信します。この場合、サーバの大きなパケット（576 バイト以上）だけが PMTUD をトリガーします。クライアントのパケットは小さく（576 バイト以下）、PMTUD をトリガーしません。この理由は、MTU が 576 のリンクを介した伝送ではフラグメンテーションが必要ではないからです。

シナリオ 3

シナリオ 4 では、パスの 1 つがその他のパスより小さな最小 MTU を持つ状況である、非対称ルーティングの例を示します。非対称ルーティングは、2つのエンドポイント間でデータを送受信するために異なるパスが使用されると発生します。このシナリオでは、TCP フローの一方向においてだけ、PMTUD によって送信 MSS の低下がトリガーされます。TCP クライアントからサーバへのトラフィックは、ルータ A とルータ B 経由で流れますが、サーバからクライアントへのリターン トラフィックは、ルータ D とルータ C 経由で流れます。TCP サーバによってクライアントにパケットが送信されると、PMTUD がサーバをトリガーして送信 MSS を低下させます。この理由は、ルータ C に 4092 バイトのパケットを送信する前に、ルータ D ではこれをフラグメント化する必要があるからです。

これに対して、クライアントでは、「Fragmentation Needed and DF set」を示すコードを持つ ICMP「Destination Unreachable」メッセージを受け取ることはありません。この理由は、ルータ B 経由でサーバに送信する場合、ルータ A ではパケットをフラグメント化する必要がないからです。

シナリオ 4

注：ルータ（たとえば、BGP および Telnet）によって開始された TCP 接続のための TCP MTU パス ディスカバリを有効にするためには、ip tcp path-mtu-discovery コマンドが使用されます。

PMTUD の問題

PMTUD が失敗する 3 つの状況があります。このうちの 2 つは一般的ではありませんが、残りの 1 つは一般的です。

• ルータではパケットの破棄はできるが、ICMP メッセージが送信されない。（一般的ではない）

• ルータでは ICMP メッセージの生成と送信ができるが、ICMP メッセージが、このルータと送信側の間でのルータまたはファイアウォールによってブロックされる。（一般的）

• ルータでは ICMP メッセージの生成と送信ができるが、送信側がこのメッセージを無視する。（一般的ではない）

上記 3 項目の最初と最後の項目は一般的ではなく、通常はエラーの結果ですが、2 番目の項目は一般的な問題を示しています。ICMP パケット フィルタを実装する担当者は、特定の ICMP メッセージ タイプだけではなく、すべての ICMP メッセージ タイプをブロックする傾向があります。パケット フィルタでは、「unreachable」または「time-exceeded」以外のすべての ICMP メッセージ タイプのブロックが可能です。 PMTUD が成功したか、失敗したかは、TCP/IPv4 パケットの送信者に到着する ICMP の unreachable メッセージで判定されます。ICMP の time-exceeded メッセージは、その他の IPv4 問題にとって重要なものです。ルータ上に実装された、このようなパケット フィルタの例を次に示します。

access-list 101 permit icmp any any unreachable
access-list 101 permit icmp any any time-exceeded
access-list 101 deny icmp any any
access-list 101 permit ip any any

ICMP が完全にブロックされてしまうという問題の緩和に役立つ手法が他にもあります。

• ルータ上の DF ビットをクリアし、状況にかかわらずフラグメンテーションを許可します（ただし、これはお勧めできません。詳細については、『IP フラグメンテーションに関する問題』を参照してください）。

• インターフェイス コマンド ip tcp adjust-mss <500-1460> で、TCP MSS のオプション値 MSS を操作します。

次のシナリオでは、ルータ A およびルータ B は同じ管理ドメイン内にあります。ルータ C はアクセスできず、ICMP をブロックするので、PMTUD が失敗します。この状況の回避策として、フラグメンテーションを許可するため、ルータ B で両方向の DF ビットをクリアします。これはポリシー ルーティングで実行できます。DF ビットをクリアするための構文は、Cisco IOS® ソフトウェア リリース 12.1(6) 以降で利用可能です。

interface serial0 
... 
ip policy route-map clear-df-bit 
route-map clear-df-bit permit 10 
	match ip address 111 
	set ip df 0 
 
access-list 111 permit tcp any any

別のオプションは、ルータを通過する SYN パケット上の TCP MSS オプションの値を変更することです（Cisco IOS® 12.2(4)T 以降で使用可能）。 これにより、TCP SYN パケット内の MSS オプションの値が低下し、ip tcp adjust-mss コマンドでの値（1460）より小さくなります。その結果、TCP の送信側では、この値に収まる大きさのセグメントを送信します。IPv4 パケットのサイズは、TCP ヘッダー（20 バイト）と IPv4 ヘッダー（20 バイト）を加えて、MSS 値（1460 バイト）より 40 バイト大きくなります（1500）。

ip tcp adjust-mss コマンドにより、TCP SYN パケットの MSS を調整できます。次の構文では、TCP セグメント上の MSS 値が 1460 に低下させられます。このコマンドは、インターフェイス serial0 での着信と発信両方のトラフィックに影響します。

int s0 
ip tcp adjust-mss 1460

IPv4 トンネルがより広く普及するようになったのに従い、IPv4 フラグメンテーションの問題がさらにまん延するようになりました。トンネルがフラグメンテーションをさらに発生させている理由は、トンネルのカプセル化による「オーバーヘッド」がパケット サイズに付加されているからです。たとえば、Generic Routing Encapsulation（GRE; 総称ルーティング カプセル化）の付加により、24 バイトがパケットに追加されます。そして、この増加によって、パケットが発信側 MTU より大きくなり、フラグメント化が必要になる場合があります。このドキュメントの後のセクションで、トンネルと IPv4 フラグメンテーションによリ発生する種類の問題を、例を挙げて説明しています。

PMTUD が必要とされる一般的なネットワーク トポロジ

PMTUD は、中継リンクの MTU がエンド リンクの MTU より小さいようなネットワーク状況において必要となります。これらのより小さな MTU リンクが存在する一般的な理由としては、次のものがあります。

• トークン リング（または FDDI）に接続されたエンド ホストで、中間にイーサネット接続がある場合。これらの両端でのトークン リング（または FDDI）MTU は、中間にあるイーサネット MTU より大きくなります。

• （ADSL でよく使用される）PPPoE では、そのヘッダーに 8 バイトが必要です。これにより、イーサネットでの有効 MTU が 1492（1500 - 8）に低下します。

GRE、IPv4sec、および L2TP などのトンネリング プロトコルでも、それぞれのヘッダーとトレーラのための領域が必要です。これもまた、発信インターフェイスの有効 MTU を低下させます。

次のセクションでは、2つのエンドホスト間のどこかでトンネリングプロトコルが使用されるPMTUDの影響について説明します。前述の 3 つの状況では、この状況が最も複雑であり、他の状況で発生するすべての問題も含まれます。

Tunnel（トンネル）

トンネルとは、トランスポート プロトコル内で、パッセンジャ パケットをカプセル化する方法を提供する、Cisco ルータ上の論理インターフェイスです。これは、ポイントツーポイント カプセル化スキームを実装するサービスを提供する設計になっているアーキテクチャです。トンネリングには、次の3つの主要コンポーネントがあります。

• パッセンジャ プロトコル（AppleTalk、Banyan VINES、CLNS、DECnet、IPv4、または IPX）

• キャリア プロトコル：次のいずれかのカプセル化プロトコル。

  • GRE - Cisco のマルチプロトコル キャリア プロトコル詳細は、RFC 2784 および RFC 1701 を参照してください。

  • IPv4 トンネル内の IPv4：詳細は、RFC 2003  を参照してください。

• トランスポート プロトコル：カプセル化プロトコルを伝送するために使用されるプロトコル

このセクションで示すパケットは、GRE がカプセル化プロトコルであり、IPv4 がトランスポート プロトコルであるという IPv4 トンネリングの概念を示しています。パッセンジャプロトコルもIPv4です。この場合、IPv4はトランスポートとパッセンジャプロトコルの両方です。

ノーマル パケット

IPv4

TCP

Telnet

トンネル パケット

IPv4

GRE

IPv4

TCP

Telnet

• IPv4 はトランスポート プロトコルです。

• GRE はカプセル化プロトコルです。

• IPv4 はパッセンジャ プロトコルです。

次の例では、キャリアとして GRE を使った、パッセンジャ プロトコルとしての IPv4 および DECnet のカプセル化を示しています。これは、図に示すように、キャリア プロトコルによって複数のパッセンジャ プロトコルのカプセル化が可能であることを示しています。

IPv4 バックボーンによって隔てられた 2 つの非隣接の非 IPv4 ネットワークが存在する状況では、ネットワーク管理者はトンネリングを検討することができます。この非隣接ネットワークで DECnet が実行されている場合、バックボーンに DECnet を設定することにより、これらを接続することを、管理者が望まない場合があります。管理者は、IPv4 ネットワークのパフォーマンスに影響を及ぼす可能性があるため、バックボーン帯域幅を消費する DECnet ルーティングを許可したくない場合があります。

実行可能な代案は、IPv4 バックボーンを介して DECnet をトンネル化することです。トンネリングによって IPv4 内部に DECnet パケットがカプセル化され、バックボーンを介してカプセル化を外すントンネル エンドポイントに送信されます。また、DECnet を介した DECnet パケットの宛先へのルーティングが可能になります。

他のプロトコル内でのトラフィックのカプセル化により、次の利点が実現されます。

• エンドポイントはプライベートアドレス(RFC 1918)を使用し、バックボーンはこれらのアドレスのルーティングをサポートしません。

• WAN またはインターネット介した Virtual Private Network（VPN; バーチャル プライベート ネットワーク）を可能にする。

• 単一プロトコルのバックボーンを介して、非隣接マルチプロトコル ネットワークを統合する。

• バックボーンまたはインターネット上のトラフィックを暗号化する。

このドキュメントの残りの部分では、パッセンジャ プロトコルとしての IPv4 とトランスポート プロトコルとしての IPv4 を取り上げます。

トンネル インターフェイスに関する考察

トンネリングを実行する場合の注意事項は次のとおりです。

• Cisco IOS®リリース11.1でGREトンネルのファーストスイッチングが導入され、バージョン12.0でCEFスイッチングが導入されました。マルチポイントGREトンネルのCEFスイッチングは、バージョン12.2(8)Tで導入されました。トンネル エンドポイントでのカプセル化とカプセル化解除は、プロセス交換だけがサポートされていた Cisco IOS® の初期バージョンでは処理が低速でした。

• パケットをトンネリングする場合には、セキュリティおよびトポロジの問題があります。トンネルは、Access Control List（ACL; アクセス コントロール リスト）およびファイアウォールをバイパスできます。ファイアウォールを介してトンネル化する場合、トンネリングしているパッセンジャ プロトコルの種類にかかわらず、基本的にはファイアウォールをバイパスします。したがって、パッセンジャ プロトコルで任意のポリシーを実施するために、トンネルのエンドポイントにファイアウォール機能を備えることが推奨されます。

• トンネリングでは、遅延の増大により、タイマーで制限されたトランスポート プロトコル（たとえば DECnet）に問題が発生する場合があります。

• 異なる速度のリンクが含まれた環境（高速 FDDI リングと低速 9600 bps 電話回線など）にわたるトンネリングでは、パケットの順序が入れ替わる問題が発生する場合があります。混合メディア ネットワークでは、一部のパッセンジャ プロトコルの機能は不完全です。

• ポイントツーポイント トンネルは、物理リンク上の帯域幅を使い果たす可能性があります。ルーティング プロトコルを複数のポイントツーポイント トンネルを介して実行する場合、各トンネル インターフェイスには帯域幅が割り当てられている点、およびトンネルが実行されている物理インターフェイスにも帯域幅が割り当てられている点に注意してください。たとえば、10 MB リンクを介して 100 のトンネルが実行されている場合、トンネル帯域幅を 100 KB に設定します。トンネルのデフォルト帯域幅は、9 KB です。

• ルーティング プロトコルで、「実」リンクを介したトンネルが優先される場合があります。この理由は、トンネルが、最も低いコスト パスを持つ 1 ホップ リンクであるように誤って認識されるためです。ところが、実際はトンネルにはそれ以上のホップが含まれ、他のパスよりも非常にコスト高です。この問題は、ルーティング プロトコルの適切な設定により軽減できます。物理インターフェイス上で実行されているルーティング プロトコルとは異なるルーティング プロトコルを、トンネル インターフェイスで実行することを検討する必要がある場合があります。

• 再帰ルーティングの問題は、トンネル宛先への適切なスタティック ルートを設定することにより回避できます。再帰ルーティングとは、トンネル宛先へのベスト パスがトンネル自体を通っている場合を指します。この状況では、トンネル インターフェイスが不安定になります。再帰ルーティングの問題が発生している場合、次のエラーが表示されます。

  %TUN-RECURDOWN Interface Tunnel 0
  temporarily disabled due to recursive routing

トンネルのエンドポイントにおいて PMTUD 参加者に関与するルータ

トンネルのエンドポイントとなっているルータには 2 つの異なる PMTUD の役割があります。

• 1 番目の役割では、ルータはホスト パケットを転送します。PMTUD 処理のために、ルータは元のデータ パケットの DF ビットおよびパケット サイズを確認し、必要に応じて適切な処理を行う必要があります。

• 2 番目の役割は、ルータがトンネル パケット内に元の IPv4 パケットをカプセル化した後、実行されます。この段階では、ルータは PMTUD およびトンネル IPv4 パケットに関して、ホストのような動作をします。

PMTUD に関して 、ホスト IPv4 パケットを転送する 1 番目の役割でルータが動作している場合の状況について解説します。この役割は、ルータがトンネル パケット内にホスト IPv4 パケットをカプセル化する前に実行されます。

ルータがホスト パケットの転送側となる場合、次のアクションが実行されます。

• DF ビットが設定されているかどうかの確認

• トンネルが対応できるパケット サイズの確認

• フラグメント化（パケットが大きすぎて DF ビットが設定されていない場合）、フラグメントのカプセル化、および送信。または

• パケットのドロップ（パケットが大きすぎて DF ビットが設定されている場合）および送信者への ICMP メッセージの送信

• カプセル化（パケットが大きすぎない場合）および送信

一般的に、カプセル化後のフラグメント化（2 つのカプセル化フラグメントの送信）、またはフラグメント化後のカプセル化（2 つのカプセル化フラグメントの送信）のどちらかを選択できます。

次のいくつかの例では、IPv4 パケット カプセル化とフラグメント化のしくみ、および、例として挙げられたネットワークを通過するパケットと PMTUD とのインタラクションを示す 2 つのシナリオを説明します。

次の 1 番目の例では、（トンネル発信元の）ルータが転送ルータの役割を果たす場合のパケットの状態を示します。PMTUD 処理のために、ルータは元のデータ パケットの DF ビットおよびパケット サイズを確認し、適切な処理を行う必要があることを思い出してください。この例では、トンネルの GRE カプセル化を使用しています。確認できるように、GRE はカプセル化の前にフラグメント化を実行します。後で挙げる例では、カプセル化の後にフラグメント化が実行されるシナリオを説明します。

例 1 では DF ビットが設定されておらず（DF = 0）、GRE トンネル IPv4 MTU は 1476（1500 - 24）です。

例 1

1.転送ルータ（トンネルの送信元）は、送信側ホストからDFビットがクリア(DF = 0)された1500バイトのデータグラムを受信します。このデータグラムは、20 バイトの IP ヘッダーと 1480 バイトの TCP ペイロードから構成されています。

IPv4	1480 バイト TCP + データ

 2.パケットがGREオーバーヘッド（24バイト）が追加された後のIPv4 MTUに対して大きすぎるため、転送ルータはデータグラムを1476（20バイトIPv4ヘッダー+ 1456バイトIPv4ペイロード）と44バイト（24ヘッダー+の2バイト）の2フラグメントににに分割します24バイトのIPv4ペイロード)を使用して、GREカプセル化が追加された後は、パケットが発信物理インターフェイスのMTUより大きくなることはありません。

IP0	1456 バイト TCP + データ

IP1	24 バイト データ

 3.転送ルータは、元のIPv4データグラムの各フラグメントに、4バイトのGREヘッダーと20バイトのIPv4ヘッダーを含むGREカプセル化を追加します。これにより、これら 2 つの IPv4 データグラムは 1500 バイトおよび 68 バイトの長さとなります。これらのデータグラムはフラグメントとしてではなく、個々の IPv4 データグラムとして認識されます。

IPv4

GRE

IP0

1456 バイト TCP + データ

IPv4

GRE

IP1

24 バイト データ

4.トンネル宛先ルータは、元のデータグラムの各フラグメントからGREカプセル化を削除し、長さが1476バイトと24バイトの2つのIPv4フラグメントを残します。これらの IPv4 データグラム フラグメントは、このルータによって受信側のホストに別々に転送されます。

IP0	1456 バイト TCP + データ

IP1	24 バイト データ

5.受信側ホストは、これら2つのフラグメントを元のデータグラムに再構成します。

IPv4	1480 バイト TCP + データ

シナリオ 5 では、ネットワーク トポロジの観点での転送ルータの役割を図示します。

この例では、ルータは転送ルータと同じ役割を果たしますが、この場合は DF ビットが設定されています（DF = 1）。

例 2

1.トンネル送信元の転送ルータは、送信側ホストから1500バイトのデータグラム(DF = 1)を受信します。

IPv4	1480 バイト TCP + データ

2. DFビットが設定され、データグラムサイズ（1500バイト）がGREトンネルIPv4 MTU(1476)より大きいため、ルータはデータグラムを廃棄し、「ICMP fragmentation needed but DF bit set」メッセージをデータグラムの送信元に送信します。ICMP メッセージによって、MTU が 1476 であることが送信側に警告されます。

IPv4	ICMP MTU 1476

3.送信側ホストはICMPメッセージを受信し、元のデータを再送信する際に1476バイトのIPv4データグラムを使用します。

IPv4	1456 バイト TCP + データ

4.このIPv4データグラムの長さ（1476バイト）は、GREトンネルのIPv4 MTUと同じ値になるため、ルータはGREカプセル化をIPv4データグラムに追加します。

IPv4

GRE

IPv4

1456 バイト TCP + データ

5.受信側ルータ（トンネルの宛先）は、IPv4データグラムのGREカプセル化を削除し、受信側ホストに送信します。

IPv4	1456 バイト TCP + データ

次に、PMTUD およびトンネル IPv4 パケットに関して、ルータが送信側ホストとして 2 番目の役割を果たしている場合の状況を説明します。この役割は、ルータがトンネル パケット内に元の IPv4 パケットをカプセル化した後で実行されることを思い出してください。

注：デフォルトでは、 ルータは生成する GRE トンネル パケットに対して PMTUD を実行しません。tunnel path-mtu-discovery コマンドを使用して、GRE-IPv4 トンネル パケットに対して PMTUD を有効にできます。

例 3 では、GRE トンネル インターフェイス上の IPv4 MTU に収まるほど小さい IPv4 データグラムをホストが送信している場合の状況を示します。この場合、DF ビットを設定またはクリア（1 または 0）することが可能です。 この GRE トンネル インターフェイスでは tunnel path-mtu-discovery コマンドが設定されていないので、ルータによる GRE-IPv4 パケットへの PMTUD は実行されません。

例 3

1.トンネル送信元の転送ルータが、送信元ホストから1476バイトのデータグラムを受信する。

IPv4	1456 バイト TCP + データ

2.このルータは1476バイトのIPv4データグラムをGRE内にカプセル化し、1500バイトのGRE IPv4データグラムを取得します。GRE IPv4 ヘッダー内の DF ビットはクリアされます（DF = 0）。 次に、このルータはこのパケットをトンネルの宛先に転送します。

IPv4

GRE

IPv4

1456 バイト TCP + データ

3.トンネルの送信元と宛先の間に、リンクMTUが1400のルータがあると仮定します。DF ビットがクリアされている（DF = 0）ので、このルータではトンネル パケットがフラグメント化されます。 この例では、最も外側の IPv4 がフラグメント化されるので、GRE、内側の IPv4、および TCP ヘッダーは最初のフラグメントだけに表示されていることを憶えておいてください。

IP0

GRE

IP

1352 バイト TCP + データ

IP1	104 バイト データ

4.トンネル宛先ルータは、GREトンネルパケットを再構成する必要があります。

IP

GRE

IP

1456 バイト TCP + データ

5. GREトンネルパケットが再構成されると、ルータはGRE IPv4ヘッダーを削除し、途中で元のIPv4データグラムを送信します。

IPv4	1456 バイト TCP + データ

次の例では、PMTUD およびトンネル IPv4 パケットに関して、ルータが送信側ホストの役割を果たしている場合の状況を説明します。この場合、元の IPv4 ヘッダー内で DF ビットがセットされ（DF = 1）、tunnel path-mtu-discovery コマンドが設定されているので、内側の IPv4 ヘッダーから外側の（GRE + IPv4）ヘッダーに DF ビットがコピーされます。

例 4

1.トンネル送信元の転送ルータは、送信側ホストから1476バイトのデータグラム(DF = 1)を受信します。

IPv4	1456 バイト TCP + データ

2.このルータは1476バイトのIPv4データグラムをGRE内にカプセル化し、1500バイトのGRE IPv4データグラムを取得します。元の IPv4 データグラムの DF ビットが設定されているため、この GRE IPv4 ヘッダーでは DF ビットが設定されます（DF = 1）。次に、このルータはこのパケットをトンネルの宛先に転送します。

IPv4

GRE

IPv4

1456 バイト TCP

3.ここでも、トンネルの送信元と宛先の間に、リンクMTUが1400のルータがあると仮定します。DF ビットが設定されている（DF = 1）ので、このルータではトンネル パケットのフラグメント化が行われません。 このルータはパケットをドロップし、ICMP エラー メッセージをトンネル送信元ルータに送信する必要があります。この理由は、これがパケット上の送信元 IPv4 アドレスであるからです。

IPv4	ICMP MTU 1400

4.トンネル送信元の転送ルータは、この「ICMP」エラーメッセージを受信し、GREトンネルのIPv4 MTUを1376(1400 ～ 24)に下げます。 送信側ホストが次にデータを 1476 バイトの IPv4 パケットで再送信すると、このパケットは大きすぎることになるため、このルータは 1376 の MTU 値を付けて ICMP エラー メッセージを送信者に送ります。送信側ホストがデータを再送信する際には、1376 バイトの IPv4 パケットで送信し、このパケットは GRE トンネルを介して受信側ホストに到着します。

シナリオ 5

このシナリオでは、GRE フラグメンテーションを解説します。GRE のカプセル化の前にフラグメント化し、次にデータ パケットの PMTUD を実行することと、IPv4 パケットが GRE によってカプセル化される場合には、DF ビットがコピーされないことを憶えておいてください。このシナリオでは、DF ビットは設定されていません。GRE トンネル インターフェイスの IPv4 MTU は、デフォルトでは物理インターフェイスの IPv4 MTU より 24 バイト少ないので、図のように、GRE インターフェイスの IPv4 MTU は 1476 となります。

1. 送信者は 1500 バイトのパケット（20 バイト IPv4 ヘッダー + 1480 バイトの TCP ペイロード）を送信します。
2. GRE トンネルの MTU は 1476 なので、1500 バイトのパケットは 1476 バイトと 44 バイトの 2 つの IP フラグメントに分割されます。それぞれの IPv4 フラグメントには、24 バイトの GRE ヘッダーが付加されることを見込んでいます。
3. 24 バイトの GRE ヘッダーが各 IPv4 フラグメントに付加されます。したがって、フラグメントはそれぞれ 1500 バイト（1476 + 24）および 68 バイト（44 + 24）になります。
4. 2 つの IPv4 フラグメントを含む GRE + IPv4 パケットが、GRE トンネル ピア ルータに転送されます。
5. GRE トンネル ピア ルータが、2 つのパケットから GRE ヘッダーを削除します。
6. このルータは、2 つのパケットを宛先ホストに転送します。
7. 宛先ホストは、この IPv4 フラグメントを元の データグラムに再構成します。

シナリオ 6

このシナリオはシナリオ 5 に類似していますが、今回は DF ビットが設定されています。シナリオ 6 では、ルータは GRE + IPv4 トンネル パケットに PMTUD を実行するように、tunnel path-mtu-discovery コマンドで設定されています。また、DF ビットは元の IPv4 ヘッダーから GRE IPv4 ヘッダーにコピーされます。ルータでは、GRE + IPv4 パケットの ICMP エラーを受信すると、GRE トンネル インターフェイス上の IPv4 MTU を低下させます。再度、デフォルトでは GRE トンネル IPv4 MTU が物理インターフェイス MTU より 24 バイト少なく設定されているので、GRE IPv4 MTU が 1476 であることを思い出してください。さらに、図に示すように、GRE トンネル パス内に 1400 の MTU リンクが存在することにも注意してください。

1. ルータは、1500 バイトのパケット（20 バイトの IPv4 ヘッダー + 1480 バイトの TCP ペイロード）を受信し、このパケットをドロップします。ルータがこのパケットをドロップする理由は、これが GRE トンネル インターフェイス上の IPv4 MTU（1476）よりも大きいためです。
2. ルータは、ネクスト ホップの MTU が 1476 であることを通知する ICMP エラーを送信側に送ります。ホストは、通常は、その宛先のホスト ルートとして、この情報をルーティング テーブル内に記録します。
3. 送信側ホストは、データを再送信する際に 1476 バイトのパケット サイズを使用します。GRE ルータでは、24 バイトの GRE カプセル化付加分を追加し、1500 バイトのパケットを送り出します。
4. 1500 バイトのパケットは 1400 バイトのリンクを通過できないので、中継ルータによって廃棄されます。
5. 中継ルータは、1400 のネクスト ホップ MTU 値を付けて、ICMP（タイプ 3、コード 4）を GRE ルータに送信します。GRE ルータでは、これを 1376（1400 - 24）に低下させて、GRE インターフェイスでの内部 IPv4 MTU 値を設定します。この変更は、debug tunnel コマンドを使用するときのみ確認できます。これは show ip interface tunnel<#> コマンドの出力では確認できません。
6. ホストが次に 1476 バイトのパケットを再送信する場合、このパケットは GRE トンネル インターフェイスの現在の IPv4 MTU（1376）より大きいので、GRE ルータはこれをドロップします。
7. GRE ルータは、1376 のネクスト ホップ MTU 値を付けて、別の ICMP（タイプ 3、コード 4）を送信側に送り、ホストでは新しい値で現在の情報を更新します。
8. ホストは再度データを再送信しますが、今回はより小さい 1376 バイトのパケットで送信します。GRE はカプセル化の 24 バイトを追加し、これを転送します。今回は、パケットは GRE トンネル ピアに到着し、ここでカプセル化解除され、宛先ホストに送信されます。

注：このシナリオにおいて、転送ルータ上で tunnel path-mtu-discovery コマンドが設定されておらず、さらに GRE トンネルを介して転送されたパケット内で DF ビットが設定されている場合、Host 1 は TCP/IPv4 パケットを Host 2 に送信できますが、これらのパケットは途中、1400 MTU リンクでフラグメント化されます。さらに、GRE トンネル ピアでは、これらをカプセル化解除して転送する前に、再構成する必要があります。

純粋な IPsec トンネルモード

IPv4 セキュリティ（IPv4sec）プロトコルは、IPv4 ネットワークを介して転送される情報にプライバシ、整合性、および信憑性を提供する、標準ベースのメソッドです。IPv4sec では、IPv4 ネットワーク層での暗号化が提供されます。IPv4sec では、少なくとも 1 つの IPv4 ヘッダー（トンネル モード）が追加されるので、IPv4 パケットが長くなります。 追加されるヘッダーの長さはIPv4sec設定モードによって異なりますが、パケットごとに最大58バイト(Encapsulating Security Payload(ESP)およびESP authentication(ESPauth))を超えることはできません。

IPv4sec には、トンネル モードおよびトランスポート モードの 2 つのモードがあります。

1. トンネル モードがデフォルトのモードです。トンネル モードでは、元の IPv4 パケットはすべて保護され（暗号化、認証、またはその両方）、IPv4sec のヘッダーとトレーラでカプセル化されます。次に、新規の IPv4 ヘッダーがパケットの先頭に付加されて、送信元および宛先に IPv4sec エンドポイント（ピア）が指定されます。トンネル モードは任意のユニキャスト IPv4 トラフィックで使用でき、IPv4sec がホストからのトラフィックを IPv4sec ピアの後方で保護している場合に使用する必要があります。たとえば、トンネル モードはバーチャル プライベート ネットワーク（VPN）で使用されます。この場合、保護されたあるネットワーク上のホストが保護された別のネットワーク上のホストにパケットを送信するのに、一対の IPv4sec ピアが経由されます。VPN では、IPv4sec「トンネル」は IPv4sec ピア ルータ間のこのトラフィックを暗号化することにより、ホスト間の IPv4 トラフィックを保護します。
2. （トランスフォーム定義で、サブコマンド mode transport で設定される）トランスポート モードでは、元の IPv4 パケットのペイロードだけが保護（暗号化、認証、またはその両方）されます。 ペイロードは、IPv4sec のヘッダーとトレーラでカプセル化されます。IPv4 プロトコル フィールドの ESP（50）への変更を除き、元の IPv4 ヘッダーはそのままの状態です。また、元のプロトコル値は、パケットが復号される際の復元のために IPv4sec トレーラに保存されます。トランスポート モードは、IPv4 トラフィックが IPv4sec ピア自体の間で保護される場合にだけ使用され、パケット上の送信元および宛先の IPv4 アドレスは、IPv4sec ピア アドレスと同じになります。IPv4sec トランスポート モードが使用されるのは、通常、最初の IPv4 データ パケットをカプセル化に別のトンネリング プロトコル（GRE など）が使用され、次に IPv4sec により GRE トンネル パケットを保護するような場合だけです。

IPv4sec では常に、データ パケットおよび IPsec 自体のパケットのために PMTUD が実行されます。IPv4sec IPv4 パケットの PMTUD 処理を変更するために、IPv4sec 設定コマンドがあります。IPv4sec では DF ビットに関して、クリア、設定、またはデータ パケットの IPv4 ヘッダーから IPv4sec の IPv4 ヘッダーへのコピーが可能です。これは「DF ビット上書き機能」と呼ばれます。

注：IPv4sec でハードウェアでの暗号化を行う場合、カプセル化の後のフラグメンテーションを必ず回避する必要があります。ハードウェアでの暗号化では、ハードウェアによっては約 50 Mbps のスループットが提供されますが、IPv4sec パケットがフラグメント化される場合、このスループットの 50 ～ 90% が失われます。フラグメント化された IPv4sec パケットが再構成のためにプロセス交換された後、復号のためにハードウェア暗号化エンジンに渡されることがこの損失の原因です。スループットのこの損失によって、ハードウェア暗号化スループットがソフトウェア暗号化のパフォーマンス レベル（2 ～ 10 Mbps）にまで低下する可能性があります。

シナリオ 7

このシナリオでは、実行中の IPv4sec フラグメンテーションを図示します。このシナリオでは、全パスでの MTU は 1500 です。このシナリオでは、DF ビットは設定されていません。

1. ルータは、Host 2 を宛先とした 1500 バイトのパケット（20 バイト IPv4 ヘッダー + 1480 バイトの TCP ペイロード）を受信します。
2. 1500 バイトのパケットが IPv4sec によって暗号化され、52 バイトのオーバーヘッド（IPv4sec ヘッダー、トレーラ、および追加の IPv4 ヘッダー）が追加されます。 これにより、IPv4sec は 1552 バイトのパケットを送信する必要があります。送信 MTU が 1500 なので、このパケットをフラグメント化する必要があります。
3. この IPv4sec パケットから 2 つのフラグメントが作成されます。フラグメンテーション中、2 番目のフラグメントに対してさらに 20 バイトの IPv4 ヘッダーが追加され、結果として 1500 バイトのフラグメントと 72 バイトの IPv4 フラグメントになります。
4. IPv4sec トンネル ピア ルータはこれらのフラグメントを受信し、追加の IPv4 ヘッダーを取り除き、さらに、これらの IPv4 フラグメントを結合して元の IPv4sec パケットに戻します。次に、IPv4sec によってこのパケットが復号されます。
5. ルータは次に、元の 1500 バイトのデータ パケットを Host 2 に転送します。

シナリオ 8

このシナリオはシナリオ 6 に類似しています。ただし、この場合は元のデータ パケットに DF ビットが設定されており、IPv4sec トンネル ピア間のパスにその他のリンクより低い MTU を持つリンクが存在する点が異なります。このシナリオでは、「トンネルのエンドポイントにおいて PMTUD に関与するルータ」のセクションで説明したような、両方の PMTUD の役割を果たす IPv4sec ピア ルータの動作を説明します。

このシナリオでは、フラグメンテーションに必要となる、IPv4sec PMTU の低い値への変更の状況を示します。IPv4sec がパケットを暗号化する時に、DF ビットが内側の IPv4 ヘッダーから外側の IPv4 ヘッダーにコピーされることに注意してください。メディア MTU および PMTU の値は、IPv4sec Security Association（SA; セキュリティ結合）内に格納されます。 メディア MTU は、アウトバウンド ルータ インターフェイスの MTU に基づいています。また、PMTU は、IPv4sec ピア間のパスで発生する最小 MTU に基づいています。図に示すように、IPv4sec では、フラグメント化の前に、パケットがカプセル化/暗号化されることに注意してください。

1. ルータは、1500 バイトのパケットを受信して廃棄します。この理由は、IPv4sec オーバーヘッドが追加される場合、パケットが PMTU（1500）より大きくなるからです。
2. ルータは、ネクスト ホップの MTU が 1442（1500 - 58 = 1442）であることを通知する、ICMP メッセージを Host 1 に送ります。 この 58 バイトとは、IPv4sec ESP および ESPauth を使用する場合の最大 IPv4sec オーバーヘッドです。実際の IPv4sec オーバーヘッドは、この値より最大 7 バイト小さい値となる場合があります。Host 1 は通常、宛先（Host 2）のホスト ルートとして、ルーティング テーブル内にこの情報を記録します。
3. 3.ホスト1はホスト2のPMTUを1442に下げるため、ホスト1はデータをホスト2に再送信すると、より小さい（1442バイト）パケットを送信します。ルータは1442バイトのパケットを受信し、IPv4secパケットは1144444 96バイト。このパケットは、ヘッダー内に DF ビットが設定されているので、MTU リンクが 1400 バイトの中間ルータによって廃棄されます。
4. パケットをドロップするこの中間ルータは、ICMP メッセージを IPv4sec パケットの送信者（1 番目のルータ）に送り、ネクスト ホップの MTU が 1400 バイトであることを伝えます。この値は、IPv4sec SA PMTU 内に記録されます。
5. 次に Host 1 が 1442 バイトのパケットを再送信する（この確認応答は受信していません）と、IPv4sec はパケットをドロップします。ルータはパケットを再度ドロップします。この理由は、IPv4sec オーバーヘッドがパケットに追加される場合、パケットが PMTU（1400）より大きくなるからです。
6. ルータは、ネクスト ホップの MTU が 1342（1400 - 58 = 1342）であることを通知する、ICMP メッセージをHost 1 に送ります。 Host 1 は、この情報を再度記録します。
7. Host 1 がデータを再送信する場合、より小さなサイズのパケット（1342）を使用します。 このパケットはフラグメンテーションを必要とせず、IPv4sec トンネルを介して Host 2 に到達します。

GRE と IPv4sec の使用

GRE トンネルの暗号化に IPv4sec が使用される場合、フラグメンテーションと PMTUD のより複雑なインタラクションが発生します。IPv4sec では IPv4 マルチキャスト パケットがサポートされていないため、IPv4sec と GRE が次の方法で組み合されることになります。これは、IPv4sec VPN ネットワークではダイナミック ルーティング プロトコルを実行できないことを意味します。GRE トンネルはマルチキャストをサポートしているので、まず GRE トンネルを使用して、GRE IPv4 ユニキャスト パケット内のダイナミック ルーティング プロトコル マルチキャスト パケットをカプセル化できます。次に、これを IPv4sec により暗号化できます。これを実行すると、多くの場合、GRE に加えて IPv4sec がトランスポート モードで展開されます。この理由は、IPv4sec ピアと GRE トンネルのエンドポイント（ルータ）は同じものであり、トランスポート モードでは IPv4sec オーバーヘッドの 20 バイトが節約されるからです。

注目すべき状況の 1 つに、IPv4 パケットが 2 つのフラグメントに分割され、GRE によってカプセル化される場合があります。この場合、IPv4sec では 2 つの独立した GRE + IPv4 のパケットに対応することになります。デフォルト設定では、多くの場合、これらのパケットの 1 つは大きいため、暗号化された後でフラグメント化される必要があります。IPv4sec ピアは、復号化の前にこのパケットを再構成する必要があります。送信側ルータでの、この「2 重のフラグメンテーション」（GRE の前に 1 回、IPv4sec の後に 1 回）は、遅延を増大させ、スループットを低下させます。また、再構成はプロセス交換されるので、この状態が発生するたびに受信側ルータ上で CPU ヒットが発生します。

この状況は、GRE と IPv4sec 両方からのオーバーヘッドに対処するほど低く、GRE トンネル インターフェイス上の「ip mtu」を設定することによって回避できます（デフォルトでは、GRE トンネル インターフェイスの「ip mtu」は、実際の送信インターフェイスの MTU である GRE オーバーヘッドのバイトに設定されています）。

次の表では、発信物理インターフェイスの MTU が 1500 であると仮定して、各トンネル/モードの組み合せに推奨される MTU 値を掲載しています。

トンネルの組み合せ	必要な特定の MTU	推奨される MTU
GRE + IPv4sec（トランスポート モード）	1440 バイト	1400 バイト
GRE + IPv4sec（トンネル モード）	1420 バイト	1400 バイト

注：一般的な GRE + IPv4sec モードの組合せの大部分に対応しているため、MTU 値には 1400 が推奨されます。また、追加的な 20 バイトまたは 40 バイトのオーバーヘッドを許可することへの認識できるマイナス面はありません。1 つの値を記憶して設定し、この値を使用してほぼすべてのシナリオに対応するほうが簡単です。

シナリオ 9

IPv4sec が GRE に加えて展開されています。発信物理 MTU は 1500、IPv4sec PMTU は 1500、そして GRE IPv4 MTU は 1476（1500 - 24 = 1476）です。 このため、TCP/IPv4 パケットは 2 回フラグメント化されます。GRE の前に 1 回と IPv4sec の後に 1 回です。パケットは GRE カプセル化の前にフラグメント化され、フラグメント化された GRE パケットの 1 つが IPv4sec 暗号化の後で再度フラグメント化されます。

GRE トンネル上で「ip mtu 1440」（IPv4sec トランスポート モード）または「ip mtu 1420」（IPv4sec トンネル モード）を設定すると、このシナリオでの 2 重のフラグメンテーションの可能性が解消されます。

1. ルータは 1500 バイトのデータグラムを受信します。
2. カプセル化の前に、GRE により、1500 バイトのパケットが 1476 バイト（1500 - 24 = 1476）と 44 バイト（24 データ + 20 IPv4 ヘッダー）の 2 つの断片にフラグメント化されます。
3. GRE では IPv4 フラグメントをカプセル化し、各パケットに 24 バイトが追加されます。この結果として、それぞれ 1500 バイト（1476 + 24 = 1500）および 68 バイト（44 + 24）の、2 つの GRE + IPv4sec パケットとなります。
4. この 2 つのパケットは IPv4sec により暗号化され、カプセル化オーバーヘッドの 52 バイト（IPv4sec トンネル モード）がそれぞれに追加されて、1552 バイトと 120 バイトのパケットが作成されます。
5. 1552 バイトの IPv4sec パケットは送信 MTU（1500）より大きいため、ルータによりフラグメント化されます。 1552 バイトのパケットは、1500 バイトのパケットと 72 バイトのパケットに分割されます（後者のフラグメントには、52 バイトの「ペイロード」に加えて、追加の 20 バイト IPv4 ヘッダーが含まれる）。 1500 バイト、72 バイト、および 120 バイトの 3 つのパケットが、IPv4sec + GRE ピアに転送されます。
6. 受信側ルータでは、2 つの IPv4sec フラグメント（1500 バイトと 72 バイト）が再構成されて、元の 1552 バイトの IPv4sec + GRE パケットが取得されます。120 バイトの IPv4sec + GRE パケットに対しては、必要な処理はありません。
7. IPv4sec で 1552 バイトと 120 バイトの両方の IPv4sec + GRE パケットが復号され、1500 バイトと 68 バイトの GRE パケットが取得されます。
8. GRE では、1500 バイトと 68 バイトの GRE パケットがカプセル化解除され、1476 バイトと 44 バイトの IPv4 パケット フラグメントが取得されます。これらの IPv4 パケット フラグメントが、宛先ホストに転送されます。
9. Host 2 は、これらの IPv4 フラグメントを再構成して、元の 1500 バイトの IPv4 データグラムを取得します。

シナリオ 10 はシナリオ 8 に類似していますが、トンネル パスにより低い MTU リンクが存在している点が異なります。ホスト1からホスト2に送信される最初のパケットの最悪のシナリオです。このシナリオの最後の手順の後、ホスト1はホスト2に正しいPMTUを設定し、ホスト1とホスト2間のTCP接続に問題はありません（IPv4sec + GREトンネルを経由）シナリオ10のステップ

このシナリオでは、tunnel path-mtu-discovery コマンドが GRE トンネルに設定され、Host 1 で生成される TCP/IPv4 パケット上に DF ビットが設定されます。

シナリオ 10

• ルータは、1500 バイトのパケットを受信します。このパケットは GRE によって廃棄されます。この理由は、DF ビットが設定されているので GRE ではパケットのフラグメント化または転送を実行できず、GRE オーバーヘッド（24 バイト）が追加されると、パケット サイズが発信インターフェイスの「ip mtu」を超過するからです。
• ルータは、ネクスト ホップの MTU が 1476（1500 - 24 = 1476）であることを通知するため、ICMP メッセージを Host 1 に送ります。
• Host 1 は Host 2 の PMTU を 1476 に変更し、パケットを再送信する場合に、より小さいサイズで送信します。GRE でこれがカプセル化され、1500 バイトのパケットが IPv4sec に渡されます。IPv4sec はパケットをドロップします。この理由は、GRE によって（設定状態の）DF ビットが内側の IPv4 ヘッダーからコピーされており、IPv4sec オーバーヘッド（最大 38 バイト）を付加したパケットは大きすぎて、物理インターフェイスから転送できないためです。
• IPv4sec は ICMP メッセージを GRE に送信し、ネクスト ホップの MTU が 1462 バイト（暗号化と IPv4 オーバーヘッドに最大 38 バイトが追加されるため）であることを通知します。GRE では、値 1438（1462 - 24）をトンネル インターフェイス上の「ip mtu」として記録します。
• 注：この値の変更は内部的に格納されており、show ip interface tunnel<#> コマンドの出力には表示されません。一方、debug tunnel コマンドを使用すると、この変更が表示されます。
• 次に Host 1 が 1476 バイトのパケットを再送信すると、GRE はそれを廃棄します。
• このルータは、ネクスト ホップの MTU が 1438 であることを通知する ICMP メッセージを Host 1 に送ります。
• Host 1 は Host 2 の PMTU を低下させ、1438 バイトのパケットを再送信します。今回は、GRE はパケットを受け入れてカプセル化し、暗号化のために IPv4sec に渡します。IPv4sec パケットは中継ルータに転送されますが、中継ルータの発信インターフェイス MTU が 1400 なので、ドロップされます。
• 中継ルータは、ネクスト ホップの MTU が 1400 であることを通知する ICMP メッセージを IPv4sec に送信します。この値は、関連する IPv4sec SA の PMTU 値内に IPv4sec により記録されます。
• Host 1 が 1438 バイトのパケットを再送信すると、GRE はこれをカプセル化して IPv4sec に渡します。IPv4sec はその PMTU を 1400 に変更しているので、このパケットをドロップします。
• IPv4sec は ICMP エラーを GRE に送信し、ネクスト ホップの MTU が 1362 であることを通知し、GRE はこの値 1338 を内部に記録します。
• Host 1 が（確認応答を受け取っていないため）元のパケットを再送信すると、GRE はこれを廃棄します。
• ルータは、ネクスト ホップの MTU が 1338（1362 - 24 バイト）であることを通知する ICMP メッセージを Host 1 に送信します。 Host 1 は、Host 2 のための PMTU を 1338 に低下させます。
• Host 1 は、1338 バイトのパケットを再送信し、今回は、このパケットは最終的に Host 2 まで到着できます。

その他の推奨事項

GRE と IPv4sec が同じルータ上に設定されている場合、トンネル インターフェイス上で tunnel path-mtu-discovery コマンドを設定することは、それらのインタラクションに有用です。tunnel path-mtu-discovery コマンドを設定していないと、GRE IPv4 ヘッダー内の DF ビットが常にクリアされることに注意してください。これにより、カプセル化されたデータ IPv4 ヘッダーで DF ビットが設定されていた場合（この場合、通常はパケットのフラグメント化が許可されません）でも、GRE IPv4 パケットのフラグメント化が許可されます。

tunnel path-mtu-discovery コマンドが GRE トンネル インターフェイスで設定されていると、次の状態になります。

1. GRE では、データ IPv4 ヘッダーから GRE IPv4 ヘッダーに、DF ビットをコピーします。
2. GRE IPv4 ヘッダー内で DF ビットが設定されていると、IPv4sec 暗号化後のパケットが物理発信インターフェイスの IPv4 MTU に対して「大きすぎる」場合、IPv4sec はそのパケットをドロップし、GRE トンネルに IPv4 MTU サイズを縮小するように通知します。
3. IPv4sec はそれ自体のパケットに対して PMTUD を実行しますが、IPv4sec PMTU が変更（縮小）されても、これは即座には、IPv4sec から GRE に通知されません。ところが、別の「大きすぎる」パケットが到着すると、ステップ 2 の処理が発生します。
4. この場合、GRE の IPv4 MTU はさらに小さいので、DF ビットが設定された大きすぎるデータ IPv4 パケットをすべて廃棄し、送信側ホストに ICMP メッセージを送信します。

ip mtu コマンドを使用した静的な設定とは異なり、tunnel path-mtu-discovery コマンドは、GRE インターフェイスが IPv4 MTU を動的に設定するのに有効です。実際には、両方のコマンドの使用が推奨されます。ip mtu コマンドは、ローカルの物理発信インターフェイスの IPv4 MTU に関連する、GRE と IPv4sec のオーバーヘッドのためのスペースを確保するのに使用されます。tunnel path-mtu-discovery コマンドでは、IPv4sec ピア間のパスにさらに低い IPv4 MTU のリンクが存在する場合に、GRE トンネルの IPv4 MTU をさらに低下させることができます。

GRE + IPv4sec トンネルが設定されたネットワーク内で、PMTUD に問題が発生する場合に実行可能な対応を、ここに示します。

次のリストでは、最も推奨されるソリューションから掲載しています。

1. PMTUD が機能しない問題を解決します。この問題は通常、ICMP をブロックしているルータまたはファイアウォールが原因です。
2. そのトンネル インターフェイスに ip tcp adjust-mss コマンドを使用して、ルータが TCP SYN パケットの TCP MSS 値を低下させるようにします。これは 2 つのエンドホスト（TCP の送信側および受信側）で、PMTUD が必要とされないくらい小さいパケットを使用する場合に有効です。
3. ルータの入力インターフェイスでポリシー ルーティングを使用し、さらに、ルート マップを設定して、データ IPv4 ヘッダー内の DF ビットが GRE トンネル インターフェイスに到着する前にクリアされるようにします。これにより、データ IPv4 パケットを、GRE カプセル化の前にフラグメント化できるようになります。
4. 発信インターフェイスの MTU と等しくなるように、GRE トンネル インターフェイスの「ip mtu」を増加させます。これにより、フラグメント化を先に実行しないでも、データ IPv4 パケットの GRE でのカプセル化ができるようになります。次に、GRE パケットに対して IPv4sec 暗号化が実行され、物理アウトバウンド インターフェイスから送信するためにフラグメント化されます。この場合、GRE トンネル インターフェイスで tunnel path-mtu-discovery コマンドの設定は行いません。これによりスループットが極端に下がる場合があります。これは、IPv4sec ピアでの IPv4 パケットの再構成がプロセス交換モードで実行されることが原因です。

関連情報

• IP ルーティングに関するサポート ページ
• IPSec（IP セキュリティ プロトコル）に関するサポート ページ
• IPSec オーバーヘッド カルキュレータ（IPSec カプセル化プロトコルでパケット サイズを計算する）
• RFC 1191 Path MTU Discovery
• RFC 1063 IP MTU Discovery オプション
• RFC 791 インターネット プロトコル
• RFC 793 Transmission Control Protocol
• RFC 879 The TCP Maximum Segment Size and Related Topics
• RFC 1701 Generic Routing Encapsulation（GRE）
• RFC 1241 A Scheme for an Internet Encapsulation Protocol
• RFC 2003 IP Encapsulation within IP
• テクニカル サポートとドキュメント – Cisco Systems