JP2008042881A - インターネットデータ伝送中継媒体 - Google Patents

インターネットデータ伝送中継媒体 Download PDF

Info

Publication number
JP2008042881A
JP2008042881A JP2007114071A JP2007114071A JP2008042881A JP 2008042881 A JP2008042881 A JP 2008042881A JP 2007114071 A JP2007114071 A JP 2007114071A JP 2007114071 A JP2007114071 A JP 2007114071A JP 2008042881 A JP2008042881 A JP 2008042881A
Authority
JP
Japan
Prior art keywords
ipv4
ipv6
relay medium
network
relay
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
JP2007114071A
Other languages
English (en)
Inventor
Paz Itzhaki Weinberger
イトツハキ−ウェインベルガー パズ
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
ITZHAKI WEINBERGER CONSULTANTS
ITZHAKI-WEINBERGER CONSULTANTS (IWC) Ltd
MARCEL SCHEINER
NICOLE ROSALYN MONK
Original Assignee
ITZHAKI WEINBERGER CONSULTANTS
ITZHAKI-WEINBERGER CONSULTANTS (IWC) Ltd
MARCEL SCHEINER
NICOLE ROSALYN MONK
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by ITZHAKI WEINBERGER CONSULTANTS, ITZHAKI-WEINBERGER CONSULTANTS (IWC) Ltd, MARCEL SCHEINER, NICOLE ROSALYN MONK filed Critical ITZHAKI WEINBERGER CONSULTANTS
Publication of JP2008042881A publication Critical patent/JP2008042881A/ja
Pending legal-status Critical Current

Links

Images

Abstract

【課題】IPv4からIPv6への移行期間中、広く展開しているIPv4対応機器を入れ替えることなく、IPv6環境内で充分機能するよう、既存のテレコミュニケーションに容易に組み込まれる方法論やシステムを提供する。
【解決手段】中継媒体はIPv4とIPv6トラフィックの両方が行き来する複数のネットワークのノードにミドルウェアとして設定される。更に、IPv4ルーターやファイヤーウォールにファームウェア・アップグレードとして、より新しいIPv6デバイスにファームウェアとして、又、IPv4とIPv6の両ネットワーク上にある複数の端末に組み込まれたり、ファームウェア,ハードウェア,ソフトウェアとしても設定される。このように、この中継媒体は、―データが送られる機器の必要性に応じて―入力データを再構築しながら、IPv4とIPv6の両フォーマット内でデータの伝送・受信を可能とする。
【選択図】図2

Description

