JP2013535905A - ネットワーク通信の方法および機器 - Google Patents

Abstract

【課題】ネットワーク通信の方法および機器。
【解決手段】該方法において、端末が、ＩＰｖ６アプリから送信したＩＰｖ６情報を受信すると、上記ＩＰｖ６情報をＩＰｖ４情報にトランスレートし、上記ＩＰｖ４情報付きのＩＰｖ６アプリ要求を送信するステップと、上記端末が、上記ＩＰｖ６アプリ要求に対応するＩＰｖ６アプリ応答を受信するステップとを含む。本発明の実施例において、ＩＰｖ４網内のＩＰｖ６アプリと他のIＰアドレスファミリサービスとの自由な相互通信が実現されている。
【選択図】図１

Description

本願は、２０１０年７月２８日に中国特許庁に提出した出願番号２０１０１０２３９８５７．０、発明の名称が「ネットワーク通信の方法および機器」の中国特許出願の優先権を主張し、その全内容を引用によって本願に取り入れる。
本発明は、通信技術分野に係り、特にネットワーク通信の方法および機器に関する。

世界的にＩＰｖ４（Internet Protocol version ４）アドレスの枯渇化、および端末の「常時接続」へのサービスの要求に伴い、ＩＰｖ６（Internet Protocol version ６）技術の展開が必然となる。

ＩＰｖ６技術の展開と順調な移行を実現するために、ＩＰｖ６技術の導入策略と応用場面について設定を行う必要がある。ＩＰｖ６網の概念を一歩一歩導入するために、ＩＰｖ６網およびＩＰｖ４／ＩＰｖ６デュアルスタック網の構築が、ＩＰｖ６技術展開の第一歩となる。

具体的に、ＩＰｖ６技術の進化について、ＩＥＴＦ（The Internet Engineering Task Force）により一連の適切で実行可能な理論的予測をし、ＩＰｖ６の進化につき主に下記三つの段階に分けると指摘した。
段階１：ＩＰｖ６進化の初期段階
該段階において、ネットワークにおける大部分のサービス提供は、まだＩＰｖ４に基づくものである。ＩＰｖ６への移行を実現するために、各種類のＩＰｖ６への移行技術（例えばトンネリング、トランスレーション、デュアルスタック技術など）が徐々にネットワークにおいて実施され、ネットワークにおけるＩＰｖ６の関連トラフィックが次第に増加する。
段階２：ＩＰｖ４／ＩＰｖ６技術共存段階
該段階において、インターネットサービス事業者が同時にユーザに対してＩＰｖ４サービスとＩＰｖ６サービスをそれぞれ提供し、ユーザが具体的な状況に応じて所望のサービスの種類を判断して選択できる。また、該段階において、ＩＰｖ６展開規模は徐々に増加し、ＩＰｖ４同様に豊富なサービス資源を有する。
段階３：ＩＰｖ６技術進化の後期
該段階において、ネットワークにおけるサービスはＩＰｖ６がメインとなり、ＩＰｖ４サービスの提供範囲が次第に縮小し、ＩＰｖ６網がインターネットの主要なネットワーキング技術形態となり、ＩＰｖ４網の範囲が萎縮し、インターネット網のＩＰｖ６への移行が完成する。

ＩＰｖ６サービス提供方式は、徐々に将来のインターネットが提供する主流方式となり、ＩＰｖ６への移行の中後期では、ＩＰｖ６ only網が現れることにつれて、ＩＰｖ６技術のみをサポートするアプリがインターネットサービスの主要提供方式となる。このような場合には、ＩＰｖ６をサポートできない旧機器がネットワークに存在することや、一部のプロバイダがＩＰｖ６へのグレードアップコストを考慮してＩＰｖ６アプリをサポートできないなどの理由により、ＩＰｖ４網が徐々に減退するものの、ＩＰｖ４技術とネットワークが消えてなくなるまでは依然として長い時間がかかる。

したがって、ＩＰｖ６アプリがＩＰｖ４網においても実行して動作できるようにすることが必要である。しかし、従来技術での解決策において、ＩＰｖ６アプリがＩＰｖ４網を介して通信するという技術的問題を有効的に実現できていない。

本発明は、ＩＰｖ６アプリがＩＰｖ４網を介して通信することを実現するネットワーク通信の方法および機器を提供する。

上記目的を実現するために、本発明は、ネットワーク通信の方法を提供し、端末が、ＩＰｖ６アプリから送信したＩＰｖ６情報を受信すると、上記ＩＰｖ６情報をＩＰｖ４情報にトランスレートし、上記ＩＰｖ４情報付きのＩＰｖ６アプリ要求を送信するステップと、上記端末が、上記ＩＰｖ６アプリ要求に対応するＩＰｖ６アプリ応答を受信するステップとを含む。

本発明によるネットワーク通信の方法は、端末がＩＰｖ６アプリ情報を受信し、上記ＩＰｖ６アプリ情報をデュアルスタックサーバに送信し、上記デュアルスタックサーバにより返信される上記ＩＰｖ６アプリ情報に対応するサービスデータを受信することを含む。
本発明によるネットワーク通信の機器は、ＩＰｖ６アプリから送信したＩＰｖ６情報を受信すると、上記ＩＰｖ６情報をＩＰｖ４情報にトランスレートするためのトランスレートモジュールと、上記ＩＰｖ４情報付きのＩＰｖ６アプリ要求を送信するための送信モジュールと、上記ＩＰｖ６アプリ要求に対応するＩＰｖ６アプリ応答を受信するための受信モジュールと含む。

本発明によるゲートウェイ機器は、端末からのトランスレーション後のＩＰｖ４要求情報を受信するための第１受信モジュールと、上記ＩＰｖ４要求情報に対応するＩＰｖ６要求をＩＰｖ６網における機器に送信するための第１送信モジュールと、上記ＩＰｖ４要求情報に対応するＩＰｖ６要求に対してＩＰｖ６網における機器から返信されるＩＰｖ６応答を受信するための第２受信モジュールと、上記ＩＰｖ６応答に対応するＩＰｖ４応答をＩＰｖ４網における端末に送信するための第２送信モジュールとを含む。

本発明によるネットワーク通信の機器は、ＩＰｖ６アプリ情報を受信すると、上記ＩＰｖ６アプリ情報をデュアルスタックサーバに送信するための送信モジュールと、上記デュアルスタックサーバにより返信される上記ＩＰｖ６アプリ情報に対応するサービスデータを受信するための受信モジュールとを含む。

従来技術と比べ、本発明の実施例のほうが少なくとも以下の利点を有する。すなわち、ＩＰｖ４網におけるＩＰｖ６アプリと他のIＰアドレスファミリサービスとの自由な相互通信が実現されていることである。

本発明の実施例または従来技術における技術的解決策をより明確に説明するために、以下、実施例または従来技術の記載に使用される図面を簡単に紹介する。以下の記載に係る図面が本発明のいくつかの実施例に過ぎず、当業者にとって、創造性を要する作業なしにこれらの図面に基づいて他の図面も取得可能であることは明らかである。
本発明の実施例１によるネットワーク通信の方法のフローを示す図面である。 本発明の実施例の応用場面におけるシステムアーキテクチャーを示す図面である。 本発明の実施例２によるＩＰｖ６アプリがＩＰｖ６サーバにアクセスする機能的フローを示す図面である。 本発明の実施例３によるＩＰｖ６アプリがＩＰｖ４サーバにアクセスする機能的フローを示す図面である。 本発明の実施例４によるＩＰｖ６アプリがデュアルスタックサーバにアクセスする機能的フローを示す図面である。 本発明の実施例によるネットワーク通信の機器構造図である。 本発明の実施例によるネットワーク通信の機器構造図である。 本発明の実施例によるネットワーク通信の機器構造図である。

ＩＰｖ４技術とネットワークが消えてなくなるまで依然として長い時間がかかり、かつＩＰｖ６アプリが快速に発展しているため、ＩＰｖ６アプリがＩＰｖ４網において実行して動作できることが必要である。また、ＩＰｖ６アプリがＩＰｖ４網を介して通信するというニーズは、移動ネットワークの運営にもある。

移動ネットワークにおいてＲ８までの端末が一つのＰＤＰ（Packet Data Protocol）コンテキストにＩＰｖ４アドレスとＩＰｖ６アドレスを同時に取得することができず、ＩＰｖ４アドレスとＩＰｖ６アドレスの配信を実現するには、二つのＰＤＰをそれぞれ活性化するしかできない。

移動ネットワークにおいてＲ８までの移動端末数が多く、移動ネットワークの運営資源を節約するために、端末が、通信する前に一回のＰＤＰコンテキストのみを活性化してよく、すなわち端末が一つのアドレスのみを取得し、通常はＩＰｖ４アドレスを取得する。端末がＩＰｖ６へのサービス要求を送信する際に、異なるアドレスファミリの間のアプリが通信できないため、端末は、ＩＰｖ６通信を満足するにはもう一つのＰＤＰを活性化することを余儀なくされる。その際、ＩＰｖ６アプリがＩＰｖ４網を介して通信する機能を採用すれば、端末がＰＤＰを一回だけ維持することで端末の各種類の通信ニーズを満足できるようになる。

