MTUサイズが異なるリンクが混在、IPv6 MTU値の設定に注意

 6rdでは、IPv6パケットをIPv4パケットでカプセル化して送ります。そのため、IPv4転送経路がIPv6パケットに適切な状態であるか考慮します。6rd-CEや6rd-BRのIPv4経路表に従ってIPv4カプセル化されたIPv6パケットは、IPv4のネクストホップに向けて転送されます。ここで問題になるのは、IPv4インタフェースのMTU(Maximum Transmission Unit)サイズです。通常、イーサネットのMTUサイズは1500バイトです。しかし6rdの場合はIPv4カプセル化を考慮したIPv6 MTUサイズとする必要があります。IPv4ヘッダーは20バイト(オプションなし)ですから、6rd Virtual-InterfaceのMTUサイズはIPv4インタフェースのMTUサイズから20バイト引いた値を設定しておきます。IPv4インタフェースのMTUサイズが1500バイトだと、IPv6パケットのサイズは1480バイト以下にする必要があります。

 6rd-CE/BRは、カプセル化用IPv4ヘッダーにはDF(Don’t Fragment)ビットをセットします。MTUサイズより大きなIPv6パケットは転送できないので、そのようなIPv6パケットは廃棄したうえでICMPv6のPacket Too BigメッセージをIPv6送信元アドレスに向けて送信します。IPv6では、パケットを転送パス中のルーターがフラグメントすることを許容していません。

 では、同じ6rdドメイン内にある他の6rd-CEや6rd-BRのMTUサイズがばらばらだったらどうすればよいのでしょう?RFC4213では、IPv4 Path MTU Discoveryを使ってあて先IPv4アドレスごとにMTUサイズを調整する方法が書かれています。さらに、ネットワークが転送できるIPv6パケットの最小サイズは1280バイトと定められていますが、IPv4はもっと小さい548バイトです。つまり、1280バイトのIPv6パケットすら転送することができないリンクが存在する可能性があります。もし1300バイト(=1280+20)より小さなPath MTUが存在してしまう場合に、1280バイト以下のIPv6パケットがPath MTUサイズを超えてしまったら、やむを得ずカプセル化するIPv4ヘッダーのDFビットをセットせずパケットを転送します。どこかでフラグメントされてしまいますが、パケットを受信するルーターでデフラグメントされます。

 6rdは、ISPネットワーク内でIPv6サービスを提供することが主目的の技術です。そのため、さすがにここまでMTUサイズのバラエティーに富むネットワーク環境でトンネリングを想定することはありません。ISPネットワーク内のIPv4 MTUサイズにバリエーションがある場合は、その最小サイズから20バイトを引いた値を6rd Virtual-InterfaceのIPv6 MTUサイズにしておきます。ただし、どうしてもどんなMTUサイズのリンクがあるかわからない場合は、1280バイトにしておきます。

 6rdでは、複数の6rd-BRから6rd-CEへパケットを送信することが可能です。このとき、6rd-CEが受信したパケットのフラグメントIDが重複してしまうと、パケットを正しくデフラグメントすることができません。このためRFC5969では、6rd-BRから6rd-CE方向のパケットは必ずDFビットをセットするよう規定しています。これに限らず、6rdドメイン内のISPネットワークの最小MTUサイズが1280バイトのIPv6パケットをカプセル化できるのであれば、実装は別として6rdの運用としては、CEからBR方向もDFビットがセットされたパケットしか流れないはずです。

6rdにおける経路制御のポイント

 6rdを使ってIPv4ネットワーク上に6rdドメインを構築するときは、IPv4とIPv6両方の経路制御を適切に行う必要があります。

・6rd-CE
 6rd-CEのデフォルトルートは、6rd Virtual-Interfaceの論理インタフェースに向けておきます。実装にもよりますが、ネクストホップアドレスとして必ずIPv6アドレスを必要とするものがあります。この場合、6rdBRIPv4Addressから6rdアドレスマッピングルールに従って導出したIPv6アドレスにしておくとよいでしょう。例えば、6rdPrefix/Lengthが2001:db8::/32、IPv4MaskLenが0のとき、6rd-BRIPv4Addressは192.0.2.254だったとすると、6rd-CEに設定されるデフォルトルートのアドレスは2001:db8:c000:02fe::となります。

 不要なパケット転送を防ぐことも重要です(図1)。6rd delegated prefixのうち、6rd-CEのインタフェースや経路表のどこにも設定されていないプレフィックスをあて先とするパケットなど、使用しないプレフィックスに向かうパケットは廃棄されるよう適切に経路表を設定しなければなりません。例えば6rd delegated prefixが2001:db8:abcd:ef00::/56なら、それ自身を表す2001:db8:abcd:ef00::/56は廃棄するように設定しておきます。LAN側インタフェースアドレスなどで使用している/64など、/56よりも長いプレフィックス長の経路を登録しておきます。

図1●6rdにおける経路制御
図1●6rdにおける経路制御
[画像のクリックで拡大表示]

 さらに、カプセル化用あて先IPv4アドレスが使ってはならないアドレス、例えば0.0.0.0/8や127.0.0.0/8、さらにはクラスDやクラスEアドレスなどになるパケットが6rd-CEから外に出て行かないようにします。これらも経路制御であらかじめ設定しておくことが可能ですが、6rd Virtual-Interfaceの処理でも実装していると間違いが起こらずにすみます。

 6rdを使うネットワークを設計したり運用したりする際、いくつか考慮すべきポイントがあります。今回はまずこれらのポイントを解説します。そのあとで、6rdの現状と今後について考察します。