IPv6 をサポートするためにホストとルーターをアップグレードした後も、IPv4 だけをサポートしているホストとルーター とのネットワーク経由の相互運用が必要です。この章では、IPv4 から IPv6 への移行と、標準的な解決法の概要について説明します。RFC 1933 でも、移行問題の詳しい解決法を示しています。
この章では、以下の内容について説明します。
移行時のグローバルな調整は不要です。サイトとインターネットサービスプロバイダ (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 専用ノードは、どちらも IPv4 ノード
サイト – インターネットのプライベートトポロジの 1 つ。すなわちあらゆるユーザーを対象としたトラフィック伝送を行わないトポロジ。サイトが物理的に広範囲に展開されることがある。たとえば、多国籍企業のプライベートネットワークは、1 つのサイト
ホストとルーターを IPv6 にアップグレードするとき、それらの IPv4 の機能を残す。したがって、すべての IPv4 プロトコルおよびアプリケーションとの互換性が確保される。このようなホストおよびルーターをデュアルスタックと呼ぶ
IPv6 対応ノードに関する情報は、(DNS などの) ネームサービスを利用して伝送する
IPv6 アドレス形式には、IPv4 アドレスを保存する
デュアルスタックとは、アプリケーションからネットワーク層に至るプロトコルスタックのすべてのレベルの完全な複製をいいます。デュアルスタックの例として、同じマシンで実行する OSI プロトコルと TCP/IP プロトコルがあります。ただし、 IPv6 移行の観点からは、プロトコルスタックに IPv4 と IPv6 の両方を組み込むことを表します。残りスタックは同一となります。この場合、同じ伝送プロトコル (TCP、UDPなど) が IPv4 と IPv6 の両方で実行します。また、同じアプリケーションも IPv4 と IPv6 の両方で実行します。
次の図は、OSI 層全体にわたるデュアルスタックプロトコルを表します。
デュアルスタック方式では、ホストとルーター両方のサブセットをアップグレードして、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 ルートが必要です。
通常 32 ビット IPv4 アドレスは、128 ビット IPv6 アドレスで表現できます。移行機能では、次の 2 つの形式を定義しています。
IPv6 ノードは互換フォーマットで表現します。このフォーマットでは、実際の IPv6 アドレスがなくても IPv6 ノードを使用できます。また、IPv4 専用ルーターで自動トンネルを使用できるため、このアドレスフォーマットではさまざまな IPv6 設定の試用が可能です。ただし、IPv6 ステートレスアドレス自動設定機構では、このアドレスは設定できません。IPv6 ステートレスアドレス自動設定機構には、DHCPv4 など既存の IPv4 機構や静的設定ファイルが必要なためです。
マップアドレスフォーマットでは、IPv4 ノードを表現します。現在ソケット API の一部でだけ、このアドレスフォーマットの使用方法が定義されています。アプリケーションでは、IPv6 アドレスと IPv4 アドレスの両方に共通のアドレスフォーマットを使用できます。 共通のアドレスフォーマットは、IPv4 アド レスを 128 ビットマップアドレスで表現します。ただし、IPv4 プロトコルトランスレータと IPv6 プロトコルトランスレータがないと、これらのアドレスは使用できません。
移行時の依存状態を最小限に抑える目的から、2 つの IPv6 ノード間にあるすべてのルーターで IPv6 をサポートする必要がありません。この機構をトンネルといいます。基本的に IPv6 パケットは IPv4 パケット内部に組み込まれ、IPv4 ルーター間を転送されます。図 17–2 は、IPv4 を使用したルーター (R) 間のトンネル機構を示します。
その他、移行時には次のようなトンネル機構の使用方法があります。
2 つのルーター間で設定したトンネル (上記の図を参照)
デュアルホストで終了する自動トンネル
設定トンネルは、MBONE (IPv4 マルチキャストバックボーン) など現在はインターネットで他の目的に使用します。設定トンネルの作成手順からいうと、2 つのルー ターを設定して、その間に IPv4 ネットワーク経由の仮想ポイントツーポイントリンクを作成します。 近い将来インターネットのさまざまな局面にこの種のトンネルが利用されるでしょう。
初期の実験的配置では、自動トンネルの使用可能範囲は限定されています。IPv6 ルーターがない場合、自動トンネルには IPv4 互換アドレスが必要であり、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 に段階的に移行する場合、新しく導入する 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 を処理できます。
表 17–1 に IPv4 と IPv6 のクライアントとサーバー間の相互運用性をまとめます。表 17–1 では、デュアルスタックホストに、IPv4 と IPv6 両方のアドレスがそれぞれのネームサービスデータベースに存在するものとします。
表 17–1 クライアントサーバーアプリケーション: IPv4 と IPv6 の相互運用性
アプリケーションの種類 (ノードの種類) |
IPv6-unaware (非認識) サーバー (IPv4 専用ノード) |
IPv6-unaware (非認識) サーバー (IPv6 有効化ノード) |
IPv6-aware (認識) サーバー (IPv6 専用ノード) |
IPv6-aware (認識) サーバー (IPv6 有効化ノード) |
---|---|---|---|---|
IPv6-unaware (非認識) クライアント (IPv4 専用ノード) |
IPv4 |
IPv4 |
X |
IPv4 |
IPv6-unaware (非認識) クライアント (IPv6 有効化ノード) |
IPv4 |
IPv4 |
X |
IPv4 |
IPv6-aware (認識) クライアント (IPv6 専用ノード) |
X |
X |
IPv6 |
IPv6 |
IPv6-aware (認識) クライアント (IPv6 有効化ノード) |
IPv4 |
(IPv4) |
IPv6 |
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 の機能を利用できません。このシナリオでは、段階的な配置方式は制約されます。
先に説明した方法では、デュアルノードと 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 プロトコ ルに組み込まれています。 暗号化されているパケットを除いて、変換時に情報は失われません。ソースルーティングなどの使用頻度の低い機能は、情報が失われてしまうことがあります。