以上の要素を考慮し、ＩＰｖ６移行段階において、ＩＰｖ４網でのＩＰｖ６アプリのアクセスとアプリレイヤでの相互通信を解決することは、ＩＰｖ６移行時に考慮すべき重要な問題である。該問題について、解決策は、端末側に基づく解決策とネットワーク側に基づく解決策に分けられる。

端末側に基づく解決策では、Ｔｅｒｅｄｏ（ＩＰｖ６向けＩＰｖ４のＮＡＴ横断）により、ＮＡＴ（Network Address Translation）の後にあるノードが全体的なＩＰｖ６接続を得られる。その核心的な思想として、ＩＰｖ６のパケットをＩＰｖ４ ＵＤＰ（User Datagram Protocol）パケットのペイロードにカプセル化してＮＡＴ機器を横断することであり、Ｔｅｒｅｄｏの展開においてＴｅｒｅｄｏ ｓeｒｖｅｒ（サーバ）とＴｅｒｅｄｏ Ｒeｌａｙ（中継）の協力が必要である。

ネットワーク側に基づく解決策では、主に６ｔｏ４技術と６ｏｖｅｒ４などの技術がある。６ｔｏ４トンネリング技術により、ＩＰｖ６相互接続サービスを提供するインターネットサービス事業者がない条件で、孤立サイトが他の孤立サイトおよびＩＰｖ６基幹網内部の各サイトと通信する問題を実現した。

６ｔｏ４移行技術は、自動トンネリング仕組みを採用しており、サイトで特殊なＩＰｖ６アドレス（２００２：ＩＰｖ４ＡＤＤＲ：：／４８）の採用が要求される。このようなＩＰｖ６アドレスは、サイトのＩＰｖ４アドレスから自動的に派生してきたものであるため、６ｔｏ４仕組みを採用する各サイトには、少なくとも世界的に一義的なＩＰｖ４アドレスを有しなければならない。

このような仕組みでは、トンネルエンドポイントのＩＰｖ４アドレスがＩＰｖ６アドレスから抽出できるため、トンネルの構築は自動的に行われる。受信側の６ｔｏ４ルータにとって、トンネル受信エンドポイントが本域内にあるかを自動的に区別できる。６ｔｏ４はＩＰｖ４のルーティングテーブルに新しいエントリを導入することはない。

また、６ｏｖｅｒ４により解決しようとする問題が６ｔｏ４に類似しており、ただ実施形態が異なる。６ｏｖｅｒ４の場合、ＩＰｖ４マルチキャスト自動トンネリング仕組みを採用する。６ｏｖｅｒ４トンネリングは、ネットワーク内部の、異なるサブネットに位置しかつＩＰｖ６ルータの直接接続がないＩＰｖ６ホストを、マルチキャスト仕組みを介してバーチャルのリンクに接続して、論理的な同一サブネットを形成する。その核心的な思想として、ＩＰｖ６マルチキャストアドレスをＩＰｖ４マルチキャストアドレスにマッピングし、他のＩＰｖ６ホストによるＩＰｖ４アドレスの探索と境界ルータＩＰｖ４の探索を、近隣探索におけるルータ要求／宣告、近隣要求／宣告工程を介して完成させることである。

ＩＰｖ６にとって、ＩＰｖ４マルチキャスト域全体がバーチャルイーサネット（登録商標）（virtual Ethernet（登録商標））である。６ｏｖｅｒ４移行技術は、６ｔｏ４トンネリングとの異なる点として、６ｏｖｅｒ４には特殊形式のＩＰｖ６アドレスを必要としないことであり、ＩＰｖ４マルチキャスト域が世界的に一義的なＩＰｖ４アドレスを採用するネットワークであるか、プライベートのＩＰｖ４ネットワークの一部であってもよく、ＩＰｖ６が下位層のリンクから独立でき、かつＩＰｖ４のサブネットを跨ぐことができる。

６ｏｖｅｒ４仕組みを採用する前提として、ＩＰｖ４網の基礎施設が必ずＩＰｖ４マルチキャストをサポートすることである。このような仕組みは、ＩＰｖ６ルータの直接接続がない物理リンク上の孤立ＩＰｖ６ホストに適用するものであり、ＩＰｖ６ホストがＩＰｖ４マルチキャスト域をバーチャルリンクとすることができ、完全に機能できるＩＰｖ６サイトとなる。

なお、Ｔｅｒｅｄｏの実施中に、Ｔｅｒｅｄｏ仕組みは、アドレスにＩＰｖ４マッピングアドレスとポートを嵌め込んだため、特別なアドレスプレフィックスによりＩＰｖ６階層型ルーティング体系を壊し、ＩＰｖ６のルーティング拡張可能に関する問題が生じる。また、Ｔｅｒｅｄｏの実施中に、Ｔｅｒｅｄｏ中継器とＴｅｒｅｄｏサーバのサポートが必要であり、かつＩＰｖ６アプリにアクセスするパケットが全てＴｅｒｅｄｏサーバで処理されるため、Ｔｅｒｅｄｏのデータルーティングが常に最適化でないものとなる。Ｔｅｒｅｄｏユーザの増加につれて、Ｔｅｒｅｄｏサーバの処理負荷が徐々に上昇し、さらに一連の安全上の問題が生じる虞がある。また、Ｔｅｒｅｄｏが対称状のＮＡＴを横断できないため、該当するＮＡＴ場面ではＴｅｒｅｄｏが動作できない。

６ｔｏ４技術は一般的に境界ルータにおいて実現されるため、境界ルータが６ｔｏ４技術対応可能であることが必要となり、６ｔｏ４技術の実施中に、一旦ＩＰｖ４アドレスに変化が生じると、全サイトのＩＰアドレスを改めて割り当てる必要があるため、例えばダイヤルによるアクセス、ｘＤＳＬ（Digital Subscribe Line）によるアクセス、ＤＨＣＰ（Dynamic Host Configuration Protocol）など、動的アドレス割り当ての状況には適用しない。また、６ｔｏ４技術も単一障害点問題が存在し、境界の６ｔｏ４ルータに故障があると、全サイトとの他のＩＰｖ６との通信が中断することとなる。

６ｏｖｅｒ４技術では、６ｏｖｅｒ４トンネルがデュアルプロトコルスタックを具備するホスト間の通信に適用する。ＩＰｖ４のマルチキャスト仕組みを利用してバーチャルリンクを作成するため、６ｏｖｅｒ４仕組みの実行は、ネットワークが必ずマルチキャスト技術をサポートできることが必要となる。しかし、現在マルチキャストをサポートするＩＰｖ４網が欠如し、かつ６ｔｏ４より６ｏｖｅｒ４があまり強みがないため、実際には６ｏｖｅｒ４の使用が極めて少ない。

また、上記技術はともにトンネリング技術に属するものであり、トンネリングに共有の欠点も有する。第一、ＩＰｖ６網移行中に、トンネリングカプセル化技術を採用することで、ＩＰヘッダが６０バイトまで長くなることをもたらす。モバイル事業者にとって、無線エアインタフェースが非常に価値がありかつ希少な資源であり、数億の移動端末数により、ネットワークの伝送負荷を相当な程度で増大させる。かつ、トンネリング技術はデータ通信前に確立して維持しなければならないため、コストが比較的に高い。第二、上記技術的解決策は、ともにネットワークの単一障害点およびネック現象が存在する。たとえば、Ｔｅｒｅｄｏ通信データは、Ｔｅｒｅｄｏサーバにより処理が必要であり、６ｔｏ４の技術的解決策の場合、特定な６ｔｏ４ルータによる処理が必要である。第三、トンネリング技術には多層データカプセル化ヘッダを採用したため、ＱｏＳ（Quality of Service）制御情報付きのデータヘッダ部が通常別のＩＰパケットにカプセルかされるため、ＱｏＳ策略実行ポイントでは、機器がＱｏＳ情報を識別できない。

以上の問題に対して、本発明の実施例は、ネットワーク通信の方法および機器を提供して、ＩＰｖ６アプリがＩＰｖ４網を介して通信することを実現し、ＩＰｖ６とＩＰｖ４アプリとの自由な通信ニーズを満足する。また、トンネリング移行仕組みによるエアインタフェース資源への影響を克服し、余分なエアインタフェース資源の消耗を回避する。さらに、ホストとホスト間の直接通信をサポートし、ネットワークの単一障害点およびネック現象を防止し、ＩＰｖ４ホストによるＩＰｖ６へのアクセス要求をサポートする。

