この製品のマニュアルセットは、偏向のない言語を使用するように配慮されています。このマニュアルセットでの偏向のない言語とは、年齢、障害、性別、人種的アイデンティティ、民族的アイデンティティ、性的指向、社会経済的地位、およびインターセクショナリティに基づく差別を意味しない言語として定義されています。製品ソフトウェアのユーザーインターフェイスにハードコードされている言語、RFP のドキュメントに基づいて使用されている言語、または参照されているサードパーティ製品で使用されている言語によりドキュメントに例外が存在する場合があります。シスコのインクルーシブランゲージに対する取り組みの詳細は、こちらをご覧ください。
シスコは世界中のユーザにそれぞれの言語でサポート コンテンツを提供するために、機械と人による翻訳を組み合わせて、本ドキュメントを翻訳しています。 ただし、最高度の機械翻訳であっても、専門家による翻訳のような正確性は確保されません。 シスコは、これら翻訳の正確性について法的責任を負いません。原典である英語版(リンクからアクセス可能)もあわせて参照することを推奨します。
このドキュメントでは、IPv4 フラグメンテーションおよび Path Maximum Transmission Unit Discovery(PMTUD; パス最大転送ユニット ディスカバリ)の仕組みを示し、IPv4 トンネルの異なる組み合わせとともに使用される場合の PMTUD の動作に関連するシナリオについて説明します。インターネットで現在広く普及した IPv4 トンネルの利用により、IPv4 フラグメンテーションおよび PMTUD に関連する問題が顕在化しています。
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 データグラムのフラグメント化は、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 の情報に基づいてパケットが操作されます。パケットが複数のフラグメントにわたる場合、このデバイスでのポリシーの実行が失敗することがあります。
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に接続します。
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 が考慮され、これがどのようにフラグメンテーションの回避に役立つのかに注意してください。
1460 が両方のホストによって、それぞれの送信 MSS として選択された値になります。多くの場合、送信 MSS の値は TCP 接続の両側で同じ値になります。
シナリオ 2 では、TCP 接続のエンドポイントにおいてフラグメンテーションは発生しません。この理由は、両方の送信インターフェイス MTU がホストにより考慮されているからです。ただし、いずれかのホストの送信インターフェイスの MTU より低い MTU を含むリンクがあると、ルータ A とルータ B の間のネットワーク内でパケットがフラグメント化される可能性があります。
前述したように、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 のリンクを介した伝送ではフラグメンテーションが必要ではないからです。
シナリオ 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 ではパケットをフラグメント化する必要がないからです。
注:ルータ(たとえば、BGP および Telnet)によって開始された TCP 接続のための TCP MTU パス ディスカバリを有効にするためには、ip tcp path-mtu-discovery コマンドが使用されます。
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 は、中継リンクの MTU がエンド リンクの MTU より小さいようなネットワーク状況において必要となります。これらのより小さな MTU リンクが存在する一般的な理由としては、次のものがあります。
トークン リング(または FDDI)に接続されたエンド ホストで、中間にイーサネット接続がある場合。これらの両端でのトークン リング(または FDDI)MTU は、中間にあるイーサネット MTU より大きくなります。
(ADSL でよく使用される)PPPoE では、そのヘッダーに 8 バイトが必要です。これにより、イーサネットでの有効 MTU が 1492(1500 - 8)に低下します。
GRE、IPv4sec、および L2TP などのトンネリング プロトコルでも、それぞれのヘッダーとトレーラのための領域が必要です。これもまた、発信インターフェイスの有効 MTU を低下させます。
次のセクションでは、2つのエンドホスト間のどこかでトンネリングプロトコルが使用されるPMTUDの影響について説明します。前述の 3 つの状況では、この状況が最も複雑であり、他の状況で発生するすべての問題も含まれます。
トンネルとは、トランスポート プロトコル内で、パッセンジャ パケットをカプセル化する方法を提供する、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
トンネルのエンドポイントとなっているルータには 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 トンネルを介して受信側ホストに到着します。
このシナリオでは、GRE フラグメンテーションを解説します。GRE のカプセル化の前にフラグメント化し、次にデータ パケットの PMTUD を実行することと、IPv4 パケットが GRE によってカプセル化される場合には、DF ビットがコピーされないことを憶えておいてください。このシナリオでは、DF ビットは設定されていません。GRE トンネル インターフェイスの IPv4 MTU は、デフォルトでは物理インターフェイスの IPv4 MTU より 24 バイト少ないので、図のように、GRE インターフェイスの IPv4 MTU は 1476 となります。
このシナリオはシナリオ 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 リンクが存在することにも注意してください。
注:このシナリオにおいて、転送ルータ上で tunnel path-mtu-discovery コマンドが設定されておらず、さらに GRE トンネルを介して転送されたパケット内で DF ビットが設定されている場合、Host 1 は TCP/IPv4 パケットを Host 2 に送信できますが、これらのパケットは途中、1400 MTU リンクでフラグメント化されます。さらに、GRE トンネル ピアでは、これらをカプセル化解除して転送する前に、再構成する必要があります。
IPv4 セキュリティ(IPv4sec)プロトコルは、IPv4 ネットワークを介して転送される情報にプライバシ、整合性、および信憑性を提供する、標準ベースのメソッドです。IPv4sec では、IPv4 ネットワーク層での暗号化が提供されます。IPv4sec では、少なくとも 1 つの IPv4 ヘッダー(トンネル モード)が追加されるので、IPv4 パケットが長くなります。 追加されるヘッダーの長さはIPv4sec設定モードによって異なりますが、パケットごとに最大58バイト(Encapsulating Security Payload(ESP)およびESP authentication(ESPauth))を超えることはできません。
IPv4sec には、トンネル モードおよびトランスポート モードの 2 つのモードがあります。
IPv4sec では常に、データ パケットおよび IPsec 自体のパケットのために PMTUD が実行されます。IPv4sec IPv4 パケットの PMTUD 処理を変更するために、IPv4sec 設定コマンドがあります。IPv4sec では DF ビットに関して、クリア、設定、またはデータ パケットの IPv4 ヘッダーから IPv4sec の IPv4 ヘッダーへのコピーが可能です。これは「DF ビット上書き機能」と呼ばれます。
注:IPv4sec でハードウェアでの暗号化を行う場合、カプセル化の後のフラグメンテーションを必ず回避する必要があります。ハードウェアでの暗号化では、ハードウェアによっては約 50 Mbps のスループットが提供されますが、IPv4sec パケットがフラグメント化される場合、このスループットの 50 ~ 90% が失われます。フラグメント化された IPv4sec パケットが再構成のためにプロセス交換された後、復号のためにハードウェア暗号化エンジンに渡されることがこの損失の原因です。スループットのこの損失によって、ハードウェア暗号化スループットがソフトウェア暗号化のパフォーマンス レベル(2 ~ 10 Mbps)にまで低下する可能性があります。
このシナリオでは、実行中の IPv4sec フラグメンテーションを図示します。このシナリオでは、全パスでの MTU は 1500 です。このシナリオでは、DF ビットは設定されていません。
このシナリオはシナリオ 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 では、フラグメント化の前に、パケットがカプセル化/暗号化されることに注意してください。
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 つの値を記憶して設定し、この値を使用してほぼすべてのシナリオに対応するほうが簡単です。
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 重のフラグメンテーションの可能性が解消されます。
シナリオ 10 はシナリオ 8 に類似していますが、トンネル パスにより低い MTU リンクが存在している点が異なります。ホスト1からホスト2に送信される最初のパケットの最悪のシナリオです。このシナリオの最後の手順の後、ホスト1はホスト2に正しいPMTUを設定し、ホスト1とホスト2間のTCP接続に問題はありません(IPv4sec + GREトンネルを経由)シナリオ10のステップ
このシナリオでは、tunnel path-mtu-discovery コマンドが GRE トンネルに設定され、Host 1 で生成される TCP/IPv4 パケット上に DF ビットが設定されます。
GRE と IPv4sec が同じルータ上に設定されている場合、トンネル インターフェイス上で tunnel path-mtu-discovery コマンドを設定することは、それらのインタラクションに有用です。tunnel path-mtu-discovery コマンドを設定していないと、GRE IPv4 ヘッダー内の DF ビットが常にクリアされることに注意してください。これにより、カプセル化されたデータ IPv4 ヘッダーで DF ビットが設定されていた場合(この場合、通常はパケットのフラグメント化が許可されません)でも、GRE IPv4 パケットのフラグメント化が許可されます。
tunnel path-mtu-discovery コマンドが GRE トンネル インターフェイスで設定されていると、次の状態になります。
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 に問題が発生する場合に実行可能な対応を、ここに示します。
次のリストでは、最も推奨されるソリューションから掲載しています。