本発明は、デバイスが十分に機能するよう保守しつつ、IPv4 とIPv6ネットワーク間における中継、又はこれらのネットワークに接続された機器がいずれのネットワーク内でも正しく操作されるようにするための中継媒体や中継方法の提供を対象とする。
インターネットプロトコル(以下IP)は、2つのコンピューターが独自に相互識別し、インターネット上でデータ転送が確実に行われるよう、世界中の各コンピューターの住所割当(アドレッシング)がその目的である。
IPはコネクションレス・プロトコルであり、各データパケットが別々に処理され、且つ、他の複数のパケットに関係なく単独型パケットとして受理されるOSL参照基本モデルの第3層に位置する。これは、(OSI参照モデルの第4層に位置する)TCPや(ファイルの断片化と共に個々のパケットが持つ独立性をある程度損なう)TCP/IP等の拡張子との接続により拡張される。
IPv4とはインターネット プロトコル バージョン 4 の略称で、パケット交換型インターネット(例:イーサネット)上で利用されるデータ指向プロトコルである。IPv4はインターネットプロトコルの最初のバージョンとして広く展開され、現在インターネット上で使われている主要なネットワーク層である。これはIETF RFC 791(1981年9月)とアメリカ国防総省規格ミルスペックドキュメント:MIL-STD-1777に記載されている。
IPv4は32ビット アドレスシング システムを使用している。IPv4は4.3x109(43億)のアドレスをサポートするが、これは全ての人ひとりに一つのアドレスを与えるのにさえ不足した数であり、急成長している結合装置市場を遥かに下回るサポート数である。
絶え間なくオン状態であるADSLモデムやケーブルモデムと共に、携帯機器を含むインターネット対応機器(ラップトップコンピューター, PDA, 携帯電話等)がより普及し、インターネット利用者数の急激な上昇に伴い、IPアドレス資源の枯渇に対する懸念が高まっている。2016年頃までにはIPv4アドレス空間領域が枯渇するだろうと、一般的に見られている。
IPv4アドレス資源の使い果たしを和らげるため、クラスフル ネットワークスやCIDRアドレッシングが開発された。種々の部分的な解決案は以下を含む:
ネットワーク アドレス変換(以下NAT)
個人ネットワーク利用
ダイナミックホスト設定プロトコル(以下DHCP)
仮想ホスティングに基づく命名
地域的インターネット レジストリーによるローカル インターネット レジストリーへのアドレス配布の制御強化
インターネット初期段階で割り当てられたアドレス空間の、数ある膨大な塊を回収するための、ネットワーク再番号割当
IPv6は、1994年にインターネット技術特別調査委員会により採り入れられ、“次世代IP”と呼ばれた。IPv6は128ビットアドレッシングシステムを用い、3.4x1038アドレス、又は、5x1028アドレスを、いま生きている一人一人のためにサポートする。
10年が経過した今でも、公的にアクセス可能なインターネット上で有効なアドレスはIPv4によって占められているおり、IPv6が占める割合はほんの僅かでしかない。
IPv4からIPv6への移行はそれ自体が難問であることが立証されており、全インターネットにおける、IPv6の導入が数年のうちになされる見込みは薄い。部分的にアドレス資源の枯渇を和らげるNATの採用が、IPv6の導入を遅らせている。
アドレス利用とセキュリティの両方を高める一つの方法は、NATの利用である。一つのIPアドレスをある公的マシーンにインターネット・ゲートウェイとして割り当て、且つ、組織内の複数のコンピューターが共有出来る一つのプライベートネットワークを用いることにより、多量のアドレスを節約出来る。またこれはすべてのコンピューターが一つのネットワークで稼動させ、公的ネットワークから直接アクセスさせないため、セキュリティの強化にもなる。本来なら、公的インターネットを通じて二つのネットワーク(例:二つの支社)を接続することは不可能である。しかしバーチャル・プライベートネット・ワークス(以下VPN)がこの問題に対処する。
VPNは、あるIPパケット(カプセル化されたパケット)を別のIPパケット(カプセル化するパケット)に直接挿入し、且つ、カプセル化するパケットの中の公的に経路選択可能なアドレスを利用することにより機能する。VPNパケット経路が、一旦公的ネットワーク内に送られ、終点に辿り着くと、カプセル化されたパケットは抽出され、そうして、まるで二つのネットワークが直接接続しているかのように、プライベートネットワーク上で転送される。
IPがデータリンク層より上層部に位置するので、IPアドレスAを持つコンピューターがIPアドレスBを持つもう一つのコンピューターと交信したい時に問題が生じる。AからBにパケットを送るため、AはBのハードウェア アドレスを知る必要がある。この物理アドレスの検出はアドレス・レゾリューション・プロトコル(ARP)を経由して行われる。
DHCP又はRARPは、コンピューターがその―IPアドレスではなく―データリンク層アドレスを認識する時に機能する。これは、マシーンのIPアドレスがネットワーク構成やコネクション設定に直接関連しない時、プライベートネットワークやDSLコネクション上における一般的なシナリオである。これは通常、―サーバーではなく―ネットワークステーションのケースに当て嵌まる。現在その大部分は、DHCPに取って替わられている。
IPアドレスの送信に加え、DHCPはNTPサーバーやDNSサーバー等を送信することも出来る。一般的に、IPパケットはヘッダとデータで構成される。一つのIPアドレスは4つの8ビットオクテットのグループであり、計32ビットである。このフィールド値は各オクテットの二進法値を取り、それらを一つの32ビット値として結合することによって測定される。
異なる複数のネットワークにおいて、IPv4をより耐久性あるものにするため、IP層でのディスク断片化に関する構想が開発されている。それは、必要ならば、デバイスがデータをより小さい断片に細分化出来るようにするためである。これは、最大伝送ユニット(MTU)がパケットサイズより小さい場合に必須である。
受信側が(“more fragments”フラグセットか “断片補正”フィールドのいずれかがゼロでない場合の)IPパケットを検出した時に、その受信側はそのパケットが一つの断片であることを認識する。その後、受信側は識別フィールド、断片補正、及びmore fragmentsフラグと共にデータを記憶する。受信側がmore fragmentsフラグがセットされていない状態で断片を受け取った時、オリジナルデータの最大蓄積量の長さを認識する。それは断片オフセットとデータの長さを足したものが、オリジナルデータの最大蓄積量のサイズと等しいからである。
一旦、受信側が全ての断片を所持すると、(断片オフセットを用いて)そのデータを適切な順序に再構築し、さらなる処理のためにスタックに蓄積する。
アメリカ政府は、2008年までにすべての連邦機関のネットワーク基幹回線はIPv6を配置しなくてはならないと言明している。
何十億の機器が世界中に分散しており、それらはIPv4に依存している。IPv4からIPv6への移行は、これらの機器の多くを旧式とし、交換を強いるだろう。多くのシステムは特定のユーザーの要請に基づいてカスタマイズされる。再構築と修正には、労務時間という莫大な投資を要するだろう。
一例としては、殆どのハードウェア ファイヤーウォールが、IPv4フィルタリング技術を元にしたルールに則っている点が挙げられる。IPv4からIPv6に一旦置き換わると、これらのファイヤーウォールは差し替えや再構築を必要とする。
IPv6サポート機能、又は、IPv6にアップグレードするオプション付きの新型機器は、時としてIPv4-IPv6ハイブリッド機器として知られている。
IPv6の導入は、IPv4用にデザインされたソフトウェアが適切に稼動しないかも知れないといった問題を引き起こすだろうと予想されている。IPv6 がIPv4に完全に取って代わるまで―それはここ当分は実現しないだろうが―、IPv6のみに対応するホストをIPv4のサービスに到達させ、複数のIPv6単独ホストやネットワークがIPv4インフラを超えてIPv6インターネットに至るよう、幾つかものいわゆる遷移メカニズムが必要である。
IPv6はIPv4の小規模な機能延長に過ぎないので、大部分のコードを共有しつつ、IPv4とIPv6の両方に対応するネットワークスタックを書くことは比較的簡単である。このような導入はデュアルスタックと呼ばれ、そのデュアルスタックを実行するホストはデュアルスタックホストと呼ばれている。この取り組み方法はPFC4213に記載されている。現在の殆どのIPv6導入はデュアルスタックが用いられている。幾つかの初期実験的導入は、独立したIPv4と複数のIPv6スタックを使用した。
IPv6インターネットに到達するには、単独のホストまたはネットワークが、複数のIPv6パケットを運ぶよう、既存のIPv4インフラの使用が必須である。これは少々誤解を招きかねないトンネリングと言う用語で知られている技術―IPv6パケットをIPv4内でカプセル化して構成される―を以ってなされ、事実上IPv4をIPv6用のリンクとして使用する。
IPv6パケットはプロトコール番号41を使用してIPv4パケット内に直接カプセル化されることが可能である。また、ルーターやプロトコール41トラフィックをブロックするNATデバイスを横切るために、UDPパケット等の中でも直接カプセル化することが出来る。
自動設定トンネリングは、トンネルの末端をルーティングインフラにより自動的に認識する技術に言及する。自動設定トンネリングにおいて推奨される技術は、プロトコール41カプセル化を用いる6to4トンネリングである。リモートサイド上の既知であるIPv4 エニキャスト アドレスを用い、ローカルサイド上のIPv6アドレスの内にIPv4アドレス情報をはめ込むことで、トンネルの末端は決定される。6to4はこんにち広く展開されている。
手動設定トンネリングは、トンネルの末端がどこなのかはっきり設定される技術であり、人間による操作、或いは、トンネルブローカーとして知られている自動サービスのいずれかで行われる。手動設定トンネリングは通常、自動設定トンネリングよりも、より決定的でより簡単にデバッグし、したがって大きな、うまく管理されているネットワークに推奨されている。手動設定トンネリングは概して(推奨されている)プロトコル41かraw UDPカプセル化のいずれかを用いる。
IPv6のみに対応するホストがIPv4のみに対応するサービス(例:ウェブサーバー)にアクセスする必要がある時は、何らかの変換が不可欠である。実際に機能している変換方式の一つは、デュアルスタック副アプリケーション層(例:副ウェブ)の使用である。
IPv4機器が複数のIPv6ネットワークを横切りアクセス可能になること、そして、IPv4環境内でIPv6機器がネットワーク化されることが許可される必要がある。本願発明はその必要性に対応する。
本発明は、IPv4対応のハードウェア、ソフトウェア、ネットワークとIPv6対応のハードウェア、ソフトウェア、ネットワーク間での中継方法や中継システムを提供することを目指す。
具体的な目的は、その方法論やシステムが、既存のテレコミュニケーションシステムに簡単に組み込まれなければならないという点である。
(課題を解決する手段)
第一の態様において、本願発明の目的は、IPv4とIPv6ネットワーク化された機器の間での中継をする中継媒体を提供することである。つまり、この中継媒体はネットワーク内のあるノードとして配置され、以下の事柄を実行するために設定可能である:
(a) ソースと宛先がIPv4と互換性を持つ機器である時、複数のIPv4データパケットが横断して透過的に伝送されるのを可能にすること
(b)ソースと宛先がIPv6と互換性を持つ機器である時、複数のIPv6データパケットが横断して透過的に伝送されるのを可能にすること
(c) IPv4互換ソースからIPv6宛先へとデータが移動する場合、IPv4データパケットをIPv6パケットとして再パケット化すること、そして
(d) IPv6互換ソースからIPv4宛先へとデータが移動する場合、IPv6データパケットをIPv4パケットとして再パケット化すること
大体においてこの中継媒体は、ハードウェア, ソフトウェア, ファームウェア、又は、その混合体として設定される。
任意に、この中継作業はカプセル化されることで成り立つ。或いは、パケットの再構築により成り立つ。
要約するに、本願発明の中継媒体はIPv4とIPv6トラフィックの両方が行き来する複数のネットワークのノードにミドルウェアとして設定される。更に、IPv4ルーターやファイヤーウォールにファームウェア・アップグレードとして、より新しいIPv6デバイスにファームウェアとして、更にIPv4とIPv6の両ネットワーク上にある複数の端末に組み込まれたり、ファームウェア,ハードウェア,ソフトウェアとしても設定される。
この中継媒体は、―データが送られる機器の必要性に応じて―入力データを再構築しながら、IPv4とIPv6の両フォーマット内でデータの伝送・受信を可能とする。
IPv4からIPv6への移行実現に関する問題は、時間の経過と共に対応されている。ここに明記された複数の中継媒体の使用により、IPv4 IT機器に多大な投資を行った企業は、大規模な再構築をせずとも、彼らの機材を使い続けることが出来る。複数のファイヤーウォールをそのままにしておくことが可能である。
従って、本分野で傑出した技術者達は、本願発明が、本文に敢えて説明や記述されている事柄だけに制限されない事を高く評価するだろう。むしろ、本願発明が言及する範囲については、添付の特許請求範囲により定められ、本文に説明された様々な特徴の組み合わせと補足的な組み合わせ、更に、複数のバリエーションや改良点も含んでいる。(以上のような事柄は、本分野で傑出した技術者達が、前述の説明を読めば納得するであろう)
この特許請求範囲における、“構成”という単語やその変化形である “構成する”や“構成している”といった言葉は、掲載された複数の要素が含まれていることを示唆するものだが、概してほかの要素を除外するものではない。
本発明は、IPv4にネットワーク化された機器とIPv6にネットワーク化された機器との間を中継するため、中継媒体を提供する。本中継媒体は、ネットワーク内のノードとして設定され、複数のIPv4互換性機器にソースと宛先のある場合、IPv4データパケットがそこを横切って透過的に伝送されることを、ケースに応じて可能にする。この中継媒体は(例えばトンネリング等のカプセル化やパケット再構築によって、データがIPv4互換ソースからIPv6互換宛先まで移動する場合)複数のIPv4データパケットをIPv6データパケットとして再パケット化する。
ソースと宛先の両方がIPv6互換の場合、IPv6データパケットは透過的に本中継媒体を横切って伝送される。これら様々な実施例において、本中継媒体はハードウェア, ソフトウェア, ファームウェア又はその混合体として設定されることだろう。
ファームウェアにより、ROM集積回路の中のコンピュータープログラムが対象となり、又、本開発テクノロジーは、(ハードウェア形式にソフトウェアを取り込むROMと似通った)その他のハードウェアにおいても導入が可能である。1037C連邦基準を参照。このファームウェアは、EPROMチップ、又は、特殊な外部ハードウェアによってそのプログラムの修正が可能なEEPROMチップとして提供され得る。
さて図1は、本発明のある実施例を踏まえた中継媒体10の概略図であり、それは、IPv4ネットワーク12が中継媒体10を経由して、その他複数のIPv4ネットワーク14、IPv4ネットワーク16のいずれとも通信することを可能にする様を示すものである。この実施例では、中継媒体10は単独型デバイスで、複数のIPv4デバイスとIPv6のインフラとを―IPv4デバイスの再設定をせずとも―接続する。
IPv4ネットワーク内の機器12が別のIPv4ネットワーク上の機器14と通信しなくてはいけない場合、中継媒体10は規定された方法でそれを通して両方向にデータ伝送を可能にする。しかし、IPv4ネットワーク12内の機器がIPv6ネットワーク16上の機器と通信しなくてはならない場合、本中継媒体10は情報伝送を可能にすべく、複数のデータパケットを再設定する。通常この中継媒体10は、IPv4ネットワーク12上のIPv4機器からのデータをカプセル化し、そのカプセル化したデータをIPv6ネットワーク16上の機器へ伝える。
逆方向では大抵、このIPv6ネットワーク16上のIPv6機器がIPv4データを生成しそれをIPv6フォーマットにカプセル化するので、中継媒体10は単にカプセル層を取り除けば良いだけとなる。或いは、パケット再構築も同様の結果をもたらすために用いられるだろう。カプセル化とパケット再構築に関する数ある技術は、広く文献化された従来技術である。
図2は本発明の、ある実施例を踏まえた中継媒体20の概略図である。中継媒体20は、IPv4ネットワーク12のIPv4フロントデバイス22とIPv6ネットワーク16のIPv6フロントデバイス26の間を中継するミドルウェアとしての役割を果たしている。
図3では、中継媒体30がIPv4 ネットワーク エミュレーション35を可能にしつつ、IPv4フロントデバイス22及びそれに付随する機能と、機能的に関連している可能性を示す参照例である。中継媒体30は実際、IPv4フロントデバイス22、又は、再設定を基礎としたソフトウェアにさえ付属品を接続する、ファームウェアとなり得る。この中継媒体30は、―多くの機器のアップグレードや、適度な機能性の実現を目的としてITエクスパート達による数週間に及ぶ設定作業を義務付けることなしに―IPv4機器を備える機関のIPv6ネットワーク16へのアクセスを可能にする。
特に、本願発明は複数のルーター, スイッチ, ファイアーウォールやその類の物を差し替える必要性を保留する。その結果、機関は、IPv6テクノロジーへの移行を何年も掛けて遂行しつつ、所有するIPv4機器を徐々に排除していくことが可能になるだろう。
2008年までにIPv6の配備を実施予定しているアメリカ政府連邦機関のように、早い段階でIPv6を検討した会社や大手企業は、図4のように、IPv6フロントデバイス26と結びついた反対方向に設定可能な中継媒体40の使用が可能である。これは、IPv4ネットワークエミュレーション45をIPv6フロントデバイス26に設置することで、企業のインターナルIPv6ネットワーク46と複数のIPv4ネットワークとの通信を可能にするためである。場合によっては、IPv6デバイス26の一つ、又は、より多くのポートがIPv4フロンドデバイス22と通信するよう、IPv4として取り込まれる可能性もある。
これはIPv4ネットワークエミュレーションや、あるプロトコルから別のプロトコルへの通信中継/変換を要する大規模な事業体にのみ関する事ではない。図5は、会社のIPv6ネットワーク46上のIPv6端末47へのソフトウェア アップグレードとして中継媒体50が提供される参照例である。ソフトウェア アップグレード50によって、このIPv6端末47がIPv4ネットワーク55をエミュレートすることが可能である。これはIPv6端末47がIPv4ソフトウェアやハードウェアを使用し続けることを可能にする。このようなソフトウェアアップグレード50によるIPv6端末47へのIPv4ネットワーク55のエミュレーションは、印刷を行えるよう、IPv6端末47とそれと連動しているIPv4プリンター57との通信を可能にするような、日常的な行ためを可能にする。
一例として、IPv6ネットワーク46上のIPv6完全対応型PC 47でもなお、(簡単にはアップグレードが出来ない)時代遅れのソフトウェアアプリケーションを幾つも稼動することを強いられる可能性がある。特に管理や会計ソフトウェアは大抵、長く勤めている秘書や事務員達が使用し、彼らはしばしば変化に対して強い抵抗を示す。
そのようなソフトウェアを適応させるのは難しい。概して、最初にそのソフトウェアをプログラムした会社はもはや存続していなかったり、ユーザーマニュアル等のサポート手続きが存在しない場合もある。そのようなソフトウェアに手を加えるのは多大なるの投資を要し、且つバグや誤作動の危険を伴う可能性がある。しかし、そんなアプリケーション上に多くの重要なデータがしばしば保存されており、そのようなアプリケーションを稼動し続けることが必要不可欠である。論理的には、IPv4コンピューターとそのプリンターを接続しているLANやバックアップ手段を利用出来るが、このようなシステムは実用的でないばかりか、どのコンピューターでもそのソフトウェアを稼動出来ることや、(少なくとも)プリンターや印刷のためのバックアップサーバーとの交信が可能となることの利点、そして、バックアップの目的そのものの有利性は、すぐに明白となるだろう。
本発明の中継媒体50はIPv6 PC 47でIPv4ソフトウェアを稼動することを可能にし、プリンター57やサーバー58といった、その他複数のネットワーク ノードとの通信を可能にする。この中継媒体50は、(パケットの再構築またはカプセル化のいずれかによって)変換テーブルを介して変換を可能にするソフトウェアパッチとして導入され得る。
類似のソフトウェア アップグレード50'は、IPv4ネットワーク12上のIPv4 端末17のために提供され得る。このように、IPv4端末17は複数のIPv4 デバイスとしてインターネットを横切り、IPv6端末47と通信が出来るようになるだろう。
殆どの行政法人にとって、彼らのファイヤーウォール防御管理や展開には、技術や知識、更に一般的には多額の費用が要求される。IPv4を用いるファイヤーウォールに、多大な投資をした行政法人は、IPv6テクノロジーへ再投資することに気が乗らず、その遂行に伴うセキュリティを脅かす危険性を理由に、彼らのファイヤーウォールに手を加えるのを実に好まない。
図6は、ファイヤーウォール13が、外界と結合したあらゆるネットワーク12にとって、重要な意味を持つ要素であることを示す。ファイヤーウォール13の背部にあるIPv4ネットワーク12は、IPv4パケットストリームとして、中継媒体10を通じてデータ6を送受信する。この中継媒体10は、(IPv4ネットワーク14に接続されることが決定付けられている)複数のIPv4データパケットをそのまま伝送する。しかし、(IPv6ネットワーク16に通信することが決められた、又は、IPv6ネットワーク16から受信される)データ6は、ファイヤーウォール13の複数の規則に従って、IPv4として再設定やカプセル化される。このように中継媒体10は、ニーズに合わせ苦労の末、設定したファイヤーウォール13を所有する企業が、その要請を踏まえた上で操作することを可能にするが、とはいえ必要に応じて、IPv6ネットワークを超えた外界との通信を促進する。
ファイヤーウォール13に保護されているネットワーク12と本発明の中継媒体10を結合することにより―IPv6とのアップ/ダウンストリーム通信や、ファイヤーウォール13を経由するために再設定や再パケット化されたIPv4フォームにデータパケットと共に―IPv4 ファイヤーウォール13の操作の継続を可能にする。このように、セキュリティ監査され、侵入テストにも耐え、おそらくISOからの保証を得てSerbanes-Oxley法などにも則ったIPv4 ウォールフォールの維持が可能となる。企業はファイヤーウォールを越えてIPv6プロトコールを使用しながらの通信を続行することが出来、更にファイヤーウォール13内のIPv6へと徐々に移行していくことさえ出来る。
一方、ファイヤーウォール13はそのまま残すことが出来る。なぜなら、ファイヤーウォール13を経由する全てのデータは、そこを経由してデータ移行を行えるようにIPv4に変換されることが可能だからである。
(過去数年に遂行されていることが期待される)IPv4からIPv6への段階的移行期間中、IPv4とIPv6の両ネットワーク上での通信を可能にすることには多くの利点がある。負荷分散は、複数の並列データリンクを横切るデータ転送を可能にするための一般的な技法である。データリンクへの入り口点の後ろに中継媒体が連結されている限り、データは正確に移行されるであろう。因みに本中継媒体はそのリンク上で伝送するために、データを適切な形式への変換を可能にする。
本発明はIPv4とIPv6ネットワークリンク間の負荷分散を可能にする。これは、時間の掛かるIPv6への移行、及び、両ネットワークが共存する場合おそらく長期間に亘るであろうIPv6への移行に際し、特に有効である。今まで会社やユーザー達は、いつIPv4からIPv6ベースに移行すべきか、とりわけ、どちらのネットワークの密集度が少ないかに関して予測を元に、決定を下さなくてはいけなかった。いまや、両ネットワークを横切る負荷分散が容易になされる。
図7は、IPv4ルーター22がその後ろに(おそらくファームウェアとして)中継媒体30と結合し、IPv4 ルーター26がその後ろに(おそらくファームウェアとして)中継媒体40と結合した場合、IPv4端末17とIPv6端末47は、その複数のローカルネットワーク上で、或いは直接接続されている複数のルーター/モデム22や26上で、利益を得ることを示している。このように、結果的に負荷分散を可能しながら(IPv4リンクやネットワーク72, 74上、又は、複数のIPv6リンクやネットワークである76上での)複数のルーター22と26の間で通信が可能になる。
IPv4ヘッダー(図8)とIPv6ヘッダー(図9)の比較で示すように、IPv4ヘッダーはIPv6通信では必要としない幾つかのフィールドを含む。これらのフィールドは、IHL(ヘッダーの長さ), IDENT(ID), フラグ, フラグメント オフセット, チェックサム, オプションそしてパディングを含む。本発明の中継媒体10による中継行ためは本質的に、数あるデータパッケージのIPv4ヘッダーから適切なフィールドを複数取り出すことや、これらのデータパッケージを複数のIPv6データパッケージとして再設定することで構成され得る。これは概して、単なる変換プロセスであり、一つのプロトコルから他のプロトコルに変換するようデータ分析を要さない。
この中継媒体を導入する主なコンセプトは、専用ミドルウェアとしての導入にある。通常これは、ネットワーク インターフェイス 入出力機能を持った単独型“プラグ&プレイ”デバイスであり、複数の好適な実施形態では、それ自体のIPv4アドレスとIPv6アドレスを両方所有することになり、結果、いずれのネットワークからも設定やアクセスされることが可能となる。このようなデバイスはシンプルな一定の規則と共に、大抵は自動的に作動する。通常、当該する規則はプリセット デフォルトとして提供されるだろうが、大抵はユーザー設定が可能だろう。このタイプの専用ミドルウェアは、入力時に受信された複数のパケットを分析しそのまま送信する、もしくは必要ならば、そのダウンストリームの数ある要求に従って、再構築やカプセル化による変換を行う。
ほんの一部の実現例として、このミドルウェアを操作するための一定規則は、以下のようになり得る:
1.IPv6 -> AS-ISを出力1へ転送
2.IPv4 領域 192.168.1.0-192.168.1.255 -> IPv6 アドレス X-Y として再構築し、出力 1へ転送
3.IPv4アドレス101.1.0.4 -> IPv6 アドレス Zとしてカプセル化し、
出力1への宛先Uに送信
4.ほかのIPv4アドレス-> AS-ISを出力1へ転送
ミドルウェアとして設定された中継媒体は単一ネットワークや、2つのネットワーク、又は、(有効な入出力ポートの数に従い)もっと多くのネットワークと接続されるだろう。
この中継媒体の操作論理は、そのデバイスがとてもシンプルな機能なのでとても容易なものとなるだろう。中継媒体の操作は原則的に、以下の複数の機能の少なくとも一部を使用する演算手順に従う:
1.パケットがIPv4であるか確定する
2.パケットがIPv6であるか確定する
3.複数のIPv4アドレスを抽出する
4.複数のIPv6アドレスを抽出する
5.IPv4をIPv6として再構築する機能
6.IPv6をIPv4として再構築する機能
7.複数のIPv4パケットをIPv6の中にカプセル化する機能
8.複数のIPv6パケットをIPv4の中にカプセル化する機能
9.複数のIPv4パケットをIPv4の中にカプセル化する機能
10.複数のIPv6パケットをIPv6の中にカプセル化する機能
11.この機能性を管理する規則表を保管する
12.規則表やその他複数の設定を組み込むインターフェイスを所有する
13.複数の異なった入出力を処理する機能を所有する(複数の規則は、単なるプロトコール固有やアドレス固有ではなく、ポート固有である可能性がある。)
14.一般的通信基準をサポートする(イサーネットやATM等)- 標準デバイス(ネットワークカードやモジュラー等)と通信出来る
例証として、中継媒体が受信データをいかにして処理するかに関する、基本的なフローチャートが図10に描かれている。
模範的な中継媒体110の基本的機能要素を示す図12には、複数のIPv4データパケットを識別するIPv4データパケット 識別子114,複数のIPv6データパケットを識別するIPv6データパケット 識別子112,IPv6アドレス エクストラクー116,IPv4メタデータアドレス エクストラクター118,IPv4 > IPv6 カプセル化装置 120, IPv4 > IPv6 カプセル化装置 122, IPv4 > IPv4 カプセル化装置 124, IPv6からIPv4パケットへ 再構築する装置 126, IPv6 > IPv4 カプセル化装置 127, IPv4からIPv6パケットへ 再構築する装置128, (本中継媒体が設定されるのを可能にする)設定インターフェイス130が含まれている。本中継媒体110が、そのネットワーク上で遠隔的に設定可能であるのが望ましい。考慮条件一覧表又はデータベース132は、複数の規則を保管するためとパケットの動きを見極めるダイナミックな決定ツリーを整えるために提供されており、更に、中継媒体110の複数のポートを設定するためのネットワーク通信インターフェイス134や(多角的なシナリオにおけるデバイスの動きに関するルールを明確にする規則固有/ポート固有テーブルである)多角的インターフェイス規則136も含有する。
上記の実施例が制限のない証例であることは高く評価されるだろう。この一般的な論理は、上記した複数の機能や、複数のデータパッケージを(それらの性質に従って)そのまま転送,カプセル化,再構築する中継媒体、そして、そのアップストリームとダウンストリーム機器の機能によって成り立っている。
この中継媒体は概して、例えば“私用インターネットのためのアドレス割付”のようなRFC1593 を踏まえる、制限されたIPv4アドレスを利用し、 一定規則と共にあらかじめプログラムされて提供されるであろう。
このあらかじめ規定された一定規則は、(i) 全てのIPv6をIPv4へ変換する(カプセル化), (ii) 全てのIPv4をIPv6へ変換する(カプセル化), (iii) 全てのIPv6をIPv4へ変換する(再構築), (iv) 全てのIPv4をIPv6へ交換する(再構築), (v)IPv4の特定アドレス領域をIPv6へ変換する(再構築)といった、単体のデータパケット変換コマンドを含み得る。
しかし別の方法として、テクノロジーにより精通したユーザーが(おそらく何千もの規則やファイルから簡単にダウンロード出来る一定のインポート/エクスポート規則すべてを所有しつつ)とても具体的なレベルまで、全ての規則を手動で定義出来るよう、本中継媒体が提供されるのが好ましいと考えられる。このように、各デバイスやノードや導入は、―困難な再設定なしに―然るべき設定によるセットアップが可能である。各再設定は概して一つの組織に対し一度行われ、その後全てのデバイスへと取込まれるだろう。一方で、このような複数の規則の導入や特定の最適化されたセットアップが手動で管理出来るという方法も高く評価されるだろう。考慮条件一覧表に関する任意的設定は図11に示されており、それは複数の規則をカスタマイズするための様々なオプションを紹介している。
ある実施例では、この中継媒体はIPv4デバイスを再設定せずに、IPv6インフラと接続する独立したデバイスとして設定されている。
第二の実施例においては、この中継媒体はIPv6デバイスを再設定せずに、IPv4インフラと接続する独立したデバイスとして設定されている。
第三の実施例では、この中継媒体はIPv4デバイス上にIPv6機能を後付けする、IPv4デバイスのアップグレードとして設定されている。
第四の実施例では、この中継媒体は、IPv4ネットワーク内で IPv4デバイスとして稼動しつつ、 IPv6デバイス上に IPv4の機能を後付けするための、IPv6のダウングレードとして設定されている。
ファームウェアにより、ハードウェアデバイス内に組み込まれているソフトウエェアが対象となる。フラッシュ ROM上、又は、ユーザーが既存のハードウェア上にアップロード出来る2進法イメージファイルとして、しばしば供給される。
本発明のより深い理解のため且つ事実上どのように実践されるかを示すため、(純粋なある一例として)添付図表を参照して欲しい。
具体的な基準として詳細に描かれているこれらの図表は、本発明のみの望ましい実施例に関する証例や具体的な考察を目的とし、この発明の原理や概念的見地を、もっとも実用的且つ容易に理解を促す説明になり得ると信ずるものを提供することを目的として提示されている。ただし、この発明の根本的な理解を促すのに必要であると思われる以上に、構造細部を示す試みは行われていない。ちなみに、この図を用いた説明は、実施において本発明の様々な様式がどのように具現化されるかを、この技術において高い技術力を持つ人々に明らかにするものである。
フローチャートとブロック図は、本発明のコンセプトが本分野に傑出した技術者に理解されることを促すための、最善の伝送方法として作成されている。
ファイヤーウォールの後ろにあるIPv4ネットワークネットワークがIPv4とIPv6両ネットワーク上の端末装置と通信することを可能にするポートとなる、本発明の実施例を踏まえた中継媒体の概略図である。 IPv4ネットワークのIPv4フロントデバイスとIPv6ネットワークのIPv6フロントデバイスの間を中継するミドルウェアとなる、本発明の実施例を踏まえた概略図である。 本発明の第二実施例を踏まえた概略図であり、IPv6ネットワークのIPv6フロントデバイスとの通信を可能にしつつ、IPv4ネットワークのIPv4フロントデバイスに対するファームウェア アップグレードとして設定されている様子を示している。 IPv6フロントデバイスと結合してIPv4エミュレーションを可能にする中継媒体の概略図である。 IPv4エミュレーションを可能にする中継媒体ソフトウェアアップグレートによってIPv6ターミナル機器とIPv4ネットワーク上のIPv4ターミナル機器が通信出来るシステムの概略図である。 IPv4ファイヤーウォールの後ろにあるIPv4データが、(IPv4データをそのままに残し、或いは、それぞれにIPv6 に変換されつつ)IPv4ネットワークとIPv6ネットワークと通信することを可能にする中継媒体の概略図である。 本発明の中継媒体テクノロジーが、いかに効果的な負荷バランスを可能にするかを描いている。 IPv6ヘッダー内では省略されるフィールド(下線により明示)を伴ったIPv4ヘッダーを示している。 基本的なIPv6ヘッダーを表している。 中継媒体の外部機能を表したフローチャートである。 中継媒体設定のための様々なオプションを示した一例で、 模範的な中継媒体の機能ブロック図である。
符号の説明
10 中継媒体
12 IPv4 ネットワーク
14 IPv4 ネットワーク
16 IPv6 ネットワーク
20 中継媒体(ミドルウェア)
22 IPv4 フロントデバイス
25 IPv6 ネットワーク エミュレーション セグメント
26 IPv6 フロントデバイス
30 中継媒体(ファームウェア アップグレード)
35 IPv6 ネットワーク エミュレーション セグメント
40 中継媒体(スペシャル ファームウェア)
45 IPv4 ネットワーク エミュレーション セグメント
46 IPv6 ネットワーク
47 IPv6 端末(PC)
50 中継媒体(ソフトウェア アップグレード)
50’ 中継媒体(ソフトウェア アップグレード)
55 IPv4 ネットワーク
57 プリンター
58 サーバー
13 ファイヤーウォール
6 データ
17 IPv4 端末
72 IPv4 リンク
74 IPv4 ネットワーク
76 IPv6 リンク/ネットワーク
110 中継媒体
112 IPv6 データパケット識別子
114 IPv4 データパケット識別子
116 IPv6メタデータ エクストラクター
118 IPv4メタデータ エクストラクター
120 IPv4>IPv6 カプセル化装置
122 IPv6 カプセル化装置
124 IPv4>IPv4カプセル化装置
126 IPv6>IPv4パケット再構築装置
127 IPv6>IPv4カプセル化装置
128 IPv4>IPv6パケット再構築装置
130 設定インターフェイス
132 考慮条件一覧表/データベース
134 ネットワーク通信インターフェイス
136 多角的インターフェイス規則