以下、本発明の実施例における技術的解決策について、本発明の実施例にある図面を参照して明確且つ完全的な説明をする。明らかに、説明している実施例は、本発明の実施例のうちの一部のものであり、全ての実施例ではない。本発明の実施例における実施例に基づき、当業者が創造性を要する作業なしに取得した他の実施例は、全て本発明の実施例による保護範囲に含まれる。

図1に示すように、本発明の実施例１によるネットワーク通信の方法は、下記のステップを含む。

ステップ１０１において、端末は、ＩＰｖ６アプリから送信したＩＰｖ６情報を受信すると、上記ＩＰｖ６情報をＩＰｖ４情報にトランスレートし、上記ＩＰｖ４情報付きのＩＰｖ６アプリ要求を送信する。

ステップ１０２において、上記端末は、上記ＩＰｖ６アプリ要求に対応するＩＰｖ６アプリ応答を受信する。

本発明の実施例による技術的解決策を採用することにより、ＩＰｖ４網内のＩＰｖ６アプリと他のＩＰアドレスファミリサービスとの自由な相互通信を実現したことが分かる。

本発明の実施例による技術的解決策をより明確に説明するために、以下、本発明の実施例について具体的な応用場面を用いて詳細な説明をする。本応用場面において、図２に示すシステムアーキテクチャーを示す図面を例として説明する。

本応用場面において、ＩＰｖ６アプリがＩＰｖ４網を介して通信することを実現するために、本発明の実施例において、ＩＰｖ４端末（例えばＩＰｖ４ホスト）で関連機能を設けてＩＰｖ６アプリのパケットを処理し（もちろん、実際の応用時に、ＩＰｖ６アプリがＩＰｖ４網内に位置すればよく、ＩＰｖ４端末で行うことに限らない）、ドメイン名メッセージに対して相応な処理をすることにより、ＩＰｖ６アプリと網内のＩＰｖ４サーバ、デュアルスタックサーバおよびＩＰｖ６サーバとの自由な相互通信を実現する。

具体的に、ＩＰｖ６サーバとの相互通信を実現するために、本発明の実施例において、ＩＰｖ４網とＩＰｖ６網の境界にＮＡＴ４６ゲートウェイ（該ＮＡＴ４６ゲートウェイが独立した機器であってもよいし、ＮＡＴ４６ゲートウェイの関連機能を従来の機器に集積してもよく、本発明の実施例では独立した機器を例として説明する）を設けて関連するパケット処理を行う必要がある。

本応用場面において、ＩＰｖ４端末にホストトランスレートモジュール、ホストＤＮＳ代理モジュール、ＩＰｖ４−ＩＰｖ６マッピングアドレスプール機能モジュールを追加する必要があるが、これらに限らない。もちろん、実際の応用時に、上記各機能モジュールは、合併するか、さらにサブモジュールに分割することもできる。本応用場面において、上記三つの機能モジュールを例として説明する。

（１） ホストトランスレートモジュール
ＩＰｖ６アプリから発生したＩＰｖ６データからＩＰｖ４データへの変換を完成させるものである。

具体的に、ホストトランスレートモジュールは、ＩＰｖ６アプリから送信した情報を受信すると、ＩＰｖ６アドレスを含む応用情報をＩＰｖ４応用情報にトランスレートする必要があり、ＩＰｖ４網における情報伝送を実現する。

本応用場面において、ホストトランスレートモジュール機能の実行は、パケットヘッダトランスレートとソケット（Socket）トランスレートに基づくことができる。パケットヘッダトランスレートの実行は、ＩＰｖ６アプリから送信したＩＰｖ６パケットをモニターし、データのパケットヘッダをＩＰｖ４に変換することである。ソケットトランスレートの実行は、主にＩＰｖ６アプリから送信したＩＰｖ６システム呼び出しを傍受し、対応するＩＰｖ４システム呼び出しに変換し、ＩＰｖ４パケットの伝送を完成させることである。以上二種類の処理方法に基づき、ホストトランスレートモジュールは、送信元アドレスと宛先アドレスのＩＰｖ６からＩＰｖ４へのトランスレーションを実現した。

（１） ホストＤＮＳ代理モジュール
ＩＰｖ６から送信したＡＡＡＡ型付きのＤＮＳ要求の処理を実現するためのものである。ＩＰｖ６アプリと相手サーバとの自由な相互通信という目的を満足するために、ホストＤＮＳ代理モジュールは、下記の操作を実行する。

ＩＰｖ６からＡＡＡＡ型付きのＤＮＳ要求を送信した場合、ホストＤＮＳ代理モジュールは、ＡＡＡＡ型をＡＡＡＡ型とＡ型にトランスレートし、同時にＡＡＡＡ型とＡ型付きのＤＮＳ要求をネットワークに送信する。

ＩＰｖ６アプリのアクセス相手がデュアルスタックサーバである場合、ホストＤＮＳ代理モジュールは、ＤＮＳサーバから返信されるＡ型とＡＡＡＡ型付きのＤＮＳ回答を受信し、ＡＡＡＡ型付きのＤＮＳ回答を上位層のＩＰｖ６アプリに返信する。

ＩＰｖ６アプリのアクセス相手がＩＰｖ４サーバである場合、ホストＤＮＳ代理モジュールは、ＤＮＳサーバから返信されるＡ型付きのＤＮＳ回答を受信し、端末のＩＰｖ４とＩＰｖ６マッピングプールにマッピング記録を作成し、Ａ型記録をＡ型とＡＡＡＡ型記録にトランスレートし、トランスレーション後のＡＡＡＡ型付きのＤＮＳ回答を上位層のＩＰｖ６アプリに返信する。

ＩＰｖ６アプリのアクセス相手がＩＰｖ６サーバである場合、ホストＤＮＳ代理モジュールは、ＤＮＳサーバから返信されるＡＡＡＡ型付きのＤＮＳ回答を受信し、再びＡ型とＡＡＡＡ型付きのＤＮＳ要求をＮＡＴ４６ゲートウェイに送信し、ＮＡＴ４６ゲートウェイから返信されるＡ型とＡＡＡＡ型付きのＤＮＳ回答を待つ。

なお、ＤＮＳ要求類を送信するアプリについて、ＩＰｖ４ネット環境では、ＤＮＳサーバがフォワード解析をするときに、Ａ（ニーモニックコード）型の記録を処理し、ＩＰｖ６ネット環境では、ＤＮＳサーバがフォワード解析をするときに、ＡＡＡＡ（ニーモニックコード）型の記録を処理し、ＩＰｖ６とＩＰｖ４共存のネット環境では、ＤＮＳサーバがフォワード解析をするときに、Ａ型とＡＡＡＡ型の記録を処理する。Ａ型の記録は、ＩＰｖ４アドレスに対応する宛先名称をマッピングし、ホスト名、ＴＴＬ（time-to-live）、ＩＰｖ４ ＩＰアドレスなどを含む。ＡＡＡＡ型の記録は、ＩＰｖ６アドレスに対応する宛先名称をマッピングし、ホスト名、ＴＴＬ（time-to-live）、ＩＰｖ６ ＩＰアドレスなどを含む。

（３）ＩＰｖ４−ＩＰｖ６マッピングアドレスプール機能モジュール
ＩＰｖ６アプリがＩＰｖ４サーバにアクセスする場面では、ホストにおいてＩＰｖ４とＩＰｖ６記録を作成し、ホストＤＮＳ代理機能によりＡ型とＡＡＡＡ型付きのＤＮＳ回答を作成してＩＰｖ６アプリに返信することに協力する。

本応用場面では、ＩＰｖ６アプリとリモート側のＩＰｖ６網におけるサーバとのインタラクティブを実現するために、ＮＡＴ４６ゲートウェイ処理機能を用いてデータ情報のトランスレーションを完成させる必要がある。ＮＡＴ４６ゲートウェイにＩＰパケットヘッダトランスレート、ＤＮＳゲートウェイ代理、ＩＰｖ４−ＩＰｖ６マッピングアドレスプールのモジュールを追加する必要があるが、これらに限らない。もちろん、実際の応用時に、上記各機能モジュールは、合併するか、さらにサブモジュールに分割することもできる。本応用場面において、上記三つの機能モジュールを例として説明する。

（１）ＩＰパケットヘッダトランスレート
ＮＡＴ４６ゲートウェイ宛パケットの送信元アドレスと宛先アドレスをＩＰｖ４からＩＰｖ６へトランスレートすることに用いられる。

具体的に、ＮＡＴ４６ゲートウェイがパケットを処理する際にパケットの宛先アドレスをチェックするが、パケットがＮＡＴ４６ゲートウェイにより維持されるマッピングアドレス範囲内にある場合、ＩＰｖ４からＩＰｖ６へのトランスレーションを実行するが、逆の場合該パケットを直接転送し、ルーティング機能のみをサポートする。

（２）ＤＮＳゲートウェイ代理
ＮＡＴ４６ゲートウェイに送信するＤＮＳ要求の処理を実行することに用いられる。ＮＡＴ４６ゲートウェイは、自身宛のＤＮＳ要求を受信すると、ＡＡＡＡ型とＡ型の要求をＩＰｖ６網に転送して回答を待つ。

