第 4 章 IPv4 から IPv6 への移行 (リファレンス)

ホストとルーターを IPv6 にアップグレードする場合は、IPv4 ホストおよび IPv4 ルーターとの間で相互運用が可能なようにこれらのノードを設定する必要があります。 この章では、IPv4 から IPv6 へ移行するための標準的な方法について説明します。RFC 1933 でも、移行問題の詳しい解決法を示しています。

この章では、以下の内容について説明します。

• 移行条件

• 標準移行ツール

• IPv4 と IPv6 の相互運用性

• サイト移行のシナリオ

• 移行機構としての 6to4

• その他の移行機構

移行条件

移行時のグローバルな調整は不要です。サイトとインターネットサービスプロバイダ (ISP) はそれぞれのスケジュールで移行できます。また、移行時の依存条件も最小限に抑えました。たとえば、ホストのアップグレード前にルーターを IPv6 にアップグレードしなくても移行できます。

サイトが異なれば、移行時にはそれぞれの制約が課されます。また、IPv6 の初期アダプタには、IPv6 の製品版ユーザーの場合とは異なる問題があります。RFC 1933 は現在利用できる移行ツールを定義しています。移行の必然性としては、IPv4 アドレス領域の不足または IPv6 の新機能を使用する必要性のどちらか、または両方が考えられます。IPv6 仕様では、移行時には、既存のプロトコルの完全な互換性が求められます。 また既存のアプリケーションとの互換性も求められます。

移行方式を理解できるように、次の用語を定義します。

• IPv4 専用ノード – IPv4 だけを実装したホストやルーター。IPv4 専用ノードでは IPv6 は認識できない。移行以前に既存の IPv4 ホストとルーターのインストール可能ベースは IPv4 専用ノード

• IPv6/IPv4 ノード – IPv4 と IPv6 の両方を実装するホストとルーター。デュアルスタックとも呼ぶ

• IPv6 専用ノード – IPv6 を実装するホストまたはルーター。IPv4 を実装しない

• IPv6 ノード – IPv6 を実装するホストまたはルーター。IPv6/IPv4 ノードと IPv6 専用ノードは、どちらも IPv6 ノード

• IPv4 ノード – IPv4 を実装するホストまたはルーター。IPv6/IPv4 ノードと IPv4 専用ノードは、どちらも IPv6 ノード

• 6to4 ルーター – IPv4 ネットワーク接続上で 6to4 擬似インタフェースを使用して設定された任意の境界ルーター。6to4 ルーターは、ルーターがほかの IPv6 サイトへパケットを転送するために使用する 6to4 トンネルのエンドポイントとして機能する

• 6to4 ホスト – 6to4 派生アドレスを使用して設定されたインタフェースを持つ任意の IPv6 ホスト

• サイト – インターネットのプライベートトポロジの 1 つ。すなわちあらゆるユーザーを対象としたトラフィック伝送を行わないトポロジ。サイトが物理的に広範囲に展開されることがある。たとえば、多国籍企業のプライベートネットワークは、1 つのサイト

標準移行ツール

RFC 1933 は、次の移行方式を定義しています。

• ホストとルーターを IPv6 にアップグレードするとき、それらの IPv4 の機能を残す。したがって、すべての IPv4 プロトコルおよびアプリケーションとの互換性が確保される。このようなホストおよびルーターをデュアルスタックと呼ぶ

• IPv6 対応ノードに関する情報は、DNS などのネームサービスを利用して伝送する

• IPv6 アドレス形式には、IPv4 アドレスを保存する

• IPv4 パケットで IPv6 パケットをトンネル処理して、IPv6 にアップグレードされていないルーターを通過できる

デュアルスタックの実装

デュアルスタックとは、アプリケーションからネットワーク層に至るプロトコルスタックのすべてのレベルの完全な複製をいいます。デュアルスタックの例として、同じマシンで実行する OSI プロトコルと TCP/IP プロトコルがあります。ただし、 IPv6 移行の観点からは、プロトコルスタックに IPv4 と IPv6 の両方を組み込むことを表します。残りスタックは同一となります。この場合、同じ伝送プロトコル (TCP、UDPなど) が IPv4 と IPv6 の両方で実行します。また、同じアプリケーションも IPv4 と IPv6 の両方で実行します。

