(57)【要約】異種IPv6/IPv4ネットワーク(例えば300)においてホスト名がDNSサーバを介して解決不可能なサーバとクライアントが通信することを可能にする方法及びシステムである。解決は、好ましくはネットワーク(300)のポータル(18)に格納される２つのテーブル(40、50)をクライアントに提供することにより実現され、それによって、クライアントは、サーバ(19、20、22、26、30)と通信を可能にするテーブル情報を使用して、ポータル(18)とプロトコル交換を実行する。
2006511152.tif 000002
【特許請求の範囲】
【請求項１】
異種IPネットワークにおいてクライアントノードとサーバノードとの間で通信を確立する方法であって、
(a)前記クライアントに所望のコンテンツを提供可能なサーバのホスト名のリストについて、前記ネットワークのポータルに対して、前記クライアントに関連するユーザにより要求を行うステップと、
(b)前記クライアントの要求に応じて前記ポータルから前記クライアントに第１のテーブルと第２のテーブルとを提供し、前記第１のテーブルは前記サーバノードのホスト名のリストを有するステップと、
(c)前記提供されたサーバのホスト名のリストを前記クライアントでフィルタリングし、前記クライアントが通信を確立できないサーバのホスト名を除外するステップと、
(d)前記フィルタリングされたサーバのホスト名のリストからサーバのホスト名を前記ユーザにより選択するステップと、
(e)前記ユーザ選択されたサーバのホスト名に関連するIPアドレスがドメインネームサーバ(DNS)を介して解決可能であるか否かを前記第１のテーブルから決定するステップと、
(f)前記ステップ(e)が満たされる場合に、前記DNSから前記関連するIPアドレスを取得するステップと、
(g)前記ステップ(e)が満たされない場合に、前記クライアントにより前記ポータルでプロトコルを実行し、前記選択されたサーバのホスト名を有するサーバの１つ以上のデフォルトIPアドレスを決定するステップと
を有する方法。
【請求項２】
請求項１に記載の方法であって、
前記ステップ(f)に続いて、前記関連するIPアドレスを使用して前記選択されたサーバと通信を確立するステップを更に有する方法。
【請求項３】
請求項２に記載の方法であって、
前記選択されたサーバと通信を確立するステップは、
(1)前記DNSからの第１の返信されたIPアドレスのIPバージョンが前記クライアントのIPバージョンと同じバージョンであるか否かを決定するステップと、
(2)前記ステップ(1)が満たされない場合、前記DNSから次に返信されたIPアドレスを取得し、前記ステップ(1)を繰り返すステップと、
(3)前記ステップ(1)が満たされる場合、前記第１の返信されたIPアドレスの前記IPバージョン及び前記クライアントの前記IPバージョンがIPv6バージョンであるか否かを決定するステップと、
(4)前記ステップ(3)が満たされる場合、前記IPv6バージョンが6to4アドレスであるか否かを決定するステップと、
(5)前記ステップ(4)が満たされる場合、前記IPv6プロトコル及び自動構成トンネリングを使用して前記選択されたサーバと通信を確立するステップと
を更に有する方法。
【請求項４】
請求項３に記載の方法であって、
前記ステップ(4)が満たされない場合、IPv6プロトコル及び終端アドレスとして中継ルータを有するトンネリング方法を使用して、前記選択されたサーバと通信を確立する方法。
【請求項５】
請求項３に記載の方法であって、
前記ステップ(3)が満たされない場合、IPv4プロトコルを使用して、前記選択されたサーバと通信を確立する方法。
【請求項６】
請求項１に記載の方法であって、
前記ステップ(g)に続いて、前記関連するIPアドレスを使用して、前記選択されたサーバと通信を確立するステップを更に有する方法。
【請求項７】
請求項６に記載の方法であって、
前記選択されたサーバと通信を確立するステップは、
(1)前記第２のテーブルからの第１の返信されたIPアドレスのIPバージョンが前記クライアントのIPバージョンと同じバージョンであるか否かを決定するステップと、
(2)前記ステップ(1)が満たされない場合、前記第２のテーブルから次の返信されたIPアドレスを取得し、前記ステップ(1)を繰り返すステップと、
(3)前記ステップ(1)が満たされる場合、前記第１の返信されたIPアドレスの前記IPバージョン及び前記クライアントの前記IPバージョンがIPv6バージョンであるか否かを決定するステップと、
(4)前記ステップ(3)が満たされる場合、前記IPv6バージョンが6to4アドレスであるか否かを決定するステップと、
(5)前記ステップ(4)が満たされる場合、前記IPv6プロトコル及び自動構成トンネリングを使用して、前記選択されたサーバと通信を確立するステップと
を有する方法。
【請求項８】
請求項７に記載の方法であって、
前記ステップ(4)が満たされない場合、IPv6プロトコル及び終端アドレスとして前記第２のテーブルから取得された中継ルータアドレスへのトンネリングを使用して、前記選択されたサーバと通信を確立する方法。
【請求項９】
請求項７に記載の方法であって、
前記ステップ(3)が満たされない場合、IPv4プロトコルを使用して、前記選択されたサーバと通信を確立する方法。
【請求項１０】
請求項１に記載の方法であって、
前記決定するステップは、インデックスとして前記ユーザ選択されたサーバのホスト名を使用して、前記クライアントにより前記第１のテーブルで照合を実行し、前記DNSを介して選択されたサーバのホスト名の解決可能状態を示すレコード値を取得することを更に有する方法。
【請求項１１】
請求項１に記載の方法であって、
前記ステップ(g)は、インデックスとして前記ユーザ選択されたサーバのホスト名を使用して、前記クライアントにより前記第２のテーブルで照合を実行し、前記選択されたサーバと通信を確立するため、前記ユーザ選択されたサーバのホスト名に関連する１つ以上のデフォルトIPアドレスを決定することを更に有する方法。
【請求項１２】
請求項１に記載の方法であって、
前記ステップ(a)の前に、複数のレコードで前記ベンダポータルの前記第１のテーブルを生成するステップを更に有し、
各レコードは、
前記クライアントに前記所望のコンテンツを提供可能な前記ネットワークのサーバの前記サーバのホスト名と、
前記サーバのホスト名に関連するIPアドレスバージョンと、
前記サーバのホスト名が前記ネットワークのDNSサーバを介して解決可能であるか否かのインジケータと
を有する方法。
【請求項１３】
請求項８に記載の方法であって、
前記生成するステップは、前記IPネットワークの動作の前の登録段階中に実行される方法。
【請求項１４】
請求項１に記載の方法であって、
前記ステップ(a)の前に、複数のレコードで前記ベンダポータルの前記第２のテーブルを生成するステップを更に有し、
各レコードは、
前記クライアントに前記所望のコンテンツを提供可能な前記ネットワークのサーバの前記サーバのホスト名と、
前記サーバのホスト名に関連するデフォルトIPアドレスと、
中継ルータアドレスと
を有する方法。
【請求項１５】
請求項１４に記載の方法であって、
前記生成するステップは、前記IPネットワークの動作の前の登録段階中に実行される方法。
【請求項１６】
請求項１に記載の方法であって、
前記ステップ(c)は、
前記サーバのホスト名に関連する１つ以上のIPアドレスバージョンと前記クライアントのIPアドレスバージョンとを比較し、前記比較から、前記比較されたIPアドレスバージョンが前記クライアントと前記サーバとの間で通信を確立可能であるか否かを決定するステップと、
前記比較のステップが満たされる場合、前記フィルタリングされたリストに前記サーバのホスト名及び関連するレコード情報を保持するステップと、
そうでない場合、前記フィルタリングされたリストから前記サーバのホスト名及び関連するレコード情報を削除するステップと
を更に有する方法。
【請求項１７】
異種IPネットワークにおいてクライアントノードとサーバノードとの間で通信を確立する方法であって、
前記クライアントに所望のコンテンツを提供可能なサーバのホスト名のリストについて、前記ネットワークのポータルに対して、前記クライアントに関連するユーザにより要求を行う手段と、
前記クライアントの要求に応じて前記ポータルから前記クライアントに第１のテーブルと第２のテーブルとを提供し、前記第１のテーブルは前記サーバノードのホスト名のリストを有する手段と、
前記提供されたサーバのホスト名のリストを前記クライアントでフィルタリングし、前記クライアントが通信を確立できないサーバのホスト名を除外する手段と、
前記フィルタリングされたサーバのホスト名のリストからサーバのホスト名を前記ユーザにより選択する手段と、
前記ユーザ選択されたサーバのホスト名に関連するIPアドレスがドメインネームサーバ(DNS)を介して解決可能であるか否かを前記第１のテーブルから決定する手段と、
前記決定する手段が満たされる場合に、前記DNSから前記関連するIPアドレスを取得する手段と、
前記決定する手段が満たされない場合に、前記クライアントにより前記ポータルでプロトコルを実行し、前記選択されたサーバのホスト名を有するサーバの１つ以上のデフォルトIPアドレスを決定する手段と
を有するシステム。
【請求項１８】
請求項１７に記載のシステムであって、
前記決定する手段が満たされる場合に、前記関連するIPアドレスを使用して前記選択されたサーバと通信を確立する手段を更に有するシステム。
【請求項１９】
請求項１８に記載のシステムであって、
前記関連するIPアドレスを使用して前記選択されたサーバと通信を確立する手段は、
前記DNSからの第１の返信されたIPアドレスのIPバージョンが前記クライアントのIPバージョンと同じバージョンであるか否かを決定する第１の手段と、
前記決定する手段が満たされない場合、前記DNSから次に返信されたIPアドレスを取得し、決定する手段を繰り返す手段と、
前記第１の決定する手段が満たされる場合、前記第１の返信されたIPアドレスの前記IPバージョン及び前記クライアントの前記IPバージョンがIPv6バージョンであるか否かを決定する第２の手段と、
前記第２の決定する手段が満たされる場合、前記IPv6バージョンが6to4アドレスであるか否かを決定する第３の手段と、
前記第３の手段が満たされる場合、前記IPv6プロトコル及び自動構成トンネリングを使用して前記選択されたサーバと通信を確立する手段と
を更に有するシステム。
【請求項２０】
請求項１９に記載のシステムであって、
前記決定する第３の手段が満たされない場合、IPv6プロトコル及び終端アドレスとして中継ルータを有するトンネリング方法を使用して、前記選択されたサーバと通信を確立するシステム。
【請求項２１】
請求項１９に記載のシステムであって、
前記決定する第２の手段が満たされない場合、IPv4プロトコルを使用して、前記選択されたサーバと通信を確立するシステム。
【請求項２２】
請求項１７に記載のシステムであって、
前記決定する手段が満たされない場合、前記関連するIPアドレスを使用して、前記選択されたサーバと通信を確立する手段を更に有するシステム。
【請求項２３】
請求項２２に記載のシステムであって、
前記通信を確立する手段は、
前記第２のテーブルからの第１の返信されたIPアドレスのIPバージョンが前記クライアントのIPバージョンと同じバージョンであるか否かを決定する第１の手段と、
前記決定する第１の手段が満たされない場合、前記第２のテーブルから次の返信されたIPアドレスを取得し、前記決定する第１の手段を繰り返す手段と、
前記決定する第１の手段が満たされる場合、前記第１の返信されたIPアドレスの前記IPバージョン及び前記クライアントの前記IPバージョンがIPv6バージョンであるか否かを決定する第２の手段と、
前記決定する第２の手段が満たされる場合、前記IPv6バージョンが6to4アドレスであるか否かを決定する第３の手段と、
前記決定する第３の手段が満たされる場合、前記IPv6プロトコル及び自動構成トンネリングを使用して、前記選択されたサーバと通信を確立する手段と
を有するシステム。
【請求項２４】
請求項２３に記載のシステムであって、
前記決定する第３の手段が満たされない場合、IPv6プロトコル及び終端アドレスとして中継ルータを有するトンネリング方法を使用して、前記選択されたサーバと通信を確立するシステム。
【請求項２５】
請求項２６に記載のシステムであって、
前記決定する第２の手段が満たされない場合、IPv4プロトコルを使用して、前記選択されたサーバと通信を確立するシステム。
【請求項２６】
請求項１７に記載のシステムであって、
前記第１のテーブルは前記ベンダポータルに存在し、複数のレコードを有し、
各レコードは、
前記クライアントに前記所望のコンテンツを提供可能な前記ネットワークのサーバの前記サーバのホスト名と、
前記サーバのホスト名に関連するIPアドレスバージョンと、
前記サーバのホスト名が前記ネットワークのDNSサーバを介して解決可能であるか否かのインジケータと
を有するシステム。
【請求項２７】
請求項１７に記載のシステムであって、
前記第２のテーブルは前記ベンダポータルに存在し、複数のレコードを有し、
各レコードは、
前記クライアントに前記所望のコンテンツを提供可能な前記ネットワークのサーバの前記サーバのホスト名と、
前記サーバのホスト名に関連するデフォルトIPアドレスと、
中継ルータアドレスと
を有するシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、概して異種IPネットワークにおけるクライアントとサーバとの間での電子コンテンツ配信に関するものである。特に、本発明は、クライアントが異種IPネットワークにおいてホスト名がDNSサーバを介して解決不可能なサーバと通信することを可能にする方法に関するものである。
【背景技術】
【０００２】
インターネットプロトコル(“IP”)は、ネットワーク内又はネットワーク間でトラヒックのルーティングを容易にするために設計されたアドレッシングプロトコルである。近年、インターネットプロトコルは、インターネットとイントラネットとを含み、多数のコンピュータネットワークで使用されている。インターネットプロトコルの現在のバージョン(すなわちバージョン4(“IPv4”))は、限られたアドレス空間に対応する。32ビットのアドレスフィールドで、232までの異なるIPv4アドレスを割り当てることができ、それは4,294,967,296個になり、それは40億個のグローバルに一意のアドレスより大きい。インターネットプロトコル・バージョン6(“IPv6”)は、IPアドレスについて128ビットのアドレスフィールドの使用を提案する。IPv6はまた、アドレス自動構成や、近隣発見や、ルータ発見のように、既存のIPv4プロトコルに対していくつかの更なるアーキテクチャ上の改善を有する。IPv6により与えられる利点にもかかわらず、多数のネットワーク(多数のインターネット・サブネットを含む)は、長い間依然としてIPv4を使用している。これは、既存のインターネットインフラで既に行われた相当の経済上及び知識上の投資のためである。従って、IPv6への移行は、IPv6が最初に既存のIPv4プロトコルと共存し、その後次第に既存のIPv4プロトコルに取って代わる長期間を必要とする。
【０００３】
そのため、IPv6/IPv4エンティティが現れる仮の異種IPv6/IPv4インフラが予期される。それは、ネットワークプロトコルスタックでIPv6とIPv4の双方をサポートし、双方のプロトコルを介して通信することができる。IPv4とIPv6との共存をサポートする現在の活動は、既存のIPv4バックボーンをトランジットとして使用する“IPv6アイランド”(又はサブネット)の間のドメイン間ルーティングに集中している。しかし、これらのアイランド自体は、ドメイン内のIPv4からIPv6への移行機構及び方策を必要とする複雑な異種IPv4及びIPv6内部構造(例えば大規模の研究用又は商用のキャンパス“イントラネット”)を有することがある。
【０００４】
要するに、変換器及びトンネリングは、既知の移行機構である。前者はこの出願では更に検討されない。トンネリングは当該技術分野において周知であり、ポイント・ツー・ポイント・トンネルを作ることにより動作し、それにより、IPv6パケットはIPv4ヘッダにカプセル化されてIPv4ルーティングインフラで運ぶ。２つの種類のトンネリング技術(手構成(configured)及び自動構成(automatic))がRFC2893に開示されている。手構成トンネリング(configured  tunneling)は、カプセル化ノードのトンネル終端アドレスの手動構成により特徴付けられる。手構成トンネリングは、構成及び運転管理リソースの点で高価であり、ネットワークトポロジの変化に適応しない。自動構成トンネリング(automatic  tunneling)は、カプセル化ノードのトンネル終端アドレスの自動構成により特徴付けられる。すなわち、手動構成を必要とせず、更にネットワークトポロジの変化に適応する。これが、自動構成トンネリングが好ましい理由である。自動構成トンネリングは、埋め込みIPv4アドレスと共に特別のIPv6アドレスを使用することにより可能になる。後者はカプセル化ノードにより使用され、トンネルの終端を定める。自動構成トンネリングを促進するIPv6アドレスの種類は以下の通りである。
・IPv4互換IPv6アドレス(RFC1886参照)
・IPv4マップ化IPv6アドレス(RFC1886参照)
・6over4アドレス(RFC2529参照)
・6to4アドレス(RFC3056参照)
・ISATAPアドレス(RFC  draft-ietf-ngtrans-isatap-06.txt)
RFC3056に定められている6to4アドレスは、(異なるサブネット間の)サイト間自動構成トンネリングが実行される場合に使用される。6to4アドレスの下位の80ビットは、サイトレベル集約識別子(SLA  ID:Site-Level  Aggregation  Identifier)やインタフェースIDのようなIPv6ノードでローカルに利用可能な情報を有する。後者は、通常は製造時に内蔵されるIPv6ノードのMACアドレスに等しい。上位の48ビットは6to4プレフィックスとして知られている。IANAは6to4プレフィックスの上位16ビットに数値0x0002(すなわち、2002::/16)を不変に割り当てている。6to4プレフィックスの下位32ビットは、加入者サイトのグローバルに一意のIPv4アドレスのコロン16進数表示(colon-hexadecimal  representation)に確保されている。6to4プレフィックスの例は、2002:8291:ae7c::/48であり、パブリックIPv4アドレス130.145.174.124に対応する。
【０００５】
クライアントがコンテンツ(例えばウェブページ)を取得する目的で、又は通信(音声会議／テレビ会議、チャット、ゲーム)に関与する目的で、(IPv4又はIPv6ネットワーク内の)サーバに連絡しようとすると、クライアントは、まずサーバのバイナリIPアドレスを知らなければならない。クライアントとサーバは同じネットワークにあってもよく、異なるネットワークにあってもよい。クライアントは、バイナリIPアドレスではなく、servername.philips.comのようなサーバのホスト名(アスキー文字列)又は“friend@philips.com”のような電子メールアドレスにより、サーバ(ホスト、メールボックス又はその他のリソース)に問い合わせる。それにもかかわらず、基礎のIPネットワーク自体はIPアドレスのみを理解するため、アスキー文字列をバイナリIPアドレスに変換するために、ドメインネームシステム(DNS:Domain  Name  System)として知られる機構が使用される。まず、DNSはIPv4アドレスのみでサポートされ、その後、IPv6アドレス集約及び再番号割当(RFC2874参照)に対応するように拡張された。しかし、IPv4からIPv6への移行期間に、DNSインフラは完全にIPv6をサポートしないことがある。すなわち、IPv6レコード(すなわちAAAA又はA6レコード)を維持しない孤立したDNSサーバが存在する。従って、プライマリ及びセカンダリDNSサーバがA6レコードをサポートしないIPv6ノードは、IPv6アドレスにより解決できないため、他のIPv6ノードによりホスト名で到達不可能(アドレス指定不可能)である。
【発明の開示】
【発明が解決しようとする課題】
【０００６】
従って、本発明は、アドレス指定されたIPv6ノードにサービス提供するプライマリ及びセカンダリDNSサーバがA6レコードをサポートしない場合に、他のIPv6ノードによりIPv6ノードをアドレス指定できない現在の制約を克服する新たな機構を提案する。
【０００７】
本発明は、ホスト名が異種IPv6/IPv4ネットワークでDNSサーバを介して解決できないサーバとクライアントが通信することを可能にする方法を対象とする。
【課題を解決するための手段】
【０００８】
本発明によると、クライアントからIPv6サブネットのサーバをアドレス指定する方法は、(a)そのクライアントに所望のコンテンツを提供可能なサーバノードのホスト名のリストについて、そのネットワークのポータルに対して、そのクライアントに関連するユーザにより要求を行うステップと、(b)そのクライアントの要求に応じてそのポータルからそのクライアントに第１のテーブルと第２のテーブルとを提供し、その第１のテーブルはそのサーバノードのホスト名のリストを有するステップと、(c)その提供されたサーバのホスト名のリストをそのクライアントでフィルタリングし、そのクライアントが通信を確立できないサーバノードのホスト名を除外するステップと、(d)そのフィルタリングされたサーバノードのホスト名のリストからサーバのホスト名をそのユーザにより選択するステップと、(e)そのユーザ選択されたサーバのホスト名に関連するIPアドレスがドメインネームサーバ(DNS:domain  name  server)を介して解決可能であるか否かをその第１のテーブルから決定するステップと、(f)そのステップ(e)が満たされる場合に、そのDNSからその関連するIPアドレスを取得するステップと、(g)そのステップ(e)が満たされない場合に、そのクライアントによりそのポータルでプロトコルを実行し、その選択されたサーバのホスト名を有するサーバの１つ以上のデフォルトIPアドレスを決定するステップとを有する。
【０００９】
本発明の態様によると、クライアントからIPv6サブネットのサーバをアドレス指定するシステムは、そのクライアントに所望のコンテンツを提供可能なサーバのホスト名のリストについて、そのネットワークのポータルに対して、そのクライアントに関連するユーザにより要求を行う手段と、そのクライアントの要求に応じてそのポータルからそのクライアントに第１のテーブルと第２のテーブルとを提供し、その第１のテーブルはそのサーバノードのホスト名のリストを有する手段と、その提供されたサーバのホスト名のリストをそのクライアントでフィルタリングし、そのクライアントが通信を確立できないサーバのホスト名を除外する手段と、そのフィルタリングされたサーバのホスト名のリストからサーバのホスト名をそのユーザにより選択する手段と、そのユーザ選択されたサーバのホスト名に関連するIPアドレスがドメインネームサーバ(DNS:domain  name  server)を介して解決可能であるか否かをその第１のテーブルから決定する手段と、その決定する手段が満たされる場合に、そのDNSからその関連するIPアドレスを取得する手段と、その決定する手段が満たされない場合に、そのクライアントによりそのポータルでプロトコルを実行し、その選択されたサーバのホスト名を有するサーバの１つ以上のデフォルトIPアドレスを決定する手段とを有する。
【００１０】
ここに記載されている方法及びシステムは、インターネットプロトコル・バージョン4(“IPv4”)ネットワークからインターネットプロトコル・バージョン6(“IPv6”)ネットワークへの移行を支援し得る。しかし、本発明はそのような実施例に限定されず、XビットとYビットのネットワークの間で移行を必要とし、二重のネットワーク利用を必要とする事実上如何なるセットのネットワークで使用可能である。
【００１１】
前記及び他の利点は、添付図面とともに以下の詳細な説明を読むことにより、当業者に明らかになる。
【発明を実施するための最良の形態】
【００１２】
本発明の以下の詳細な説明において、本発明の完全な理解を提供するために、多数の特別の詳細が示されている。しかし、本発明はこれらの特別の詳細なしに実行可能であることが当業者に明らかである。ある場合には、本発明をあいまいにすることを避けるために、周知の構成及び装置が詳細にではなく、ブロック図形式で示されている。
【００１３】
Ａ．用語
以下の説明は、以下に挙げるこの出願を通じて使用される関連用語の簡単なレビューにより明確になる。
【００１４】
“ノード”は、そのネットワークプロトコルスタックにIPv4若しくはIPv6又はその双方を実装する装置として定義される。
【００１５】
“ルータ”は、それ自体に明示的にアドレス指定されないIPパケットを転送するノードとして定義される。
【００１６】
“ゲートウェイ”は、NA(P)TやDHCPサーバ等のようなルータと比較して、更なる機能を有するノードとして定義される。
【００１７】
“ホスト”は、ルータ又はゲートウェイでない何らかのノードとして定義される。
【００１８】
“インタフェース”は、リンクへのノードの連結として定義される。
【００１９】
“パケット”は、IPヘッダに何らかのペイロードを加えたものとして定義される。
【００２０】
一般的に“IPv4専用ノード”という用語は、IPv4のみを実装し、IPv6を理解できないホスト又はルータを示す。
【００２１】
一般的に“IPv6専用ノード”という用語は、IPv6のみを実装し、IPv4を理解できないホスト又はルータを示す。
【００２２】
一般的に“IPv4/IPv6ノード”という用語は、IPv4とIPv6の双方を実装したホスト又はルータを示す。
【００２３】
一般的に“IPv4ノード”という用語は、IPv4を実装したホスト又はルータを示す。IPv6/IPv4ノード及びIPv4専用ノードは双方共にIPv4ノードである。
【００２４】
一般的に“IPv6ノード”という用語は、IPv6を実装したホスト又はルータを示す。IPv6/IPv4ノード及びIPv6専用ノードは双方共にIPv6ノードである。
【００２５】
一般的に“IPv4パケット”という用語は、IPv4ヘッダにペイロードを加えたものを示す。
【００２６】
一般的に“IPv6パケット”という用語は、IPv6ヘッダにペイロードを加えたものを示す。
【００２７】
一般的に“IPv4ネットワーク”という用語は、専らIPv4ノードで構成されるネットワークを示す。
【００２８】
一般的に“IPv6ネットワーク”という用語は、専らIPv6ノードで構成されるネットワークを示す。
【００２９】
一般的に“IPv6/IPv4ネットワーク”という用語は、IPv4ノードとIPv6ノードの双方で構成されるネットワークを示す。
【００３０】
Ｂ．従来型のIPv4ネットワーク
本発明の特定の態様をより良く理解するために、クライアントが従来型のIPv4ネットワークでサーバにアクセスする方法をまず検討することが有益である。
【００３１】
図１は、第１のIPv4ネットワークにあるIPv4専用クライアントが第２の(異なる)IPv4ネットワークにあるIPv4サーバにDNSサービスを介してアクセスする方法を一般的に記載したフローチャートである。DNSサービスを介してサーバへのアクセスを取得するこの処理は、当該技術分野において周知であり、図２の例示的なIPv4ネットワークのような異種ネットワークでIPアドレスに対してホスト名を解決することを常に保証されている。しかし、DNSサービスの信頼性は、以下に説明する図３のようなIPv6/IPv4ネットワークのような異種ネットワークの場合に必ずしも保証されているわけではない。本発明は、以下に説明するように、DNSサービスが異種ネットワークで信頼できない場合に、クライアントがサーバへのアクセスを取得することを可能にする方法を対象とする。
【００３２】
まず図１のフローチャートを参照すると、ステップ106において、クライアントは、特定のコンテンツ形式(例えばオーディオ、ビデオ等)を提供可能なサーバについてネットワークのポータルに要求を行うと、ポータルから適切なサーバのホスト名のリストを返信される。ステップ108において、クライアントのユーザは、提供されたリストから１つのサーバのホスト名を選択する。ステップ110において、クライアントは、ネットワークのデフォルトDNSサーバにDNS要求を送信する。ステップ112において、クライアントはサーバのIPv4アドレスを返信される。ステップ114において、クライアントはIPv4を使用してサーバと通信する。
【００３３】
図１のフローチャートに示すように、異種ネットワークでクライアントからサーバにアクセスする原理について、一例として補足する。具体的には、図２は、パブリック広域ネットワーク(“WAN”)24とオフィス／ホーム・ローカルエリアネットワーク(“LAN”)12とで構成される異種ネットワーク通信システム200である。ネットワーク12と24の双方は、クライアント14、ゲートウェイ16、ベンダポータル18、サーバ19及びサーバ20のそれぞれが全て共通のプロトコル(すなわちIPv4プロトコル(RFC791参照))をサポートするという点で、IPv4ベースである。例示的なネットワークでは、クライアント14は、サーバ19や20のような複数のインターネット音楽ステーション(コンテンツプロバイダ)からオーディオコンテンツを受信可能なインターネットラジオクライアントと仮定する。クライアント14でオーディオコンテンツを取得するために、クライアント14は、所望のコンテンツを提供可能なサーバのホスト名のリスト(例えばサーバ19及び20)を取得しなければならない。サーバのホスト名のリストを取得するために、まず、クライアント14はネットワークのデフォルト・ポータル(例えばベンダポータル18)に接続する。このリストに含まれるサーバは、事前にポータル18に自分自身を登録していることを仮定する。リストを受信すると、クライアント14に関連するユーザは、提供されたリストからサーバのホスト名のうち１つを選択してもよい。次に、選択されたサーバのホスト名をバイナリIPアドレスにマッピングするために、従来通り、クライアント14は、ネットワーク10でそのデフォルトDNSサーバ(図示なし)を使用する。DNSサーバはホームネットワーク12にあってもよく、パブリックネットワーク24(ベンダポータル18を含む)にあってもよい。DNSサーバから返信されたIPv4アドレスを使用して、クライアント14は選択されたサーバ(例えばサーバ20)と通信を開始し、オーディオコンテンツを受信することができる。
【００３４】
図２の異種IPv4ベースのネットワーク10がIPv4からIPv6に移行すると、前述の例は複雑になる。
【００３５】
Ｃ．IPv4からIPv6への移行
図３の通信ネットワークシステム300は、本発明の原理を示した例示的な異種IPv6/IPv4ネットワークを表している。ネットワーク300は、図２のIPv4ベースのネットワーク10が異種IPv6/IPv4ネットワークに移行し得る状態を一例として表している。図２のホームIPv4ネットワーク12は、新しいクライアント(IPv6/IPv4クライアント34及びIPv6専用クライアント36)を有するように拡張されている。図２のパブリックIPv4ネットワーク24は、IPv6/IPv4コンテンツプロバイダ22(一般的には6to4ルータ、RFC3056参照)と、IPv6専用コンテンツプロバイダ26(一般的には6to4ホスト、RFC3056参照)と、IPv6専用コンテンツプロバイダ30(ネイティブIPv6アドレスを有する)と、IPv6/IPv4中継ルータ28とを有するように拡張されている。IPv6/IPv4中継ルータ28は、IPv6専用サーバの6to4アドレスとネイティブIPv6アドレスとの間のルーティングをサポートするように構成されている。
【００３６】
説明を簡単にするために、図３の異種IPv6/IPv4ネットワーク300は移行機構として変換器をサポートしないが、トンネリングのみをサポートすることを仮定する。従って、IPv4専用ホストとIPv6専用ホストとの間の通信は維持されない(例えば、IPv4専用クライアント14はIPv6専用サーバ30と通信できない)。ネットワーク300における全ての可能な通信は、関連するIPバージョン(列2)を有する所定のクライアント(列1)が、関連するIPバージョン(列4)を有する何のサーバ(列3)と直接的に又はトンネルを用いて通信可能であるかを示すことにより、以下の表(I)にまとめられている。
【００３７】
【表１】
2006511152.tif 000003
表(I)を参照すると、IPv4専用クライアント14は、IPv4専用サーバ又はIPv6/IPv4サーバ19、20、22に連絡することができるが、IPv6専用であるサーバ26、30に連絡することができないことが示されている。IPv6/IPv4クライアント34は全てのサーバ(すなわちサーバ19、20、22、26、30)に連絡することができ、対応するサーバにより使用されるIPv4又はIPv6に自動的に適合することができる。IPv6専用クライアント36はIPv6専用サーバ又はIPv6/IPv4サーバ22、26、30に連絡することができるが、IPv4専用であるサーバ19、20に連絡することができない。
【００３８】
図３の例示的な異種IPv6/IPv4ネットワーク300を使用して、ネットワークでクライアントからサーバのアクセスを要求する処理について説明する。図２の異種ネットワーク200と比較して、図３の異種ネットワーク300ではこの処理はかなり複雑になる点に留意すべきである。この例示的な例では、IPv6/IPv4ノード(例えばクライアント34)は、ネットワーク300のそれぞれIPv4専用ノード、IPv6/IPv4ノード及びIPv6専用ノードであるサーバ19、20、22、26、30のいずれかに連絡しようとしてもよい。前記の例のように、ノードに連絡する(すなわち、IPv6/IPv4クライアント34がネットワークのサーバに連絡する)最初のステップは、最初にベンダポータル18に連絡し、サーバのホスト名のリストを取得することである。次に、クライアント34に関連するユーザは、返信されたリストからサーバのホスト名の１つを選択し、それによって、クライアントはDNS要求を行い、選択されたサーバのホスト名をバイナリIPアドレスにマッピングして、クライアント34が選択されたサーバと通信を始めることを可能にする。
【００３９】
全てのDNSサーバがIPv6レコード(すなわち、A6又はAAAAレコード)をサポートするようにアップグレードされていることを仮定すると、DNSサービスはクライアント34に以下を返信する。
・IPv4専用サーバ19又は20が選択された場合には、(少なくとも１つの)IPv4アドレス
・IPv6/IPv4サーバ22が選択された場合には、(少なくとも１つの)IPv6(及びIPv4)アドレス(サーバ22がDNSサーバにどのように登録されているかに応じて１つ又は２つのアドレスが返信されてもよい。6to4機構に従って単一のIPv6アドレスでもよく、双方ともIPv4アドレス及びIPv6アドレスでもよい。)
・IPv6専用サーバ26又はIPv6専用サーバ30が選択された場合には、(少なくとも１つの)IPv6アドレス
IPアドレスがDNSサーバから取得されると、クライアント34は以下のものと通信を開始することができる。
・IPv4パッケージを使用したIPv4専用サーバ19又は20
・IPv4にカプセル化された(すなわちトンネリングが適用される)IPv4パッケージ又はIPv6パッケージを使用したIPv6/IPv4サーバ22。後者の場合、トンネルの開始点は、IPv6/IPv4クライアント34であり、トンネリングの終点はサーバ22である(すなわち、これはホスト・ホストの6to4自動構成トンネリング(RFC2893参照)である)。
・IPv4にカプセル化された(すなわちトンネリングが適用される)IPv6パッケージを使用したIPv6専用サーバ26。後者の場合、トンネルの開始点は、IPv6/IPv4クライアント34であり、トンネリングの終点はサーバ22(サーバ26のルータ)である(すなわち、これはホスト・ルータの6to4自動構成トンネリング(RFC2893参照)である)。
・IPv4にトンネリングされたIPv6パッケージを使用したIPv6専用サーバ30。トンネルの開始点は、IPv6/IPv4クライアント34であり、トンネリングの終点はIPv6/IPv4中継ルータ28である。後者の場合は6to4中継ルータであり、RFC3068に定められる6to4ルータのエニキャストのプレフィックスを使用することにより、自動的に検出可能である。これは、クライアント34が2002:c058:6301::/48に等しいデフォルト中継ルータのプレフィックスで構成されることを示す。このプレフィックスはIPv4アドレス192.88.99.1に対応する。
【００４０】
異種ネットワークについて前述したアドレッシング機構は、全てのDNSサーバがIPv4からIPv6への移行時にIPv6レコード(すなわちA6又はAAAAレコード)をサポートするようにアップグレードされていることを仮定した。しかし、IPv4からIPv6への移行時にIPv4レコードのみ(すなわちAレコードのみ)をサポートする“レガシー”DNSサーバが存在する可能性がかなりあるという点で、この仮定は非現実的なことがある。例えば、例示的なネットワーク300において、IPv6専用サーバ26又はIPv6専用サーバ30用のプライマリ及びセカンダリDNSサーバがIPv4レコードのみをサポートしており、A6レコードをサポートしていない場合、サーバ26又は30のホスト名を解決するDNS要求を送信するIPv6/IPv4クライアント34は失敗になり、ほとんどの場合にはタイムアウトのため中断される。
【００４１】
本発明は、IPv4レコードのみをサポートする特定のDNSサーバのこの‘レガシー’の問題を克服することを対象とする。特に、本発明は、DNSサーバがIPv4レコードのみをサポートするレガシーDNSサーバであるため、移行機構としてトンネリングのみをサポートする通信ネットワークにある要求クライアントが、DNSサーバを介してホスト名が解決不可能なサーバと通信を設定することを可能にする方法を開示する。
【００４２】
Ｄ．実施例
前述の理由で及びここに明示的に記載されていない他の理由で、DNSサーバを介して解決不可能なホスト名の解決は、本発明の実施例に従って得られる。広く言えば、サーバのホスト名の解決は、ベンダポータル18からのサポート又は協力で、クライアントにより実現される。ベンダポータル18は、２つの新規なテーブル(ここでサーバのホスト名テーブルと呼ばれる第１のテーブルと、ここでHostname2IPaddressテーブルと呼ばれる第２の関連テーブル)を維持することによりサポートを提供する。
【００４３】
サーバのホスト名テーブル50及びHostname2IPaddressテーブル40の例示的な構成が図４に示されている。これらのテーブルはポータル18に格納されることが好ましい。図４に示すように、サーバのホスト名テーブル50は３つの列で構成される。“ホスト名”51というラベルの第１の列は、ベンダポータル18に既知の全てのサーバのホスト名を記載している。“IPアドレスバージョン”53というラベルの第２の列は、サーバのアドレスのIPバージョン(すなわち、IPv4専用、IPv6/IPv4又はIPv6専用)を記載している。“DNSを介して取得可能なIPアドレス”55というラベルの第３の列は、対応するサーバのIPアドレスがDNSサーバを介して解決可能か否か(例えばyes/no)を記載している。各サーバは、ベンダポータル18に登録すると、テーブル50にエントリーを提供することができると考えられる。情報は登録のために必須になってもよい。サーバがDNSサーバにより(又は何らかの理由で)到達可能でない場合、アクセスの保証としてベンダポータル18に少なくとも１つの有効なIPアドレスを指定するべきである。この情報は、図４に示すHostname2IPaddressテーブル40と呼ばれる本発明の第２のテーブルで維持される。Hostname2IPaddressテーブル40は３つの列で構成される。“ホスト名”41というラベルの第１の列は、ホスト名がDNSを介してIPアドレスに解決できないサーバのホスト名テーブル50からのサーバのホスト名を記載している。例示的な例では、これはサーバ26とサーバXを有する。“IPアドレス”43というラベルのテーブル40の第２の列は、サーバへのアクセスの保証として少なくとも１つの有効なIPアドレスを記載している。“中継ルータ”45というラベルのHostname2IPaddressテーブル40の第３の列は、(必要に応じて)中継ルータの識別表示を示している。ネイティブIPv6アドレスを備えたサーバがいくつかの特定の中継ルータアドレスを認識している場合、サーバはベンダポータル18に対してそれを指定し、この情報がテーブル40の列45に格納される。
【００４４】
所定のホストが6to4アドレスを有する場合、インターネットの如何なる場所で6to4を使用して他のホストとパケットを交換することができ、そのため、中継ルータの方法は不要である。例えば、クライアント36又は36は中継ルータなしにサーバ22又は26と通信することができる。しかし、6to4互換のないネイティブのグローバルIPv6アドレスを有するIPv6専用ノードとの通信は、6to4中継ルータ(RFC2373、2374参照)を必要とする。中継ルータは、6to4アドレスとネイティブIPv6アドレスとの間のルーティングの移行をサポートするように構成されている。図３において、クライアント34又は36は中継ルータ28を介してのみサーバ30と通信することができる。
【００４５】
クライアント(例えばクライアント14、34又は36のうちの１つ)とベンダポータル18との間の相互作用は、以下のルールに従って進む。
【００４６】
クライアントとポータル18との間で最初の接続が確立されると、クライアントはベンダポータル18からサーバのホスト名テーブル50を取得する。クライアントはそのIPバージョン(例えばクライアント36ではIPv6専用)を認識しており、そのため、ポータル18により提供されたテーブル50の第１の列51に記載されたサーバを内部でフィルタリングし、通信可能であると決定されたサーバのみを保持する。テーブル50の列51に記載されたサーバのホスト名をフィルタリングすることは、テーブル50の第２の列53で提供される情報に基づく。この例では、IPv6専用クライアント36はテーブル50の列51の６つのホスト名のリストをフィルタリングし、リストから２つのホスト名を除外し、４つのホスト名(すなわち、IPv6専用サーバ26、30、X及びIPv6/IPv4サーバ22)を保持する。サーバ19及び20は、IPv6専用クライアント36がIPv4専用サーバと通信を確立できないという決定に基づいて除外される。
【００４７】
次のステップで、クライアント36は、標準的なユーザインタフェースを介して、サーバのホスト名のフィルタリングされたリストを関連するユーザに提示する。関連するユーザは、フィルタリングされたリストからサーバのホスト名のうちの１つを選択してもよい。選択されたサーバのIPアドレスがDNSサーバを介して取得可能である場合(すなわち、テーブル50の第２の列55で‘yes’のインジケータのとき)、クライアント36はサーバのホスト名を従来通り解決するようにDNS要求を進める。そうでない場合、選択されたサーバのIPアドレスがDNSサーバを介して取得可能でないとき(すなわち‘no’のインジケータのとき)、クライアントは、ここで“HelpMeToGetIPaddress(ホスト名)”と呼ばれる特別のプロトコルをポータル18で実行する。この例では、フィルタリングされたリストからクライアント36がサーバ22を選択すると、そのIPアドレスがDNSサーバを介して取得可能になる。代替として、フィルタリングされたリストからクライアント36がサーバ26を選択すると、そのIPアドレスがDNSサーバを介して取得可能でなく、この場合にプロトコルが起動されなければならない。プロトコルは、関連するテーブル40を使用することを有する。具体的には、プロトコルは、検索キー又はインデックスとして選択されたサーバ(例えばサーバ26)のホスト名を使用して、ポータル18がテーブル40の第１の列41で照合を実行し、テーブル40の各レコードの第２の列43に格納されたサーバの１つ以上のIPアドレスを決定することを有する。必要に応じて、対応する中継ルータが、テーブル40の第３の列45から決定される。
【００４８】
図５は、クライアントが異種IPv6/IPv4ネットワークで要求サーバにアクセスすることを可能にするアルゴリズムを示したフローチャートであり、サーバのIPアドレスはDNSサービスにより解決可能でもよく、解決不可能でもよい。図３のIPv6/IPv4ネットワーク300を続けて参照する。説明において、クライアントとは、図３のネットワークのクライアント14、34又は36のうちいずれか１つを示す。ポータルとは、図３のベンダポータル18を示し、テーブル50及び40はベンダポータル18によりサポートされている。
【００４９】
ステップ52において、クライアントは、ポータル18からサーバのホスト名テーブル50を取得し、テーブル50の第１の列51に格納されたサーバの提供されたリストをフィルタリングする。フィルタリングは、クライアントにより使用されるIPバージョンと、リストの各サーバにより使用されるIPバージョンとを比較することにより実行される。具体的には、テーブル50のエントリー(レコード)毎に、クライアントのIPバージョンがテーブル50のサーバのIPバージョン(第２の列53に定められるもの、すなわち“IPアドレスバージョン”)に対して比較される。IPバージョンがクライアントとサーバとの間で通信が可能であるものである場合、サーバはフィルタリングされたリストに保持され、そうでない場合にはサーバが除外される。クライアントは、ユーザインタフェース介して、クライアントの関連するユーザにサーバのホスト名のフィルタリングされたリストを提示する。
【００５０】
ステップ54において、クライアントに関連するユーザは、表示中のフィルタリングされたリストから１つのサーバのホスト名を選択してもよい。
【００５１】
ステップ56において、クライアントは、テーブル50の第３の列55を介して、選択されたサーバのIPアドレスがDNSサーバを介して取得可能であるか否かを検査する。“YES”である場合、アルゴリズムはステップ60に進み、そうでない場合にはアルゴリズムはステップ70に進む。
【００５２】
ステップ60において、クライアントは、選択されたサーバのホスト名のIPアドレスを返信するようにそのデフォルトDNSサーバに要求し、アルゴリズムはステップ62に進む。
【００５３】
ステップ62において、クライアントは、選択されたサーバの１つ以上のIPアドレスを取得する。サーバが１つのIPアドレス以上で登録されている場合(例えば、２つのIPv4アドレス、又はIPv4及びIPv6アドレス)には、DNSサーバはその全てを返信することに留意すべきである。次に、アルゴリズムはステップ80に進む。
【００５４】
ステップ70において、クライアントは、前述のように、ポータル18で“HelpMeToGetIPaddress(ホスト名)”プロトコルを実行し、サーバのデフォルトIPアドレス及び何らか関連するルータ情報を取得する。
【００５５】
ステップ72において、クライアントは、ステップ70で起動された“HelpMeToGetIPaddress(ホスト名)”プロトコルの出力として、サーバのIPアドレス及び(必要な場合には)対応する中継ルータを取得する。次に、アルゴリズムはステップ80に進む。
【００５６】
ステップ80において、クライアントは、DNS要求又は“HelpMeToGetIPaddress(ホスト名)”プロトコルの出力として返信されたアドレスがそのアドレスと同じIPバージョンであるか否かを検査する。“yes”である場合、アルゴリズムはステップ82に進み、そうでない場合にはアルゴリズムはステップ84に進む。
【００５７】
ステップ82において、クライアントはIPアドレスがIPv6アドレスであるか否かを検査する。“yes”である場合、アルゴリズムはステップ100に進み、そうでない場合にはアルゴリズムはステップ90に進む。
【００５８】
ステップ84において、クライアントはDNS又は“HelpMeToGetIPaddress(ホスト名)”プロトコルにより返信された次のアドレスを選択し、ステップ80に戻る。ステップ52で実行されたサーバのフィルタリングのため、クライアントが通信するために使用可能な少なくとも１つのサーバのIPアドレスが存在することに留意すべきである。
【００５９】
ステップ90において、クライアントはIPv4を使用してサーバと通信する。
【００６０】
ステップ100において、クライアントとサーバとのIPv6アドレスが6to4機構(RFC3056参照)に従って構成されているか否か(すなわち、プレフィックスの最初の16ビットが2002と等しいか)を検査する。“Yes”の場合、アルゴリズムはステップ102に進み、そうでない場合には、アルゴリズムはステップ104に進む。
【００６１】
ステップ102において、クライアントはIPv6及び6to4自動構成トンネリング(RFC2893参照)を使用してサーバと通信する。
【００６２】
ステップ104において、トンネルの終点が常に中継ルータであるため、クライアントはIPv6及び自動構成トンネリング(RFC2893参照)を使用してサーバと通信する。中継ルータが6to4である場合、RFC3068に定められる6to4ルータのエニキャストのプレフィックス2002:c058:6301::/48を使用することにより、それが自動的に検出され得る。中継ルータが6to4でなく、クライアントがステップ72を実行した場合には、中継ルータのアドレス／プレフィックスはポータル18によりテーブル40から取り出され、“HelpMeToGetIPaddress(ホスト名)”プロトコルを実行した出力としてクライアントに返信される。
【００６３】
最後に、前述の説明は単に本発明の例示であることを目的としており、本発明の何らか特定の実施例又はグループに特許請求の範囲を制限するものとして解釈されるべきではない。従って、本発明についてその特定の例示的な実施例を参照して特に詳細に説明したが、特許請求の範囲に示す本発明の広い対象の要旨及び範囲を逸脱することなく、多数の変更及び変形が行われ得ることがわかる。従って、明細書及び図面は例示的なものとみなされ、特許請求の範囲を制限することを意図するものではない。
【００６４】
特許請求の範囲を解釈する際に、以下のことがわかる。
【００６５】
a)“有する”という用語は、所定の請求項に記載されたもの以外の要素又は動作の存在を除外するものではない。
【００６６】
b)要素に先行する先行詞は、そのような要素の複数の存在を除外するものではない。
【００６７】
c)請求項内の如何なる参照符号も特許請求の範囲を限定しない。
【００６８】
d)複数の“手段”が、構成又は機能を実装した同じアイテム又はハードウェア若しくはソフトウェアにより行われてもよい。
【００６９】
e)開示された要素のそれぞれは、ハードウェア部分(例えば別個の電子回路)、ソフトウェア部分(例えばコンピュータプログラム)又はその何らかの組み合わせで構成されてもよい。
【図面の簡単な説明】
【００７０】
【図１】クライアントが異種IPv4ネットワークで要求サーバにアクセスすることを可能にすることに関与するステップを示したフローチャート
【図２】従来技術による異種IPv4ネットワークの図
【図３】本発明の方法が実行され得る異種IPv6/IPv4ネットワークの図
【図４】図２のネットワークのポータルに提供されるサーバのホスト名テーブル及びHostname2IPaddressテーブルの例示的な構成
【図５】サーバのIPアドレスがDNSサービスにより取得可能又は取得不可能である場合の、クライアントが異種IPv6/IPv4ネットワークで要求サーバにアクセスすることに関与するステップを示したフローチャート
【図１】
2006511152.tif 000004
【図２】
2006511152.tif 000005
【図３】
2006511152.tif 000006
【図４】
2006511152.tif 000007
【図５】
2006511152.tif 000008
【国際調査報告】
2006511152.tif 000009
2006511152.tif 000010
2006511152.tif 000011