ＡＡＡＡ型の受信後、ＮＡＴ４６ゲートウェイは、ゲートウェイにおいてＩＰｖ６からＩＰｖ４へのマッピング記録を作成する必要がある。なお、ＩＰｖ４アドレスは、ネットワークにおいてＮＡＴ４６ゲートウェイ専用に取っておいたＩＰｖ４共有アドレスである。

本応用場面では、ＩＰｖ４アドレス節約の目的を考慮し、マッピングは、ポート多重形式で行われる。すなわち、一つの取っておいたＩＰｖ４共有アドレスで６５５３５個のＩＰｖ６アドレスを示すことができる。ネットワークの容量に応じて、ネットワーク管理者は、取って置きのＩＰｖ４アドレスについて計画をすることができる。

具体的に、取って置き情報に基づいて、ＤＮＳゲートウェイ代理は、ＡＡＡＡ型をＡＡＡＡ型とＡ型に解析し、ＮＡＴ４６ゲートウェイにおいてマッピング情報を取って置き、Ａ型とＡＡＡＡ型を同時にアドレス解析要求元のホストに返信する。

（３）ＩＰｖ４−ＩＰｖ６マッピングアドレスプール
主にＤＮＳにより作成したマッピング情報の維持の実現に用いられる。

以上の応用場面に基づき、本発明の実施例２において、ＩＰｖ６アプリがＩＰｖ６サーバにアクセスする機能的フローは、図３に示すように、下記のステップを含む。

ステップ３０１において、ＩＰｖ６アプリがＤＮＳ要求メッセージを送信する。該ＤＮＳ要求メッセージは、ＡＡＡＡ型に基づくＤＮＳ要求メッセージである。

該ＤＮＳ要求メッセージは、ＩＰｖ４網に送信される前に、端末のホストＤＮＳ代理モジュールに取得される。

ステップ３０２において、ホストＤＮＳ代理モジュールは、ＩＰｖ６ ＤＮＳ ＡＡＡＡ型要求メッセージを拡張させ、Ａ型とＡＡＡＡ型付きのＤＮＳ要求をＤＮＳサーバに送信する。該ＤＮＳサーバは、ＩＰｖ４網内のＤＮＳサーバである。

ステップ３０３において、ＤＮＳサーバは、ＡＡＡＡ型付きのＤＮＳ回答をホストＤＮＳ代理モジュールに返信する。

ＩＰｖ６アプリのアクセス相手がＩＰｖ６サーバであるため、ＤＮＳサーバがＡＡＡＡ型付きのＤＮＳ回答をホストＤＮＳ代理モジュールに返信する必要がある。

ステップ３０４において、ホストＤＮＳ代理モジュールは、ＡＡＡＡ型とＡ型付きのＤＮＳ要求を新たにＮＡＴ４６ゲートウェイに送信する。

具体的に、ホストＤＮＳ代理モジュールは、ＡＡＡＡ型のみの取得を確認すると、ＡＡＡＡ型とＡ型付きのＤＮＳ要求を新たにＮＡＴ４６ゲートウェイに送信する必要がある。

ステップ３０５において、ＮＡＴ４６ゲートウェイは、ＡＡＡＡ型とＡ型付きのＤＮＳ要求メッセージをＩＰｖ６網のＤＮＳサーバに送信する。

具体的に、ＮＡＴ４６ゲートウェイは、自身宛のＤＮＳ要求メッセージを受信すると、該ＤＮＳ要求メッセージをＩＰｖ６網のＤＮＳサーバに送信する必要がある。

ステップ３０６において、ＤＮＳサーバは、ＡＡＡＡ型付きのＤＮＳ回答をＮＡＴ４６ゲートウェイに返信する。

具体的に、ＤＮＳ要求メッセージを受信すると、ＩＰｖ６網のＤＮＳサーバがＡＡＡＡ型付きのＤＮＳ回答をＮＡＴ４６ゲートウェイに返信する必要がある。

ステップ３０７において、ＮＡＴ４６ゲートウェイは、ＡＡＡＡ型をＡ型とＡＡＡＡ型に解析し、ＩＰｖ６からＩＰｖ４へのマッピングを作成する。

具体的に、ＡＡＡＡ型付きのＤＮＳ回答を受信すると、ＮＡＴ４６ゲートウェイにおけるＤＮＳ代理がＡＡＡＡ型をＡ型とＡＡＡＡ型に解析してＮＡＴ４６ゲートウェイにおいてＩＰｖ６からＩＰｖ４へのマッピングアドレス記録を作成する必要がある。

また、ＮＡＴ４６ゲートウェイが維持するＩＰｖ４アドレスプール資源を節約するために、ＩＰｖ６からＩＰｖ４へのマッピングアドレス記録は、ポート多重化方式が採用される。

ステップ３０８において、ＮＡＴ４６ゲートウェイにおけるゲートウェイＤＮＳ代理は、解析後のＡ型とＡＡＡＡ型をホストにおけるホストＤＮＳ代理モジュールに返信する。

ステップ３０９において、ホストＤＮＳ代理モジュールは、ＡＡＡＡ型をＩＰｖ６アプリに返信する。

ステップ３１０において、ＩＰｖ６アプリは、ネットワークへの応用要求を送信する。

具体的に、ネットワークに送信した応用要求には、ＩＰｖ６アプリが採用する送信元アドレスは、端末自身パラメータのダミーアドレスであり、該アドレスが端末内のみで使用されるため、ネットワークに影響を与えることはない。

ステップ３１１において、ホストトランスレートモジュールは、ＩＰｖ６から送信した応用要求メッセージをモニターして傍受し、送信元アドレスと宛先アドレスをＩＰｖ６からＩＰｖ４にトランスレートする。送信元アドレスについて、ＩＰｖ６ダミーアドレスをホスト配置のＩＰｖ４アドレスにトランスレートする必要があり、宛先アドレスについて、ＩＰｖ６の宛先アドレスを、Ａ記録に対応するＩＰｖ４アドレスにトランスレートする必要がある。

ステップ３１２において、ホストトランスレートモジュールは、トランスレーション後のデータをＮＡＴ４６ゲートウェイに送信する。

ステップ３１３において、ＮＡＴ４６ゲートウェイは、ＩＰｖ４‐ＩＰｖ６マッピングアドレスプールの情報に基づいてＩＰｖ４アドレスをＩＰｖ６アドレスにトランスレートする。

具体的に、ＮＡＴ４６ゲートウェイが送信元ＩＰｖ４アドレスと宛先ＩＰｖ４アドレスをＩＰｖ６アドレスにトランスレートする必要がある。送信元アドレスについて、ＮＡＴ４６ゲートウェイにおいて特定なＩＰｖ６プレフィックスを配置し、該プレフィックスがＮＳＰの範囲に属する。送信元アドレスのＩＰｖ４アドレスとＮＳＰプレフィックスの組み合わせによりＩＰｖ６送信元アドレスを形成する。宛先アドレスについて、ＮＡＴ４６ゲートウェイがＩＰｖ４‐ＩＰｖ６マッピングアドレスプールの情報に基づいてＩＰｖ４アドレスをＩＰｖ６アドレスにトランスレートする。

ステップ３１４において、ＮＡＴ４６ゲートウェイは、トランスレーション後のデータをＩＰｖ６サーバに送信する。

ステップ３１５において、ＩＰｖ６サーバは、対応するサービスデータをＮＡＴ４６ゲートウェイに返信する。

ステップ３１６において、ＮＡＴ４６ゲートウェイは、サービスデータを受信すると、ＩＰｖ６アドレスをＩＰｖ４アドレスにトランスレートする。

本ステップにおいて、ステップ３１３の逆フローで対応な処理をする必要がある。具体的に、送信元アドレスについて、ＮＡＴ４６ゲートウェイは、ＩＰｖ６アドレスのうち、ＮＳＰ範囲に属する特別配置のＩＰｖ６プレフィックスを除去する。宛先アドレスについて、ＮＡＴ４６ゲートウェイがＩＰｖ４‐ＩＰｖ６マッピングアドレスプールの情報に基づいてＩＰｖ６アドレスをＩＰｖ４アドレスにトランスレートする。

ステップ３１７において、ＮＡＴ４６ゲートウェイがトランスレーション後のサービスデータをホストに送信し、ホストがＮＡＴ４６ゲートウェイから送信したデータを受信すると、全体的なサービスインタラクティブが完成する。

本発明の実施例３において、ＩＰｖ６アプリがＩＰｖ４サーバにアクセスする機能的フローは、図４に示すように、下記のステップを含む。

ステップ４０１において、ＩＰｖ６アプリがＤＮＳ要求メッセージを送信する。該ＤＮＳ要求メッセージは、ＡＡＡＡ型に基づくＤＮＳ要求メッセージである。

該ＤＮＳ要求メッセージは、ＩＰｖ４網に送信される前に、端末のホストＤＮＳ代理モジュールに取得される。