次の図は、OSI 層全体にわたるデュアルスタックプロトコルを表します。

図 4–1 デュアルスタックプロトコル

デュアルスタック方式では、ホストとルーター両方のサブセットをアップグレードして、IPv4 に加えて IPv6 をサポートします。この方法では、アップグレードされた後のノードからも IPv4 で常に IPv4 専用ノードと相互運用できます。

ネームサービスの設定

デュアルノードでは、ピアが IPv6 と IPv4 のどちらをサポートしているか明確でないと、伝送時にどちらの IP バージョンを使用するのかが決まりません。そこで、ネームサービスでどんな情報を伝達するかを制御すると、デュアルノードで使用する IP バージョンを決定できます。さらに、ネームサービスで IPv4 ノードの IP アドレスと IPv6 ノードの IP アドレスを定義します。それによって、デュアルノードでは、両方のアドレスをネームサービスで使用できます。

IPv6 アドレスをネームサービスに指定した場合も、IPv6 でノードにアクセスできます。ただし、ノードにアクセスできるのは、ネームサービスから情報を得たノードだけです。たとえば、NIS に IPv6 アドレスを指定すると、その IPv6 ホストは IPv6 からアクセスできます。ただし、IPv6 ホストにアクセスできるのは、NIS ドメインに所属する IPv6 とデュアルノードだけです。 グローバル DNS に IPv6 アドレスを指定するには、そのノードがインターネット IPv6 バックボーンからアクセスできることが条件です。これは、IPv4 の場合も同様です。たとえば、メール配信の操作は、IPv4 でアクセスできるノードの IPv4 アドレスがあるかどうかに依存します。 これは、HTTP プロキシの操作の場合も同様です。 たとえば、ファイアウォールなどの理由で IPv4 でアクセスできない場合、ネームサービスは内部ファイアウォールと 外部ファイアウォールのデータベースに分けます。 これにより、IPv4 アドレスがアクセスできる範囲だけで認識できるようになります。

ネームサービスのアクセスに使用するプロトコルは、ネームサービスで検索できるアドレスタイプに依存しません。このネームサービスサポートとデュアルスタックでは、デュアルノードが IPv4 専用ノードと通信するときに、IPv4 を使用できます。 さらに、 IPv6 ノードと通信するときに、このネームサービスでは IPv6 を使用することができます。 ただし、宛先までの IPv6 ルートが必要です。

IPv4 互換アドレスフォーマットの使用

通常 32 ビット IPv4 アドレスは、128 ビット IPv6 アドレスで表現できます。移行機能では、次の 2 つの形式を定義しています。

• IPv4 互換アドレス

  000 ... 000

  IPv4 アドレス

• IPv4 マップアドレス

  000 ... 000

  0xffff

  IPv4 アドレス

IPv6 ノードは互換フォーマットで表現します。このフォーマットでは、実際の IPv6 アドレスがなくても IPv6 ノードを使用できます。また、IPv4 専用ルーターで自動トンネルを使用できるため、このアドレスフォーマットではさまざまな IPv6 設定の試用が可能です。ただし、IPv6 ステートレスアドレス自動設定機構では、このアドレスは設定できません。IPv6 ステートレスアドレス自動設定機構には、DHCPv4 など既存の IPv4 機構や静的設定ファイルが必要なためです。

マップアドレスフォーマットでは、IPv4 ノードを表現します。現在ソケット API の一部でだけ、このアドレスフォーマットの使用方法が定義されています。アプリケーションでは、IPv6 アドレスと IPv4 アドレスの両方に共通のアドレスフォーマットを使用できます。 共通のアドレスフォーマットは、IPv4 アド レスを 128 ビットマップアドレスで表現します。ただし、IPv4 プロトコルトランスレータと IPv6 プロトコルトランスレータがないと、これらのアドレスは使用できません。