Claims (7)

  1. IPv4とIPv6ネットワーク化された機器の間の中継を行う為の中継媒体であって、
    ネットワークの中のノードに割り当てられ、
    (a)ソースと宛先がIPv4と互換性を持つ機器であり、IPv4データパケットをそれを横断して簡単に伝達可能にすること
    (b)ソースと宛先がIPv6互換性を持つ機器であり、IPv6データパケットをそれを横断して簡単に伝達可能にすること
    (c) IPv4互換ソースからIPv6宛先へとデータが移動し、IPv6データパケットとしてIPv4データパケットを再パケット化すること、そして
    (d)Ipv4互換ソースからIpv6宛先へとデータが移動し、Ipv6データパケットとしてIpv4データパケットを再パケット化すること、
    が構成可能な中継媒体。
  2. ハードウェア,ソフトウェア,ファームウェア,またはその混合体として構成される請求項1に記載の中継媒体。
  3. 中継行為はカプセル化やパケット再構築のうち少なくとも1つからなる請求項1に記載の中継媒体
  4. IPv4デバイスの再構築なしに、 IPv6インフラへIPv4デバイスを接続する単独型デバイスとして構成される請求項1の中継媒体。
  5. IPv6デバイスの再構築なしに、 IPv4インフラへIPv6デバイスを接続する単独型デバイスとして構成される請求項1の中継媒体。
  6. IPv4デバイス上へIPv6機能を後付する、IPv4デバイスのアップグレードとしてこうせいされる請求項1の中継媒体。
  7. IPv6 デバイス上へIPv4機能を後付する、IPv6デバイスのダウングレードとして設定され、それがIPv4ネットワーク内でIPv4デバイスとして作動することを可能にする請求項1に記載の中継媒体。