ステップ４０２において、ホストＤＮＳ代理モジュールは、ＩＰｖ６ ＤＮＳ ＡＡＡＡ型要求メッセージを拡張させ、Ａ型とＡＡＡＡ型付きのＤＮＳ要求をＤＮＳサーバに送信する。該ＤＮＳサーバは、ＩＰｖ４網内のＤＮＳサーバである。

ステップ４０３において、ＤＮＳサーバは、Ａ型付きのＤＮＳ回答をホストＤＮＳ代理モジュールに返信する。

ＩＰｖ６アプリのアクセス相手がＩＰｖ４サーバであるため、ＤＮＳサーバがＡ型付きのＤＮＳ回答をホストＤＮＳ代理モジュールに返信する必要がある。

ステップ４０４において、ホストＤＮＳ代理モジュールは、Ａ型をＡＡＡＡ型に解析してＩＰｖ４からＩＰｖ６へのマッピングを作成する。

具体的に、ホストＤＮＳ代理モジュールがＡ型付きのＤＮＳ回答を受信すると、上位層ＩＰｖ６アプリによるＤＮＳ回答メッセージの識別を実現するために、Ａ型をＡＡＡＡ型に解析し、ホスト上のＩＰｖ４−ＩＰｖ６アドレスマッピングプールにＩＰｖ４からＩＰｖ６へのマッピング記録を作成する必要がある。

アドレスマッピングプールにおいて、ホストがＩＰｖ６マッピングプールを維持してＩＰｖ４とマッピングを行う。外部のＩＰｖ６通信相手アドレスと衝突しないように、ＩＰｖ６マッピングプールが：：８／の範囲内にある。該範囲内のアドレスは、ＩＥＴＦにより取って置きのものであり、ネットワークに出現することはないので、衝突問題が生じることはない。

ステップ４０５において、ホストＤＮＳ代理モジュールは、解析したＡＡＡＡ型をＩＰｖ６アプリに返信する。

ステップ４０６において、ＩＰｖ６アプリは、ネットワークへの応用要求を送信する。

ネットワークに送信した応用要求には、ＩＰｖ６アプリが採用する送信元アドレスは、ホスト自身パラメータのダミーアドレスであり、該アドレスがホスト内のみで使用されるため、ネットワークに影響を与えることはない。ＩＰｖ６アプリが採用する宛先アドレスは、ホストＩＰｖ６アドレスプールにおいて作成されるアドレスである。

ステップ４０７において、ホストトランスレートモジュールは、ＩＰｖ６アドレスをＩＰｖ４アドレスにトランスレートする。

具体的に、ホストトランスレートモジュールは、ＩＰｖ６から送信した応用要求メッセージをモニターして傍受し、送信元アドレスと宛先アドレスをＩＰｖ６からＩＰｖ４にトランスレートする。送信元アドレスについて、ＩＰｖ６ダミーアドレスをホスト配置のＩＰｖ４アドレスにトランスレートする必要があり、宛先アドレスについて、ＩＰｖ６の宛先アドレスを、Ａ型記録に対応するＩＰｖ４アドレスにトランスレートする必要がある。

ステップ４０８において、ホストトランスレートモジュールは、トランスレーション後のデータをＩＰｖ４サーバに送信する。

ステップ４０９において、ＩＰｖ４サーバが応用要求メッセージを受信するとサービスデータを返信し、ホストがサーバから送信されるデータを受信すると、全体的なサービスインタラクティブが完成する。

本発明の実施例４において、ＩＰｖ６アプリがデュアルスタックサーバにアクセスする機能的フローは、図５に示すように、下記のステップを含む。

ステップ５０１において、ＩＰｖ６アプリがＤＮＳ要求メッセージを送信する。該ＤＮＳ要求メッセージは、ＡＡＡＡ型に基づくＤＮＳ要求メッセージである。

該ＤＮＳ要求メッセージは、ＩＰｖ４網に送信される前に、端末のホストＤＮＳ代理モジュールに取得される。

ステップ５０２において、ホストＤＮＳ代理モジュールは、ＩＰｖ６ ＤＮＳ ＡＡＡＡ型要求メッセージを拡張させ、Ａ型とＡＡＡＡ型付きのＤＮＳ要求をＤＮＳサーバに送信する。該ＤＮＳサーバは、ＩＰｖ４網内のＤＮＳサーバである。

ステップ５０３において、ＤＮＳサーバは、Ａ型とＡＡＡＡ型付きのＤＮＳ回答をホストＤＮＳ代理モジュールに返信する。

ＩＰｖ６アプリのアクセス相手がデュアルスタックサーバであるため、ＤＮＳサーバがＡ型とＡＡＡＡ型付きのＤＮＳ回答をホストＤＮＳ代理モジュールに返信する必要がある。

ステップ５０４において、ホストＤＮＳ代理モジュールは、ＡＡＡＡ型をＩＰｖ６アプリに返信する。

ステップ５０５において、ＩＰｖ６アプリは、ネットワークへの応用要求を送信する。

ネットワークに送信した応用要求には、ＩＰｖ６アプリが採用する送信元アドレスは、ホスト自身パラメータのダミーアドレスであり、該アドレスがホスト内のみで使用されるため、ネットワークに影響を与えることはない。ＩＰｖ６アプリが採用する宛先アドレスは、ＡＡＡＡ型に対応するＩＰｖ６アドレスである。

ステップ５０６において、ホストトランスレートモジュールは、ＩＰｖ６アプリ要求メッセージをデュアルスタックサーバに送信する。

ステップ５０７において、デュアルスタックサーバが応用要求メッセージを受信するとサービスデータを返信し、端末がサーバから送信されるデータを受信すると、全体的なサービスインタラクティブが完成する。

以上の記載をまとめると、本発明の各実施例による技術的解決策を採用することによれば、下記の利点を有する。

ＩＰｖ４網内のＩＰｖ６アプリと他のＩＰアドレスファミリサービスとの自由な相互通信を実現した。ＩＰｖ６網移行時に、ＩＰｖ６網には多種類のＩＰサービスが共存するが、これらのＩＰサービスは、事業者とインターネットサービスプロバイダにとって、価値を生み出す重要な手段であり、ユーザにとって、ユーザーエクスペリエンス向上の重要な資源である。したがって、ＩＰｖ４網内のＩＰｖ６アプリと他の種類のサービスとの相互通信により、サービスの柔軟性を大幅に向上させ、ユーザーエクスペリエンス向上に役立つ。

本発明の実施例を採用すれば、無線エアインタフェースの負担を軽減でき、ＩＰｖ６網移行中に、ＩＰ−ｉｎ−ＩＰカプセル化のトンネリング技術を採用することで、ＩＰヘッダが６０バイトまで長くなることをもたらす。まず、モバイル事業者にとって、無線エアインタフェースが非常に価値がありかつ希少な資源であり、数億の移動端末数により、ネットワークの伝送負荷を相当な程度で増大させる。また、トンネリング技術はデータ通信前に確立して維持しなければならないため、コストが比較的に高い。本発明の実施例による技術的解決策を採用することにより、ＩＰｖ６技術移行時に一部のエアインタフェースの消耗を減少させ、維持コストを減少させる。

また、本発明の実施例による技術的解決策は、ホストとホストとの直接通信をサポートできるため、ネットワークの単一障害点およびネック現象を防止した。

同様な発明の構想に基づき、本発明の実施例では、ネットワーク通信の機器も提供している。図６に示すように、ＩＰｖ６アプリから送信したＩＰｖ６情報を受信すると、上記ＩＰｖ６情報をＩＰｖ４情報にトランスレートするためのトランスレートモジュール１１と、上記ＩＰｖ４情報付きのＩＰｖ６アプリ要求を送信するための送信モジュール１２と、上記ＩＰｖ６アプリ要求に対応するＩＰｖ６アプリ応答を受信するための受信モジュール１３と含む。

上記ＩＰｖ６アプリから送信したＩＰｖ６情報には、ＡＡＡＡ型付きのＤＮＳ要求を含み、上記トランスレートモジュール１１は、具体的にＡＡＡＡ型付きのＤＮＳ要求をＡＡＡＡ型とＡ型付きのＤＮＳ要求にトランスレートすることに用いられ、上記送信モジュール１２は、具体的にＡＡＡＡ型とＡ型付きのＤＮＳ要求をＩＰｖ４網におけるＤＮＳサーバに送信することに用いられ、上記受信モジュール１３は、具体的に上記ＤＮＳサーバによりＩＰｖ６アプリのアクセス相手のサーバ種類に基づき返信されたＤＮＳ回答を受信することに用いられる。