トンネル機構

移行時の依存状態を最小限に抑える目的から、2 つの IPv6 ノード間にあるすべてのルーターで IPv6 をサポートする必要がありません。この機構をトンネルといいます。基本的に IPv6 パケットは IPv4 パケット内部に組み込まれ、IPv4 ルーター間を転送されます。以下の図は、IPv4 ルーター (R) 間のトンネル機構を示します。

図 4–2 トンネル機構

その他、移行時には次のようなトンネル機構の使用方法があります。

• 2 つのルーター間で設定したトンネル (上記の図を参照)

• デュアルホストで終了する自動トンネル

設定トンネルは、MBONE (IPv4 マルチキャストバックボーン) など現在はインターネットで他の目的に使用します。設定トンネルの作成手順からいうと、2 つのルー ターを設定して、その間に IPv4 ネットワーク経由の仮想ポイントツーポイントリンクを作成します。 近い将来インターネットのさまざまな局面にこの種のトンネルが利用されるでしょう。

自動トンネル

自動トンネルは、6to4 トンネリングを通して作成することをお勧めします。6to4 ルーティングと 6to4 トンネリングの機構詳細は、移行機構としての 6to4を参照してください。

自動トンネルは、IPv4 – 互換アドレスを要求します。 自動トンネルは、IPv6 ルータが使用できない場合に IPv6 ノードを接続するために使用できます。自動トンネルネットワークインタフェースを設定すれば、トンネルの発信元はデュアルホストとデュアルルーターのどちらが発信元でも使用できます。終点は必ずデュアルホストになります。トンネルのはたらきにより、宛先 IPv4 アドレス (トンネルの終点) が IPv4 互換宛先アドレスから抽出されて動的に指定されます。

アプリケーションとの対話

IPv6 にアップグレードしたノードでも、IPv6 を使用できるかどうかはアプリケーション次第です。アプリケーションで、IPv6 アドレスのネームサービスを要求するネットワーキング API を使用しない場合があります。また、アプリケーション側で変更が必要な API (ソケットなど) を使用する場合もあります。さらに、API のプロバイダ (java.net クラスなどの実装) が IPv6 アドレスをサポートしていない場合もあります。 どの場合も、ノードが送受信するのは IPv4 ノードのように IPv4 パケットだけです。

次の用語は、インターネットの世界では標準用語として使用されています。

• IPv6-unaware (非認識) – IPv6 アドレスを処理できないアプリケーション。IPv4 アドレスのないノードとは通信できない

• IPv6-aware (認識) – IPv4 アドレスがないノードとも通信できるアプリケーション。長い IPv6 アドレスも処理できる。アプリケーションに透過な場合がある。たとえば実際のアドレスの内容や形式が API によって非表示になる場合など

• IPv6-enabled (有効化) – IPv6-aware であるだけでなく、フローラベルなど IPv6 固有の機能が利用できる。有効化アプリケーションは低下モードで IPv4 も処理できる

• IPv6–required (要求) — このアプリケーションは、IPv6– 特定機能をいくつか要求する。このアプリケーションは IPv4 では作動できない

IPv4 と IPv6 の相互運用性

IPv4 から IPv6 に段階的に移行する場合、新しく導入する IPv6 有効化アプリケーションと共に既存の IPv4 アプリケーションも使用しなければなりません。最初の段階で、ベンダーは、デュアルスタックを実行しているホストとルータのプラットホームを提供します。 デュアルスタックとは、IPv4 プロトコルスタックと IPv6 プロトコルスタックのことです。 IPv4 アプリケーションは、少なくとも 1 つの IPv6 インタフェースで IPv6 有効化になっているデュアルスタックでも実行できます。アプリケーションの変更や移植は不要です。