JP2007114071A 2006-07-25 2007-04-24 インターネットデータ伝送中継媒体 Pending JP2008042881A (ja)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
IL177084A IL177084A0 (en) 2006-07-25 2006-07-25 Internet Data Transmission Mediator

Publications (1)

Publication Number Publication Date
JP2008042881A true JP2008042881A (ja) 2008-02-21

Family

ID=39177350

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2007114071A Pending JP2008042881A (ja) 2006-07-25 2007-04-24 インターネットデータ伝送中継媒体

Country Status (2)

Country Link
JP (1) JP2008042881A (ja)
IL (1) IL177084A0 (ja)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2013507801A (ja) * 2009-10-10 2013-03-04 ゼットティーイー コーポレーション Ipv4ネットワークと新しいネットワークとの相互通信の実現方法及びシステム
JP2019087908A (ja) * 2017-11-08 2019-06-06 Necプラットフォームズ株式会社 IPv6ネットワークシステム、ホームゲートウェイ装置、マイグレーション技術適用方法、同適用プログラム
CN114143230A (zh) * 2020-09-02 2022-03-04 中国移动通信集团安徽有限公司 双栈用户dns解析时长计算方法及装置

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2003348173A (ja) * 2002-05-24 2003-12-05 Hitachi Ltd アドレス変換機能を備えたパケット転送装置

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2003348173A (ja) * 2002-05-24 2003-12-05 Hitachi Ltd アドレス変換機能を備えたパケット転送装置

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2013507801A (ja) * 2009-10-10 2013-03-04 ゼットティーイー コーポレーション Ipv4ネットワークと新しいネットワークとの相互通信の実現方法及びシステム
US9191317B2 (en) 2009-10-10 2015-11-17 Zte Corporation Method and system for implementing interconnection between internet protocol version 4 network and new network
JP2019087908A (ja) * 2017-11-08 2019-06-06 Necプラットフォームズ株式会社 IPv6ネットワークシステム、ホームゲートウェイ装置、マイグレーション技術適用方法、同適用プログラム
CN114143230A (zh) * 2020-09-02 2022-03-04 中国移动通信集团安徽有限公司 双栈用户dns解析时长计算方法及装置
CN114143230B (zh) * 2020-09-02 2023-07-21 中国移动通信集团安徽有限公司 双栈用户dns解析时长计算方法及装置