該機器はさらに処理モジュール１４を含み、上記受信モジュール１３は、具体的に、ＩＰｖ６アプリのアクセス相手のサーバ種類がＩＰｖ４サーバである場合、ＤＮＳサーバにより返信されたＡ型付きのＤＮＳ回答を受信することに用いられ、上記処理モジュール１４は、Ａ型をＡＡＡＡ型にトランスレートし、ＩＰｖ４からＩＰｖ６へのマッピング関係を作成し、トランスレーション後のＡＡＡＡ型付きのＤＮＳ回答をＩＰｖ６アプリに通知することに用いられ、上記受信モジュール１３は、具体的に、ＩＰｖ６アプリのアクセス相手のサーバ種類がＩＰｖ６サーバである場合、ＤＮＳサーバにより返信されたＡＡＡＡ型付きのＤＮＳ回答を受信することに用いられ、上記処理モジュール１４は、Ａ型とＡＡＡＡ型付きのＤＮＳ要求をＮＡＴ４６ゲートウェイに送信し、ＮＡＴ４６ゲートウェイにより返信されたＡ型とＡＡＡＡ型付きのＤＮＳ回答を受信し、ＡＡＡＡ型付きのＤＮＳ回答をＩＰｖ６アプリに通知することに用いられる。

上記ＩＰｖ６アプリから送信したＩＰｖ６情報には、ＩＰｖ６アプリ情報を含み、上記トランスレートモジュール１１は、具体的に、上記ＩＰｖ６アプリ情報におけるＩＰｖ６送信元アドレスをＩＰｖ４送信元アドレスにトランスレートし、上記ＩＰｖ６アプリ情報におけるＩＰｖ６宛先アドレスをＩＰｖ４宛先アドレスにトランスレートすることに用いられ、上記送信モジュール１２は、具体的に、ＩＰｖ６アプリのアクセス相手のサーバ種類がＩＰｖ６サーバである場合、トランスレーション後のＩＰｖ６アプリ情報をＮＡＴ４６ゲートウェイに送信し、ＩＰｖ６アプリのアクセス相手のサーバ種類がＩＰｖ４サーバである場合、トランスレーション後のＩＰｖ６アプリ情報をＩＰｖ４サーバに送信することに用いられ、上記受信モジュール１３は、具体的に、ＩＰｖ６アプリのアクセス相手のサーバ種類がＩＰｖ６サーバである場合、上記ＮＡＴ４６ゲートウェイから返信された上記ＩＰｖ６アプリ情報に対応するサービスデータを受信することに用いられ、ＩＰｖ６アプリのアクセス相手のサーバ種類がＩＰｖ４サーバである場合、上記ＩＰｖ４サーバから返信された上記ＩＰｖ６アプリ情報に対応するサービスデータを受信することに用いられる。

ただし、本発明の装置の各モジュールは、一体に集積してもよいし、独立に配置してもよい。上記モジュールは、一つのモジュールに合併してもよいし、さらに複数のサブモジュールに分割してもよい。

同様な発明の構想に基づき、本発明の実施例では、ゲートウェイ機器も提供している。図７に示すように、端末からのトランスレーション後のＩＰｖ４要求情報を受信するための第１受信モジュール２１と、上記ＩＰｖ４要求情報に対応するＩＰｖ６要求をＩＰｖ６網における機器に送信するための第１送信モジュール２２と、上記ＩＰｖ４要求情報に対応するＩＰｖ６要求に対してＩＰｖ６網における機器から返信されるＩＰｖ６応答を受信するための第２受信モジュール２３と、上記ＩＰｖ６応答に対応するＩＰｖ４応答をＩＰｖ４網における端末に送信するための第２送信モジュール２４とを含む。

上記ＩＰｖ４要求情報には、ＡＡＡＡ型とＡ型付きのＤＮＳ要求を含み、上記第１受信モジュール２１は、具体的に端末からのＡＡＡＡ型とＡ型付きのＤＮＳ要求を受信することに用いられ、上記第１送信モジュール２２は、具体的に上記ＡＡＡＡ型とＡ型付きのＤＮＳ要求をＩＰｖ６網におけるＤＮＳサーバに送信することに用いられ、上記第２受信モジュール２３は、具体的にＩＰｖ６網におけるＤＮＳサーバから返信されるＡＡＡＡ型付きのＤＮＳ回答を受信することに用いられ、上記第２送信モジュール２４は、具体的に上記ＡＡＡＡ型付きのＤＮＳ回答におけるＡＡＡＡ型をＡ型とＡＡＡＡ型にトランスレートし、ＩＰｖ６からＩＰｖ４へのマッピング関係を作成し、Ａ型とＡＡＡＡ型付きのＤＮＳ回答をＩＰｖ４網における端末に送信することに用いられる。

上記ＩＰｖ４要求情報には、ＩＰｖ４送信元アドレスとＩＰｖ４宛先アドレス付きのＩＰｖ６アプリ情報を含み、上記第１受信モジュール２１は、具体的に端末からのＩＰｖ４送信元アドレスとＩＰｖ４宛先アドレス付きのＩＰｖ６アプリ情報を受信することに用いられ、上記第１送信モジュール２２は、具体的に上記ＩＰｖ６からＩＰｖ４へのマッピング関係に基づいて、ＩＰｖ６アプリ情報におけるＩＰｖ４送信元アドレスをＩＰｖ６送信元アドレスにトランスレートし、ＩＰｖ６アプリ情報におけるＩＰｖ４宛先アドレスをＩＰｖ６宛先アドレスにトランスレートし、ＩＰｖ６送信元アドレスとＩＰｖ６宛先アドレス付きのＩＰｖ６アプリ情報をＩＰｖ６網におけるＩＰｖ６サーバに送信することに用いられ、上記第２受信モジュール２３は、具体的にＩＰｖ６網におけるＩＰｖ６サーバから返信される上記ＩＰｖ６アプリ情報に対応するサービスデータを受信することに用いられ、上記第２送信モジュール２４は、具体的に上記ＩＰｖ６からＩＰｖ４へのマッピング関係に基づいて、上記サービスデータにおけるＩＰｖ６送信元アドレスをＩＰｖ４送信元アドレスにトランスレートし、上記サービスデータにおけるＩＰｖ６宛先アドレスをＩＰｖ４宛先アドレスにトランスレートし、ＩＰｖ４送信元アドレスとＩＰｖ４宛先アドレス付きのサービスデータをＩＰｖ４網における端末に送信することに用いられる。

ただし、本発明の装置の各モジュールは、一体に集積してもよいし、独立に配置してもよい。上記モジュールは、一つのモジュールに合併してもよいし、さらに複数のサブモジュールに分割してもよい。

同様な発明の構想に基づき、本発明の実施例では、ネットワーク通信の機器も提供している。図８に示すように、ＩＰｖ６アプリ情報を受信すると、上記ＩＰｖ６アプリ情報をデュアルスタックサーバに送信するための送信モジュール３１と、上記デュアルスタックサーバにより返信される上記ＩＰｖ６アプリ情報に対応するサービスデータを受信するための受信モジュール３２とを含む。ＩＰｖ６アプリからＡＡＡＡ型付きのＤＮＳ要求が送信される場合、ＡＡＡＡ型をＡＡＡＡ型とＡ型にトランスレートするためのトランスレートモジュール３３をさらに含み、上記送信モジュール３１は、さらにＡＡＡＡ型とＡ型付きのＤＮＳ要求をＩＰｖ４網におけるＤＮＳサーバに送信することに用いられ、上記受信モジュール３２は、さらに上記ＤＮＳサーバにより返信されるＡ型とＡＡＡＡ型付きのＤＮＳ回答を受信し、ＡＡＡＡ型付きのＤＮＳ回答をＩＰｖ６アプリに通知することに用いられる。

ただし、本発明の装置の各モジュールは、一体に集積してもよいし、独立に配置してもよい。上記モジュールは、一つのモジュールに合併してもよいし、さらに複数のサブモジュールに分割してもよい。

以上の実施形態の記載から、当業者は、本発明がハードウェアでも実現できるし、ソフトウェアに必要な汎用ハードウェアプラットフォームを加えるという方式でも実現できることが自明である。このような理解に基づき、本発明の技術的解決策は、ソフトウェア製品の形で表すことができ、該ソフトウェア製品は、不揮発性記憶媒体（ＣＤ−ＲＯＭ、Ｕディスク、リムーバブルハードディスク）に記憶でき、複数の指令を含み、一台のコンピュータ機器（パソコン、サーバ、またはネットワーク機器など）で本発明の各実施例に記載される方法を実行可能にする。

当業者として、図面が一好ましい実施例を示す図面に過ぎず、図面にあるモジュールまたはフローが必ずしも本発明の実施に必須なものに限らないことが理解可能である。

当業者として、実施例にある装置のモジュールが実施例の記載に従い実施例の装置に分布してもよいし、対応な変更を経て本実施例に異なる一つまたは複数の装置に分布してもよいことが理解可能である。上記実施例のモジュールは、一つのモジュールに合併してもよいし、さらに複数のサブモジュールに分割してもよい。
上記本発明の番号は、記載のためのものであり、実施例の優劣を表すものではない。
以上開示したのは本発明のいくつかの具体的な実施形態に過ぎず、本発明はこれらに限定されることはない。あらゆる当業者が考えうる変更も本発明の保護範囲に含まれるべきである。