デュアルスタックで実行する IPv6 アプリケーションも、IPv4 プロトコルを使用できます。IPv6アプリケーションは、IPv4 マップIPv6 アドレスを使用します。 IPv6 は設計上、IPv4 と IPv6 で別々のアプリケーションは不要です。たとえば、デュアルホストの IPv4 クライアントがなくても IPv4 専用ホストのサーバーと「通信」できます。また独立した IPv6 クライアントがなくても IPv6 サーバーと通信できます。 IPv4 クライアントアプリケーションを新しい IPv6 API に移植するだけです。クライアントは、IPv4 専用サーバーと通信できます。 また、デュアルホストまたは IPv6 専用ホストで実行中の IPv6 サーバーとも通信できます。

ネームサーバーからクライアントが取り出すアドレスで、IPv6 や IPv4 を使用するかどうかが決まります。たとえば、ネームサーバーにそのサーバーの IPv6 アドレスが指定されている場合、サーバーは IPv6 を処理できます。

表 4–1 に IPv4 と IPv6 のクライアントとサーバー間の相互運用性をまとめます。表 4–1 では、デュアルスタックホストに、IPv4 と IPv6 両方のアドレスがそれぞれのネームサービスデータベースに存在するものとします。

X は、それぞれのサーバーとクライアント間の通信ができないことを表します。

(IPv4) は、クライアントの選択するアドレスによって相互運用性が決まることを表します。IPv6 アドレスを選択すると、クライアントの処理はエラーになります。 ただし、IPv4 アドレスを選択すると、IPv4 マップ IPv6 アドレスとしてクライアントに戻り、IPv4 データグラム が送信されて処理が成功します。

IPv6 配置の初期段階では、IPv6 のほとんどの実装がデュアルスタックノードで処理されます。一般ベンダーではほとんど、初期状態では IPv6 専用実装をリリースしません。

サイト移行のシナリオ

サイトや ISP では、それぞれ事情が異なり、移行段階の手順が異なります。 ここでは、サイト移行シナリオの例をいくつか紹介します。

IPv6 へのサイトの移行では、最初に IPv6 アドレスをサポートするためのネームサービスをアップグレードします。DNS の場合、BIND 4.9.4 以降などの新しい AAAA (クアドA) レコードをサポートする DNS サーバーにアップグレードします。2 つの新しい NIS マップと NIS+ テーブルが IPv6 アドレスを保存するために導入されました。これらの新しい NIS マップと NIS+ テーブルは、任意の Solaris システムで作成、管理できます。新しいデータベースの詳細については、Solaris ネームサービスに対する IPv6 拡張機能 を参照してください。

ネームサービスで IPv6 アドレスを処理できるようになったら、ホストの移行を開始します。ホストは、次の手順で移行します。

• ホストを 1 つずつアップグレードします。IPv4 互換アドレスと自動トンネルを使用します。ルーターのアップグレードは不要です。この方法は最初の試験的な移行に適しています。IPv6 の機能のすべてが利用できるわけではありません。したがって、ステートレスアドレス自動設定や IP マルチキャストは利用できません。このシナリオはアプリケーションが IPv6 で実行できるかどうかを確認するときに使用します。また、アプリケーションが IPv6 IP 層セキュリティを利用できるかどうかを確認するときも使用します。

• サブネットを 1 つずつアップグレードします。ルーター間に設定したトンネルを使用します。このシナリオでは、サブネットごとに少なくとも 1 つのルーターをデュアルにアップグレードします。 サイト内のデュアルルーターは設定したトンネル で結合します。 これで、サブネット上のホストでは、IPv6 の全機能を利用できます。このように段階的にアップグレードしていく中で徐々にアップグレードされるルーターが増加するととともに、設定済みのトンネルは削除できます。

• ホストをアップグレードする前にすべてのルーターをヂュアルにアップグレードします。この方法は逐次行われるように思えますが、すべてのルーターがアップグレードされるまでは IPv6 の機能を利用できません。このシナリオでは、段階的な配置方式は制約されます。

移行機構としての 6to4

