IPv6 を配備するときの一般的な問題

この節では、サイトに IPv6 を計画および配備しているときに遭遇する可能性のある一般的な問題について説明します。実際の計画作業については、第 4 章IPv6 ネットワークの計画 (手順)を参照してください。

IPv4 ルーターを IPv6 用にアップグレードできない

既存の装置をアップグレードできない場合、IPv6 に対応した装置を購入するしかない場合もあります。装置に付属するマニュアルを参照して、IPv6 をサポートするために行う必要がある、装置固有の手順があるかどうかを調べてください。

IPv6 サポート用にアップグレードできない IPv4 ルーターもあります。この状況が自分のトポロジに適応する場合、IPv6 ルーターが IPv4 ルーターの隣にくるように物理的に配線します。このようにすれば、IPv6 ルーターから IPv4 ルーター経由でトンネルできます。トンネルを構成する手順については、「IPv6 サポート用にトンネルを構成するための作業 (作業マップ)」を参照してください。

サービスを IPv6 用にアップグレードしたあとの問題

サービスを IPv6 サポート用に準備しているとき、次のような状況に遭遇する場合があります。

• あるアプリケーションを IPv6 用に移植したのに、IPv6 サポートがデフォルトで有効にならない場合。このようなアプリケーションは、IPv6 が有効になるように構成する必要があります。

• 複数のサービスを実行するサーバーにおいて、IPv4 専用のサービスと IPv4 と IPv6 両用のサービスが混在している場合、次のような状況に遭遇します。クライアントがこれら両方の種類のサービスを使用する必要がある場合、サーバー側で混乱が生じます。

現在の ISP が IPv6 をサポートしない

IPv6 を配備したいが、現在の ISP が IPv6 アドレス指定を提供しない場合、ISP を変更するのではなく、次の代替方法を考えてみてください。

• 別の ISP から IPv6 通信用に 2 番目の回線 ISP を購入します。この解決方法には、高い費用がかかります。

• 「仮想 ISP」を取得します。仮想 ISP はサイトに IPv6 接続を提供しますが、実際の回線は提供しません。その代わりに、サイトから IPv4 ISP 経由で仮想 ISP に到達するトンネルを作成します。

• 自分のサイトから ISP 経由でほかの IPv6 サイトに到達する 6to4 トンネルを使用します。あるアドレスに対して、6to4 ルーターの登録済み IPv4 アドレスを、IPv6 アドレスの公開トポロジ部分として使用します。

6to4 リレールーターへのトンネルを作成するときのセキュリティー問題

本来、6to4 ルーターと 6to4 リレールーター間のトンネルは安全ではありません。これらのルーター間のトンネルには、次のようなセキュリティー問題が内在しています。

• 6to4 リレールーターはパケットのカプセル化とカプセル化の解除を行いますが、パケット内に含まれるデータのチェックは行いません。

• アドレスのスプーフィングは、6to4 リレールーターとの間で構築されるトンネルにおける際立った問題です。着信トラックについては、6to4 ルーターはリレールーターの IPv4 アドレスを送信元の IPv6 アドレスと対応させることができないという問題があります。このため、IPv6 ホストのアドレスは簡単にスプーフィングされかねません。6to4 リレールーターのアドレスもスプーフィングの可能性があります。

• デフォルトの設定では、6to4 ルーターと 6to4 リレールーター間に信頼できるメカニズムは存在しません。したがって、6to4 ルーターは 6to4 リレールーターが信頼できるものであるかどうかを識別できず、正規の 6to4 リレールーターであるかすら確認できません。このようなことから、6to4 サイトと宛先の IPv6 サイト間に信頼関係が存在していることか、あるいは攻撃を受けるという可能性を両サイトとも受け入れることが求められます。

これらの問題を始めとする 6to4 リレールーターのセキュリティー問題については、Internet Draft『Security Considerations for 6to4』で説明されています。一般には、6to4 リレールーターのサポートは次のような場合だけ検討してください。

• 信頼できるプライベートな IPv6 ネットワークとの間で 6to4 サイトが通信を行う場合。たとえば、独立した 6to4 サイトとネイティブ IPv6 サイトから構成されるキャンパスネットワーク上などでこのサポートを有効にすると便利かもしれません。

• ビジネス上の理由で、6to4 サイトと特定のネイティブ IPv6 ホストとの通信を避けることができない場合。

• Internet Draft『Security Considerations for 6to4』で提唱されている検査と信頼できるモデルを導入した場合。

6to4 ルーターの既知の問題

6to4 構成には、次の問題が影響することが判明しています。

• 4709338 – 静的なルートを認識する RIPng 実装が必要である

• 4152864 – 同じ tsrc と tdst のペアによる 2 つのトンネルの設定

6to4 サイトにおける静的なルートの実装 (バグ ID 4709338)

6to4 境界ルーターが設置された 6to4 サイトでは、次の問題が発生します。6to4 擬似インタフェースを設定する場合に 6to4 ルーターの経路制御テーブルに静的ルート 2002::/16 が自動的に追加されます。バグ 4709338 は、この静的ルートが 6to4 サイトに通知されることを防ぐ Oracle Solaris RIPng 経路制御プロトコルにおける制限について説明しています。

バグ 4709338 に対しては、次に示す回避策のどちらかを適用できます。

• 6to4 サイト内にあるすべてのサイト間ルーターの経路制御テーブルに、2002::/16 静的ルートを追加します。

• 6to4 サイトの内部ルーターに RIPng 以外の経路制御プロトコルを使用します。

同じ発信元アドレスによるトンネルの設定 (バグ ID 4152864)

バグ ID 4152864 は、同じトンネル発信元アドレスを使用して 2 つのトンネルが設定される場合に発生する問題について説明しています。これは、6to4 トンネルの重大な問題です。

同じトンネル発信元アドレスを使用して 6to4 トンネルと自動トンネル ( atun) を設定することは避けてください。自動トンネルと atun コマンドについては、tun(7M) のマニュアルページを参照してください。