Claims (19)

1. 端末が、ＩＰｖ６アプリから送信したＩＰｖ６情報を受信すると、前記ＩＰｖ６情報をＩＰｖ４情報にトランスレートし、前記ＩＰｖ４情報付きのＩＰｖ６アプリ要求を送信するステップと、
   前記端末が、前記ＩＰｖ６アプリ要求に対応するＩＰｖ６アプリ応答を受信するステップと、を含むことを特徴とするネットワーク通信の方法。
2. 前記ＩＰｖ６アプリから送信したＩＰｖ６情報には、ＡＡＡＡ型付きのＤＮＳ要求を含み、
   前記端末が前記ＩＰｖ６情報をＩＰｖ４情報にトランスレートすることは、
   前記端末がＡＡＡＡ型付きのＤＮＳ要求をＡＡＡＡ型とＡ型付きのＤＮＳ要求にトランスレートすることを含むことを特徴とする請求項１に記載の方法。
3. 前記の、前記ＩＰｖ４情報付きのＩＰｖ６アプリ要求を送信することは、
   前記端末がＡＡＡＡ型とＡ型付きのＤＮＳ要求をＩＰｖ４網におけるＤＮＳサーバに送信することを含み、
   前記端末が前記ＩＰｖ６アプリ要求に対応するＩＰｖ６アプリ応答を受信することは、
   前記端末が、前記ＤＮＳサーバによりＩＰｖ６アプリのアクセス相手のサーバ種類に基づき返信されたＤＮＳ回答を受信することを含むことを特徴とする請求項２に記載の方法。
4. ＩＰｖ６アプリのアクセス相手のサーバ種類がＩＰｖ４サーバである場合、前記端末が、前記ＤＮＳサーバによりＩＰｖ６アプリのアクセス相手のサーバ種類に基づき返信されたＤＮＳ回答を受信することは、
   前記端末が、前記ＤＮＳサーバにより返信されたＡ型付きのＤＮＳ回答を受信することを含み、
   前記端末が、前記ＤＮＳサーバによりＩＰｖ６アプリのアクセス相手のサーバ種類に基づき返信されたＤＮＳ回答を受信した後に、さらに、
   前記端末が、Ａ型をＡＡＡＡ型にトランスレートし、ＩＰｖ４からＩＰｖ６へのマッピング関係を作成し、トランスレーション後のＡＡＡＡ型付きのＤＮＳ回答をＩＰｖ６アプリに通知することを含み、
   ＩＰｖ６アプリのアクセス相手のサーバ種類がＩＰｖ６サーバである場合、前記端末が、前記ＤＮＳサーバによりＩＰｖ６アプリのアクセス相手のサーバ種類に基づき返信されたＤＮＳ回答を受信することは、
   前記端末が、前記ＤＮＳサーバにより返信されたＡＡＡＡ型付きのＤＮＳ回答を受信することを含み、
   前記端末が、前記ＤＮＳサーバによりＩＰｖ６アプリのアクセス相手のサーバ種類に基づき返信されたＤＮＳ回答を受信した後に、さらに、
   前記端末が、Ａ型とＡＡＡＡ型付きのＤＮＳ要求をＮＡＴ４６ゲートウェイに送信し、ＮＡＴ４６ゲートウェイにより返信されたＡ型とＡＡＡＡ型付きのＤＮＳ回答を受信し、ＡＡＡＡ型付きのＤＮＳ回答をＩＰｖ６アプリに通知することを含むことを特徴とする請求項３に記載の方法。
5. 前記端末がＡ型とＡＡＡＡ型付きのＤＮＳ要求をＮＡＴ４６ゲートウェイに送信した後に、さらに、
   ＮＡＴ４６ゲートウェイが、Ａ型とＡＡＡＡ型付きのＤＮＳ要求をＩＰｖ６網におけるＤＮＳサーバに送信し、
   前記ＩＰｖ６網におけるＤＮＳサーバが、ＡＡＡＡ型付きのＤＮＳ回答を前記ＮＡＴ４６ゲートウェイに送信し、
   前記ＮＡＴ４６ゲートウェイが、ＡＡＡＡ型をＡ型とＡＡＡＡ型に解析し、ＩＰｖ６からＩＰｖ４へのマッピング関係を作成し、
   前記ＮＡＴ４６ゲートウェイが、解析後のＡ型とＡＡＡＡ型付きのＤＮＳ回答を前記端末に送信することを含むことを特徴とする請求項４に記載の方法。
6. 前記ＩＰｖ６アプリから送信したＩＰｖ６情報には、ＩＰｖ６アプリ情報を含み、
   前記端末が前記ＩＰｖ６情報をＩＰｖ４情報にトランスレートすることは、
   前記端末が前記ＩＰｖ６アプリ情報におけるＩＰｖ６送信元アドレスをＩＰｖ４送信元アドレスにトランスレートし、前記ＩＰｖ６アプリ情報におけるＩＰｖ６宛先アドレスをＩＰｖ４宛先アドレスにトランスレートすることを含むことを特徴とする請求項１に記載の方法。
7. ＩＰｖ６アプリのアクセス相手のサーバ種類がＩＰｖ６サーバである場合、
   前記の、前記ＩＰｖ４情報付きのＩＰｖ６アプリ要求を送信することは、
   前記端末がトランスレーション後のＩＰｖ６アプリ情報をＮＡＴ４６ゲートウェイに送信することを含み、
   前記端末が前記ＩＰｖ６アプリ要求に対応するＩＰｖ６アプリ応答を受信することは、
   前記端末が、前記ＮＡＴ４６ゲートウェイから返信された前記ＩＰｖ６アプリ情報に対応するサービスデータを受信することを含み、
   ＩＰｖ６アプリのアクセス相手のサーバ種類がＩＰｖ４サーバである場合、
   前記の、前記ＩＰｖ４情報付きのＩＰｖ６アプリ要求を送信することは、
   前記端末がトランスレーション後のＩＰｖ６アプリ情報をＩＰｖ４サーバに送信することを含み、
   前記端末が前記ＩＰｖ６アプリ要求に対応するＩＰｖ６アプリ応答を受信することは、
   前記端末が、前記ＩＰｖ４サーバから返信された前記ＩＰｖ６アプリ情報に対応するサービスデータを受信することを含むことを特徴とする請求項６に記載の方法。
8. 前記端末が前記ＮＡＴ４６ゲートウェイから返信された前記ＩＰｖ６アプリ情報に対応するサービスデータを受信する前に、さらに、
   前記ＮＡＴ４６ゲートウェイが、トランスレーション後のＩＰｖ６アプリ情報を受信すると、前記ＩＰｖ６からＩＰｖ４へのマッピング関係に基づいて、トランスレーション後のＩＰｖ６アプリ情報におけるＩＰｖ４送信元アドレスをＩＰｖ６送信元アドレスにトランスレートし、トランスレーション後のＩＰｖ６アプリ情報におけるＩＰｖ４宛先アドレスをＩＰｖ６宛先アドレスにトランスレートし、
   前記ＮＡＴ４６ゲートウェイが、ＩＰｖ６送信元アドレスとＩＰｖ６宛先アドレス付きのＩＰｖ６アプリ情報をＩＰｖ６サーバに送信し、前記ＩＰｖ６サーバから前記ＩＰｖ６アプリ情報に対応するサービスデータが返信され、
   前記ＮＡＴ４６ゲートウェイが、前記ＩＰｖ６からＩＰｖ４へのマッピング関係に基づいて、前記サービスデータにおけるＩＰｖ６送信元アドレスをＩＰｖ４送信元アドレスにトランスレートし、前記サービスデータにおけるＩＰｖ６宛先アドレスをＩＰｖ４宛先アドレスにトランスレートし、
   前記ＮＡＴ４６ゲートウェイが、トランスレーション後の前記ＩＰｖ６アプリ情報に対応するサービスデータを前記端末に送信することを含むことを特徴とする請求項７に記載の方法。
9. 端末がＩＰｖ６アプリ情報を受信し、前記ＩＰｖ６アプリ情報をデュアルスタックサーバに送信し、前記デュアルスタックサーバにより返信される前記ＩＰｖ６アプリ情報に対応するサービスデータを受信するステップを含むことを特徴とするネットワーク通信の方法。
10. 前記端末がＩＰｖ６アプリ情報を受信する前に、さらに、
    ＩＰｖ６アプリからＡＡＡＡ型付きのＤＮＳ要求が送信される場合、前記端末は、ＡＡＡＡ型をＡＡＡＡ型とＡ型にトランスレートし、ＡＡＡＡ型とＡ型付きのＤＮＳ要求をＩＰｖ４網におけるＤＮＳサーバに送信し、
    前記端末は、前記ＤＮＳサーバにより返信されるＡ型とＡＡＡＡ型付きのＤＮＳ回答を受信し、ＡＡＡＡ型付きのＤＮＳ回答をＩＰｖ６アプリに通知することを含むことを特徴とする請求項９に記載の方法。