Solaris オペレーティングシステムには、IPv4 アドレス指定から IPv6 アドレス指定へ移行するための暫定的な推奨方法として 6to4 が含まれています。独立した IPv6 サイトで 6to4 を利用すると、IPv6 をサポートしない IPv4 ネットワーク上で自動トンネルを介して通信できます。6to4 トンネルを使用するには、IPv6 ネットワーク上の境界ルーターを 6to4 自動トンネルの一方のエンドポイントとして設定する必要があります。そのあと、この 6to4 ルーターをほかの 6to4 サイトとの間のトンネルの構成要素として使用することも、あるいは必要に応じて 6to4 以外のネイティブ IPv6 サイトとの間のトンネルで使用することもできます。

この節では、6to4 に関連した以下の参考情報を示します。

• 6to4 トンネルのトポロジ

• 6to4 アドレス指定 (通知の書式など)

• 6to4 トンネルを介したパケットフローの説明

• 6to4 ルーターと 6to4 リレールーター間のトンネルのトポロジ

• 6to4 リレールーターサポートを設定する前の考慮事項

6to4 ルーティングについての詳細は、以下のページ / 文書を参照してください。

6to4 トンネルの構成

次の図は、2 つの 6to4 サイト間の 6to4 トンネルを示しています。

図 4–3 2 つの 6to4 サイト間のトンネル

この図は、独立した 2 つの 6to4 ネットワーク、サイト A とサイト B を示しています。各サイトは、IPv4 ネットワークに外部接続するようにルーターを設定してあります。この図では、IPv4 ネットワークを介した 6to4 トンネルによって 6to4 サイトが接続されています。

IPv6 サイトを 6to4 サイトにするには、6to4 をサポートできるように 1 つ以上のルーターインタフェースを設定する必要があります。このインタフェースは、IPv4 ネットワークに対する外部接続を提供する必要があります。qfe0 で設定するアドレスは、一意 (世界で唯一) のものでなければなりません。上記の図では、境界ルーター A のインタフェース qfe0 によってサイト A が IPv4 ネットワークに接続されています。qfe0 を 6to4 擬似インタフェースとして設定するには、IPv4 アドレスを使用してあらかじめインタフェース qfe0 を設定しておく必要があります。

上記の図では、6to4 サイト A はルーター A 上のインタフェース hme0 と hme1 に接続した 2 つのサブネットから構成されています。サイト A の両サブネットのすべての IPv6 ホストは、ルーター A からの通知を受け取ると 6to4 派生アドレスを使用して自動的に再設定を行います。

サイト B は、サイト A からのトンネルの反対側のエンドポイントにあたります。サイト A からトラフィックを正しく受け取るには、サイト B 側の境界ルーターを 6to4 をサポートするように設定する必要があります。この設定を行わないと、ルーターがサイト A から受け取るパケットが認識されずに削除されてしまいます。

6to4 派生のアドレス指定

ネイティブ IPv6 ルーターの場合と同様に、/etc/inet/ndpd.conf の中の 6to4 プレフィックスから派生したサブネットプレフィックスを通知する必要があります。次の図は、6to4 サイトのプレフィックスの構成を示しています。各部の説明は、6to4 プレフィックスの書式と6to4 通知の例を参照してください。

図 4–4 サイトプレフィックスの構成

次の図は、ndpd.conf ファイルに指定する 6to4 サイトのサブネットプレフィックスの構成を示しています。

図 4–5 サブネットプレフィックスの構成

6to4 プレフィックスの書式

上記の図に示した書式には以下の要素が含まれます。

6to4 通知の例

上記図の例では以下の値を使用しています。

ホストにおける 6to4 派生のアドレス指定

ルーター通知によって 6to4 派生のプレフィックスを受信する際、IPv6 ホストはインタフェース上の 6to4 派生アドレスを自動的に設定し直します。このアドレスの書式は以下のとおりです。

prefix:IPv4 address:subnet ID:host ID/64

6to4 インタフェースを持つホストで ifconfig –a を実行すると、以下のような結果となります。

qfe1:3: flags=2180841<UP,RUNNING,MULTICAST,ADDRCONF,ROUTER,IPv6>
 mtu 1500 index 7
        inet6 2002:8192:56bb:9258:a00:20ff:fea9:4521/64 

6to4 派生アドレスは、ifconfig の出力結果の中で inet6 のあとに続きます。