Also Published As

Publication number Publication date
IL177084A0 (en) 2007-09-20

Similar Documents

Publication Publication Date Title
US11128493B2 (en) Method for implementing residential gateway service function, and server
JP4130962B2 (ja) ネットワーク上のデスティネーションへ送信されたデータの経路決めをするドメイン名を使用するためのシステムおよび方法
US8798060B1 (en) Converting between tunneling protocols
US9258272B1 (en) Stateless deterministic network address translation
Babatunde et al. A comparative review of internet protocol version 4 (ipv4) and internet protocol version 6 (ipv6)
Albkerat et al. Analysis of IPv6 transition technologies
Bi et al. IPv4/IPv6 transition technologies and univer6 architecture
Zhai et al. Transition from ipv4 to ipv6: A translation approach
Punithavathani et al. IPv4/IPv6 transition mechanisms
Ahmed et al. Security threats for IPv6 transition strategies: A review
Hamarsheh et al. Assuring interoperability between heterogeneous (IPv4/IPv6) networks without using protocol translation
Singalar et al. Performance analysis of IPv4 to IPv6 transition mechanisms
JP2008042881A (ja) インターネットデータ伝送中継媒体
CN101707573A (zh) 一种实现ipv4和ipv6网互通的过渡体系架构
Hamarsheh et al. Transition to IPv6 protocol, Where we are?
Bieringer Linux IPv6 HOWTO (it)
Risdianto et al. IPv6 Tunnel Broker implementation and analysis for IPv6 and IPv4 interconnection
Xia et al. An IPv6 translation scheme for small and medium scale deployment
Ghumman Effects of IPV4/IPv6 Transition Methods in IoT (Internet of Things): A survey
Sivaprakash et al. Configuring Linux system for internet protocol based multimedia communication network
Hamarsheh et al. Exploiting local IPv4-only access networks to deliver IPv6 service to end-users
GB2440436A (en) Mediators for interfacing IPv4 and IPv6 systems
Hughes Transition Mechanisms
Khudhair et al. Research article A prototype and roadmap for transition to IPv6 with performance evaluation
Udeagha et al. Migrating from IPV4 to IPV6 in Jamaica

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20100415

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20110310

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20110711

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20110726

A601 Written request for extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A601

Effective date: 20111025

A602 Written permission of extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A602

Effective date: 20111028

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20111125

A02 Decision of refusal

Free format text: JAPANESE INTERMEDIATE CODE: A02

Effective date: 20111220