11. ＩＰｖ６アプリから送信したＩＰｖ６情報を受信すると、前記ＩＰｖ６情報をＩＰｖ４情報にトランスレートするためのトランスレートモジュールと、
    前記ＩＰｖ４情報付きのＩＰｖ６アプリ要求を送信するための送信モジュールと、
    前記ＩＰｖ６アプリ要求に対応するＩＰｖ６アプリ応答を受信するための受信モジュールと含むことを特徴とするネットワーク通信の機器。
12. 前記ＩＰｖ６アプリから送信したＩＰｖ６情報には、ＡＡＡＡ型付きのＤＮＳ要求を含み、
    前記トランスレートモジュールは、具体的にＡＡＡＡ型付きのＤＮＳ要求をＡＡＡＡ型とＡ型付きのＤＮＳ要求にトランスレートすることに用いられ、
    前記送信モジュールは、具体的にＡＡＡＡ型とＡ型付きのＤＮＳ要求をＩＰｖ４網におけるＤＮＳサーバに送信することに用いられ、
    前記受信モジュールは、具体的に前記ＤＮＳサーバによりＩＰｖ６アプリのアクセス相手のサーバ種類に基づき返信されたＤＮＳ回答を受信することに用いられることを特徴とする請求項１１に記載の機器。
13. さらに処理モジュールを含み、
    前記受信モジュールは、具体的に、ＩＰｖ６アプリのアクセス相手のサーバ種類がＩＰｖ４サーバである場合、ＤＮＳサーバにより返信されたＡ型付きのＤＮＳ回答を受信することに用いられ、
    前記処理モジュールは、Ａ型をＡＡＡＡ型にトランスレートし、ＩＰｖ４からＩＰｖ６へのマッピング関係を作成し、トランスレーション後のＡＡＡＡ型付きのＤＮＳ回答をＩＰｖ６アプリに通知することに用いられ、
    前記受信モジュールは、具体的に、ＩＰｖ６アプリのアクセス相手のサーバ種類がＩＰｖ６サーバである場合、ＤＮＳサーバにより返信されたＡＡＡＡ型付きのＤＮＳ回答を受信することに用いられ、
    前記処理モジュールは、Ａ型とＡＡＡＡ型付きのＤＮＳ要求をＮＡＴ４６ゲートウェイに送信し、ＮＡＴ４６ゲートウェイにより返信されたＡ型とＡＡＡＡ型付きのＤＮＳ回答を受信し、ＡＡＡＡ型付きのＤＮＳ回答をＩＰｖ６アプリに通知することに用いられることを特徴とする請求項１２に記載の機器。
14. 前記ＩＰｖ６アプリから送信したＩＰｖ６情報には、ＩＰｖ６アプリ情報を含み、
    前記トランスレートモジュールは、具体的に、前記ＩＰｖ６アプリ情報におけるＩＰｖ６送信元アドレスをＩＰｖ４送信元アドレスにトランスレートし、前記ＩＰｖ６アプリ情報におけるＩＰｖ６宛先アドレスをＩＰｖ４宛先アドレスにトランスレートすることに用いられ、
    前記送信モジュールは、具体的に、ＩＰｖ６アプリのアクセス相手のサーバ種類がＩＰｖ６サーバである場合、トランスレーション後のＩＰｖ６アプリ情報をＮＡＴ４６ゲートウェイに送信し、ＩＰｖ６アプリのアクセス相手のサーバ種類がＩＰｖ４サーバである場合、トランスレーション後のＩＰｖ６アプリ情報をＩＰｖ４サーバに送信することに用いられ、
    前記受信モジュールは、具体的に、ＩＰｖ６アプリのアクセス相手のサーバ種類がＩＰｖ６サーバである場合、前記ＮＡＴ４６ゲートウェイから返信された前記ＩＰｖ６アプリ情報に対応するサービスデータを受信し、ＩＰｖ６アプリのアクセス相手のサーバ種類がＩＰｖ４サーバである場合、前記ＩＰｖ４サーバから返信された前記ＩＰｖ６アプリ情報に対応するサービスデータを受信することに用いられることを特徴とする請求項１１に記載の機器。
15. 端末からのトランスレーション後のＩＰｖ４要求情報を受信するための第１受信モジュールと、
    前記ＩＰｖ４要求情報に対応するＩＰｖ６要求をＩＰｖ６網における機器に送信するための第１送信モジュールと、
    前記ＩＰｖ４要求情報に対応するＩＰｖ６要求に対してＩＰｖ６網における機器から返信されるＩＰｖ６応答を受信するための第２受信モジュールと、
    前記ＩＰｖ６応答に対応するＩＰｖ４応答をＩＰｖ４網における端末に送信するための第２送信モジュールと、を含むことを特徴とするゲートウェイ機器。
16. 前記ＩＰｖ４要求情報には、ＡＡＡＡ型とＡ型付きのＤＮＳ要求を含み、
    前記第１受信モジュールは、具体的に端末からのＡＡＡＡ型とＡ型付きのＤＮＳ要求を受信することに用いられ、
    前記第１送信モジュールは、具体的に前記ＡＡＡＡ型とＡ型付きのＤＮＳ要求をＩＰｖ６網におけるＤＮＳサーバに送信することに用いられ、
    前記第２受信モジュールは、具体的にＩＰｖ６網におけるＤＮＳサーバから返信されるＡＡＡＡ型付きのＤＮＳ回答を受信することに用いられ、
    前記第２送信モジュールは、具体的に前記ＡＡＡＡ型付きのＤＮＳ回答におけるＡＡＡＡ型をＡ型とＡＡＡＡ型にトランスレートし、ＩＰｖ６からＩＰｖ４へのマッピング関係を作成し、Ａ型とＡＡＡＡ型付きのＤＮＳ回答をＩＰｖ４網における端末に送信することに用いられることを特徴とする請求項１５に記載のゲートウェイ機器。
17. 前記ＩＰｖ４要求情報には、ＩＰｖ４送信元アドレスとＩＰｖ４宛先アドレス付きのＩＰｖ６アプリ情報を含み、
    前記第１受信モジュールは、具体的に端末からのＩＰｖ４送信元アドレスとＩＰｖ４宛先アドレス付きのＩＰｖ６アプリ情報を受信することに用いられ、
    前記第１送信モジュールは、具体的に前記ＩＰｖ６からＩＰｖ４へのマッピング関係に基づいて、ＩＰｖ６アプリ情報におけるＩＰｖ４送信元アドレスをＩＰｖ６送信元アドレスにトランスレートし、ＩＰｖ６アプリ情報におけるＩＰｖ４宛先アドレスをＩＰｖ６宛先アドレスにトランスレートし、ＩＰｖ６送信元アドレスとＩＰｖ６宛先アドレス付きのＩＰｖ６アプリ情報をＩＰｖ６網におけるＩＰｖ６サーバに送信することに用いられ、
    前記第２受信モジュールは、具体的にＩＰｖ６網におけるＩＰｖ６サーバから返信される前記ＩＰｖ６アプリ情報に対応するサービスデータを受信することに用いられ、
    前記第２送信モジュールは、具体的に前記ＩＰｖ６からＩＰｖ４へのマッピング関係に基づいて、前記サービスデータにおけるＩＰｖ６送信元アドレスをＩＰｖ４送信元アドレスにトランスレートし、前記サービスデータにおけるＩＰｖ６宛先アドレスをＩＰｖ４宛先アドレスにトランスレートし、ＩＰｖ４送信元アドレスとＩＰｖ４宛先アドレス付きのサービスデータをＩＰｖ４網における端末に送信することに用いられることを特徴とする請求項１６に記載のゲートウェイ機器。
18. ＩＰｖ６アプリ情報を受信すると、前記ＩＰｖ６アプリ情報をデュアルスタックサーバに送信するための送信モジュールと、
    前記デュアルスタックサーバにより返信される前記ＩＰｖ６アプリ情報に対応するサービスデータを受信するための受信モジュールと、を含むことを特徴とするネットワーク通信の機器。
19. ＩＰｖ６アプリからＡＡＡＡ型付きのＤＮＳ要求が送信される場合、ＡＡＡＡ型をＡＡＡＡ型とＡ型にトランスレートするためのトランスレートモジュールをさらに含み、
    前記送信モジュールは、ＡＡＡＡ型とＡ型付きのＤＮＳ要求をＩＰｖ４網におけるＤＮＳサーバに送信することにも用いられ、
    前記受信モジュールは、前記ＤＮＳサーバにより返信されるＡ型とＡＡＡＡ型付きのＤＮＳ回答を受信し、ＡＡＡＡ型付きのＤＮＳ回答をＩＰｖ６アプリに通知することにも用いられることを特徴とする請求項１８に記載の機器。

Images