6to4 トンネルを介したパケットフロー

この節では、1 つの 6to4 サイトにあるホストから遠隔の 6to4 サイト内のホストへのパケットの経路について説明します。次のシナリオは、例として 図 4–3 で示しているトポロジを使用しています。このシナリオは、6to4 ルーターと 6to4 ホストがすでに設定済みであることを想定しています。

1. 6to4 サイト A のサブネット 1 に存在するホストが伝送を行い、6to4 サイト B 上のホストが宛先として機能します。フロー内の各パケットヘッダーには、送信元の 6to4 派生アドレスと宛先の 6to4 派生アドレスが含まれます。

2. 6to4 ルーター A は、出力パケットを受け取り、IPv4 ネットワーク上で 6to4 サイト B との間のトンネルを構築します。

3. サイト A のルーターは、IPv4 ヘッダーを付けて各 6to4 パケットをカプセル化します。続いてサイト A のルーターは、標準の IPv4 ルーティング手続きを使用し IPv4 ネットワークを介してこのパケットを転送します。

4. パケットが遭遇する IPv4 ルーターが、パケットの宛先 IPv4 アドレスを使用して転送を行います。このアドレスはルーター B のインタフェースに使用される一意の (世界に 1 つしかない) IPv4 アドレスであり、6to4 擬似インタフェースとしても機能します。

5. サイト A から送付されたパケットがルーター B に到着します。ルーター B は、IPv4 ヘッダーを削除して IPv6 パケットのカプセル化を解除します。

6. 続いてルーター B は、IPv6 パケット内の宛先アドレスを使用してサイト B の受信ホストにパケットを転送します。

6to4 リレールーターとの間のトンネルについての考慮事項

6to4 リレールーターは、6to4 ではない ネイティブ IPv6 ネットワークと通信を行う必要がある 6to4 ルーターからのトンネルのエンドポイントとして機能します。本来、リレールーターは 6to4 サイトとネイティブ IPv6 サイトとの間のブリッジとして使用されます。この手法は安全ではないため、Solaris オペレーティングシステムのデフォルト設定では 6to4 リレールーターのサポートは無効になっています。しかし、サイトでこのようなトンネルが必要な場合には 6to4relay コマンドを使用して以下に示すようなトンネリングを有効にすることができます。

図 4–6 6to4 サイトと 6to4 リレールーター間のトンネル

図 4–6 では、6to4 サイト A はネイティブ IPv6 サイト B に存在するノードと通信を行う必要があります。この図は、サイト A から IPv4 ネットワーク経由の 6to4 トンネルへと続くトラフィックの経路を示しています。このトンネルは、6to4 ルーター A と 6to4 リレールーターをエンドポイントとして使用しています。6to4 リレールーターより先は IPv6 ネットワークであり、IPv6 サイト B はこのネットワークに接続されています。

6to4 サイトとネイティブ IPv6 サイト間のパケットフロー

この節では、6to4 サイトからネイティブ IPv6 サイトに対するパケットフローについて説明します。ここでは、図 4–6 で示されているシナリオを例として使用しています。

1. 6to4 サイト A 上のホストから、ネイティブ IPv6 サイト B 上のホストに向けて伝送を行います。フロー内の各パケットヘッダーには、その発信元アドレスとして 6to4 派生アドレスが指定されています。宛先アドレスは標準の IPv6 アドレスです。

2. 6to4 ルーター A は、出力パケットを受け取り、IPv4 ネットワーク上で 6to4 リレールーターとの間のトンネルを構築します。

   6to4 リレールーターエニーキャストグループの一部である 6to4 リレールーターには、192.88.99.1 というアドレスが割り当てられます。このエニーキャストアドレスは、6to4 リレールーターのデフォルトアドレスです。特定の 6to4 リレールーターを使用する必要がある場合は、デフォルトを上書きしてそのルーターの IPv4 アドレスを指定できます。

3. サイト A の 6to4 ルーターは、各パケットを宛先である 6to4 ルーターの IPv4 アドレスを持つ IPv4 ヘッダーとともにカプセル化します。この 6to4 ルーターは、標準の IPv4 ルーティング手続きを使用し IPv4 ネットワークを介してこのパケットを転送します。パケットが遭遇する IPv4 ルーターが、6to4 リレールーターにパケットを転送します。

4. サイト A に物理的にもっとも近いエニーキャスト 6to4 リレールーターが、192.88.99.1 エニーキャストグループ宛てのパケットを検出します。

5. このリレールーターは、IPv4 ヘッダーを取り除いて 6to4 パケットのカプセル化を解除し、ネイティブ IPv6 宛先アドレスを明らかにします。

6. 続いてこのリレールーターは、IPv6 のみとなったパケットを IPv6 ネットワークに送信します。IPv6 ネットワークにおいて、パケットは最終的に Site B のルーターによって検出されます。続いてこのルーターが、宛先である IPv6 ノードにパケットを転送します。

6to4 リレールーターサポートのセキュリティ問題

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

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

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

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

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

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

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

• インターネット文書『Security Considerations for 6to4』で提唱されている検査と信頼できるモデルを導入した場合。

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

6to4 構成は、以下に示す既知のバグの影響を受けます。

• 4709338 – 静的な経路を認識する RIPng 実装が必要である

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

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

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

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

• 6to4 サイト内のイントラサイトルーターすべてのルーティングテーブルに静的経路 2002::/16 を追加する

• 6to4 サイトの内部ルーターに RIPng 以外のルーティングプロトコルを使用する

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

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

同じトンネル発信元アドレスを使用して 6to4 トンネルと自動トンネルを設定することは避けてください。

その他の移行機構

先に説明した方法では、デュアルノードと IPv4 ノード間で相互運用をします。その場合、デュアルノードには IPv4 アドレスがあります。ただし、その方法では、IPv6 専用ノードと IPv4 専用ノードの間で相互運用しません。また、IPv4 アドレスのないデュアルノードと IPv4 専用ノード間でも相互運用しません。 ほとんどの実装ではデュアルにできます。ただし、デュアル実装には、IPv4 専用ノードとの相互運用が必要なすべてのノードごとに 1 つのアドレスを割り当てるのに充分な IPv4 アドレス領域が必要です。

次に、新しい移行機構がなくても相互運用を実現できる方法を示します。

• IPv6 専用ノードとインターネットの他の要素との間にアプリケーション層ゲートウェイ (ALG) を配置する。現在使用されている ALG としては、HTTP プロキ シとメールリレーがある

• IPv4 用の、NAT ボックス (ネットワークアドレストランスレータ) をすでに売り出している会社もある。 これは、内部のプライベート IP アドレス (ネットワーク 10 など。RFC 1918 参照) と、外部 の IP アドレスの間の変換を行う。 このような会社では、IPv6 から IPv4 アドレスへの変換もサポートするように、NAT ボックス をアップグレードする可能性が高い

残念ながら、ALG と NAT のどちらの方法も、弱点があります。これらの方法を使用すると、インターネットの基盤がかなり弱まります。 IETF では、IPv6 専用ノードと IPv4 専用ノードとのより良い相互運用性のために努力しています。1 つの提案としては、必要に応じて IPv4 互換アドレスを割り当てる方法でヘッダートランスレータを使用する方法があります。別の方法としては、必要に応じて IPv4 互換アドレスを割り当て、IPv6 トンネルで IPv4 を利用して IPv6 専用ルーターをブリッジできます。

ステートレスヘッダートランスレータでは、使用中の IPv6 アドレスを IPv4 アドレスとして表現できれば、IPv4 ヘッ ダーフォーマットと IPv6 ヘッダーフォーマットの間の変換が可能です。つまり、アドレスは、IPv4 互換アドレスである必要があります。 もしくは、IPv4マップアドレスである必要があります。 これらのトランスレータのサポートは、IPv6 プロトコ ルに組み込まれています。 暗号化されているパケットを除いて、変換時に情報は失われません。ソースルーティングなどの使用頻度の低い機能は、情報が失われてしまうことがあります。