JP3665622B2 - ソースアドレス選択システム、ルータ装置、通信ノード及びソースアドレス選択方法 - Google Patents
ソースアドレス選択システム、ルータ装置、通信ノード及びソースアドレス選択方法 Download PDFInfo
- Publication number
- JP3665622B2 JP3665622B2 JP2002097652A JP2002097652A JP3665622B2 JP 3665622 B2 JP3665622 B2 JP 3665622B2 JP 2002097652 A JP2002097652 A JP 2002097652A JP 2002097652 A JP2002097652 A JP 2002097652A JP 3665622 B2 JP3665622 B2 JP 3665622B2
- Authority
- JP
- Japan
- Prior art keywords
- source address
- internet service
- packet
- service provider
- communication node
- 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.)
- Expired - Fee Related
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L45/00—Routing or path finding of packets in data switching networks
- H04L45/02—Topology update or discovery
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
- H04L69/167—Adaptation for transition between two IP versions, e.g. between IPv4 and IPv6
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L61/00—Network arrangements, protocols or services for addressing or naming
- H04L61/50—Address allocation
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Security & Cryptography (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明は、家庭やＳＯＨＯなどがＩＰｖ６を用いて複数のＩＳＰを介してインターネットで常時接続された場合において、適切に出口ルータを選択するためのソースアドレス選択システム、ルータ装置、通信ノード及びソースアドレス選択方法に関する。
【０００２】
【従来の技術】
近年、世界最大のコンピュータネットワーク「インターネット（Ｉｎｔｅｒｎｅｔ）」の利用が普及しており、このインターネットと接続し、公開された情報、サービスを利用したり、逆にインターネットを通してアクセスしてくる外部ユーザに対し、情報、サービスを提供することで、新たなコンピュータビジネスが開拓されている。また、インターネット利用に関して、新たな技術開発、展開がなされている。インターネットでは、各計算機がＩＰアドレスと呼ばれる識別子を持ち、このＩＰアドレスをもとに、パケットの交換が行われる。通常、インターネットに接続する場合には、ＩＳＰ（Ｉｎｔｅｒｎｅｔ Ｓｅｒｖｉｃｅ Ｐｒｏｖｉｄｅｒ）と契約してアドレスの割り当てを受けることになる。
【０００３】
現在のＩＰｖ６のアドレスの割り当ては、プロバイダ・ベース（ｒｏｖｉｄｅｒ Ｂａｓｅ）である。すなわち、あるプロバイダと契約した場合に、そのプロバイダがすでに割り当てられているアドレスの部分集合を、割り当ててもらうことになる。
【０００４】
今後、家庭やＳＯＨＯなど小規模なネットワークであっても、インターネットの安定した利用等を目的として、複数のプロバイダと契約をすることが考えられる。この場合、このネットワークとインターネットとの接続点は複数となり、このような状況をマルチホームと呼ぶ。
【０００５】
図１２に示すように、ノードＮがプロバイダＡとＢを介してインターネットと接続しているとする。ＩＰｖ６では、ノードが複数のアドレスを持てるため、この場合、ノードＮは、プロバイダＡにより割り当てられたアドレスと、プロバイダＢにより割り当てられたアドレスとを使うことが可能である。
【０００６】
【発明が解決しようとする課題】
ここで、図１２において、プロバイダＡで障害が発生し、インターネットからＡを経由してノードＮにパケットを届けることができなくなったとする。
【０００７】
もし、ノードＮが、プロバイダＡに属するアドレスをソースアドレス（送信元アドレス）（ｓｏｕｒｃｅ ａｄｄｒｅｓｓ）に使ってサーバＳと通信しようとした場合には、サーバＳと通信することはできないことになる。ノードＮから、プロバイダＡに属するアドレスをソースアドレスとして、パケットを送信すると、プロバイダＡ側は障害が発生しているため、サーバＳへの経路が絶たれてしまっているからである。
【０００８】
そこで、例えば、現在のＩＰｖ４プロトコルが行なっているように、プロバイダＡに属するアドレス宛のパケットをプロバイダＢを経由して届くように経路を変更することができれば解決可能であるが、このような変更は経路表の大幅な増加につながり、アドレス空間が広大なＩＰｖ６プロトコルでの実現は、従来の技術では極めて困難である。
【０００９】
なお、かりに、上記のプロバイダＡに属するアドレスをソースアドレスとしたパケットがプロバイダＢの経路を経由してサーバＳへ到達したと仮定する。この場合、サーバＳは、前述したプロバイダＡに属するアドレスをソースアドレスとして持つパケットを受信すると、このソースアドレスに基づいて送信元ノードと通信しようと試みるため、プロバイダＡの経路を経由した通信を確立しようとする。しかしながら、サーバＳからの返信パケットは、プロバイダＡに障害があるためノードＮに到達することができず、通信ができない。加えて、ＩＰｖ６では、ｉｎｇｒｅｓｓ ｆｉｌｔｅｒ（イングレス・フィルタ）（ＩＥＴＦ ＲＦＣ２２６７、ＲＦＣ２８２７）が導入される場合が非常に多いが、それが導入されるている場合には、そもそもプロバイダＡに属するするアドレスを宛先に持つパケットがプロバイダＢを通ることが許されず、サーバＳにパケットが届かない。
【００１０】
ＳＯＨＯなどにおいて、このような問題のためにマルチホームが効率的に利用出来ない場合、インターネットの信頼性を向上させることは困難である。
【００１１】
以上のように、従来の技術では、ＩＰｖ６環境でマルチホームを有効に利用することは困難であった。
【００１２】
本発明は、上記事情を考慮してなされたもので、マルチホーム環境を有効に利用することを可能とするソースアドレス選択システム、ルータ装置、通信ノード及びソースアドレス選択方法を提供することを目的とする。
【００１３】
【課題を解決するための手段】
本発明は、複数のインターネットサービスプロバイダに接続されたルータ装置と、このルータに接続された通信ノードとを含むソースアドレス選択システムにおいて、前記ルータ装置は、前記インターネットサービスプロバイダとの接続性を確認する第１の確認手段と、前記第１の確認手段により接続性が確認できた前記インターネットサービスプロバイダが提供するネットワークプレフィクスを受信する第１の受信手段と、前記受信したネットワークプレフィクスを前記通信ノード宛に通知する通知手段とを具備し、前記通信ノードは、前記ルータから前記ネットワークプレフィクスを受信する第２の受信手段と、前記ネットワークプレフィクスと自通信ノード固有の識別子に基づいてネットワークアドレスを生成する生成手段と、パケットを送信する際に前記ネットワークアドレスをソースアドレスとしてヘッダに付与して送信する送信手段とを具備し、前記ルータ装置は更に、前記通信ノードから受信したパケットが、自ルータ装置が接続性を確認できているインターネットサービスプロバイダから受信したネットワークプレフィクスを持つソースアドレスか否かを確認する第２の確認手段と、前記ソースアドレスが、自ルータ装置が接続性を確認できているインターネットサービスプロバイダから受信したネットワークプレフィクスを持っているソースアドレスであった場合は、該ネットワークプレフィクスを受信したインターネットサービスプロバイダ宛に該パケットを転送し、前記ソースアドレスが、自ルータ装置が接続性を確認できているインターネットサービスプロバイダから受信したネットワークプレフィクスを持っているソースアドレスではなかった場合は、該パケットの転送を行わず、前記通信ノード宛に該パケットの転送を行わなかったことを通知するとともに、前記第１の確認手段により接続性が確認できた前記インターネットサービスプロバイダが提供するネットワークプレフィクスを前記通信ノード宛に通知する制御手段とを具備したことを特徴とする。
また、本発明は、複数のインターネットサービスプロバイダに接続されたルータ装置と、このルータに接続された通信ノードとを含むソースアドレス選択システムにおいて、前記ルータ装置は、前記インターネットサービスプロバイダとの接続性を確認する第１の確認手段と、前記第１の確認手段により接続性が確認できた前記インターネットサービスプロバイダが提供するネットワークプレフィクスを受信する第１の受信手段と、前記受信したネットワークプレフィクスを前記通信ノード宛に通知する通知手段とを具備し、前記通信ノードは、前記ルータから前記ネットワークプレフィクスを受信する第２の受信手段と、前記ネットワークプレフィクスと自通信ノード固有の識別子に基づいてネットワークアドレスを生成する生成手段と、パケットを送信する際に前記ネットワークアドレスをソースアドレスとしてヘッダに付与して送信する送信手段とを具備し、前記ルータ装置は更に、前記通信ノードから受信したパケットが、自ルータ装置が接続性を確認できているインターネットサービスプロバイダから受信したネットワークプレフィクスを持つソースアドレスか否かを確認する第２の確認手段と、前記ソースアドレスが、自ルータ装置が接続性を確認できているインターネットサービスプロバイダから受信したネットワークプレフィクスを持っているソースアドレスであった場合は、該ネットワークプレフィクスを受信したインターネットサービスプロバイダ宛に該パケットを転送し、前記ソースアドレスが、自ルータ装置が接続性を確認できているインターネットサービスプロバイダから受信したネットワークプレフィクスを持っているソースアドレスではなかった場合は、該パケットの転送を行わず、前記通信ノード宛に該パケットの転送を行わなかったことを通知する制御手段とを具備し、前記ルータ装置の前記制御手段は、前記ソースアドレスが、自ルータ装置が接続性を確認できているインターネットサービスプロバイダから受信したネットワークプレフィクスを持っているソースアドレスではなかった場合に、前記第１の確認手段により接続性が確認できている前記インターネットサービスプロバイダがその時点で存在しないならば、該パケットの転送を行わず、前記通信ノード宛に該パケットの転送を行わなかったことを通知するとともに、前記パケットの送信先とすべき他のルータ装置を前記通信ノード宛に通知する機能を更に具備することを特徴とする。
また、本発明は、複数のインターネットサービスプロバイダに接続されたルータ装置と、このルータに接続された通信ノードとを含むソースアドレス選択システムにおいて、前記ルータ装置は、前記インターネットサービスプロバイダとの接続性を確認する第１の確認手段と、前記第１の確認手段により接続性が確認できた前記インターネットサービスプロバイダが提供するネットワークプレフィクスを受信する第１の受信手段と、前記受信したネットワークプレフィクスを前記通信ノード宛に通知する通知手段とを具備し、前記通信ノードは、前記ルータから前記ネットワークプレフィクスを受信する第２の受信手段と、前記ネットワークプレフィクスと自通信ノード固有の識別子に基づいてネットワークアドレスを生成する生成手段と、パケットを送信する際に前記ネットワークアドレスをソースアドレスとしてヘッダに付与して送信する送信手段とを具備し、前記ルータ装置は更に、前記通信ノードから受信したパケットが、自ルータ装置が接続性を確認できているインターネットサービスプロバイダから受信したネットワークプレフィクスを持つソースアドレスか否かを確認する第２の確認手段と、前記ソースアドレスが、自ルータ装置が接続性を確認できているインターネットサービスプロバイダから受信したネットワークプレフィクスを持っているソースアドレスであった場合は、該ネットワークプレフィクスを受信したインターネットサービスプロバイダ宛に該パケットを転送し、前記ソースアドレスが、自ルータ装置が接続性を確認できているインターネットサービスプロバイダから受信したネットワークプレフィクスを持っているソースアドレスではなかった場合は、該パケットの転送を行わず、前記通信ノード宛に該パケットの転送を行わなかったことを通知する制御手段とを具備し、前記ルータ装置の前記制御手段は、前記ソースアドレスが、自ルータ装置が接続性を確認できているインターネットサービスプロバイダから受信したネットワークプレフィクスを持っているソースアドレスであっても、所定の条件を満たす場合には、前記通信ノード宛に該パケットの転送を行わなかったことを通知するとともに、使用すべき前記インターネットサービスプロバイダが提供するネットワークプレフィクスを前記通信ノード宛に通知する機能を更に具備することを特徴とする。
また、本発明は、複数のインターネットサービスプロバイダに接続されるとともに、ローカルネットワークに接続され、このローカルネットネットワークに接続された通信ノードのパケットを転送するルータ装置において、前記インターネットサービスプロバイダとの接続性を確認する第１の確認手段と、前記第１の確認手段により接続性が確認できた前記インターネットサービスプロバイダが提供するネットワークプレフィクスを受信する受信手段と、前記受信したネットワークプレフィクスを前記ローカルネットワークに対し通知する通知手段と、前記通信ノードから受信したパケットが、自ルータ装置が接続性を確認できているインターネットサービスプロバイダから受信したネットワークプレフィクスを持つソースアドレスか否かを確認する第２の確認手段と、前記ソースアドレスが、自ルータ装置が接続性を確認できているインターネットサービスプロバイダから受信したネットワークプレフィクスを持っているソースアドレスであった場合は、該ネットワークプレフィクスを受信したインターネットサービスプロバイダ宛に該パケットを転送し、前記ソースアドレスが、自ルータ装置が接続性を確認できているインターネットサービスプロバイダから受信したネットワークプレフィクスを持っているソースアドレスではなかった場合は、該パケットの転送を行わず、前記通信ノード宛に該パケットの転送を行わなかったことを通知するとともに、前記第１の確認手段により接続性が確認できた前記インターネットサービスプロバイダが提供するネットワークプレフィクスを前記通信ノード宛に通知する制御手段とを具備したことを特徴とする。
また、本発明は、複数のインターネットサービスプロバイダに接続されるとともに、ローカルネットワークに接続され、このローカルネットネットワークに接続された通信ノードのパケットを転送するルータ装置において、前記インターネットサービスプロバイダとの接続性を確認する第１の確認手段と、前記第１の確認手段により接続性が確認できた前記インターネットサービスプロバイダが提供するネットワークプレフィクスを受信する受信手段と、前記受信したネットワークプレフィクスを前記ローカルネットワークに対し通知する通知手段と、前記通信ノードから受信したパケットが、自ルータ装置が接続性を確認できているインターネットサービスプロバイダから受信したネットワークプレフィクスを持つソースアドレスか否かを確認する第２の確認手段と、前記ソースアドレスが、自ルータ装置が接続性を確認できているインターネットサービスプロバイダから受信したネットワークプレフィクスを持っているソースアドレスであった場合は、該ネットワークプレフィクスを受信したインターネットサービスプロバイダ宛に該パケットを転送し、前記ソースアドレスが、自ルータ装置が接続性を確認できているインターネットサービスプロバイダから受信したネットワークプレフィクスを持っているソースアドレスではなかった場合は、該パケットの転送を行わず、前記通信ノード宛に該パケットの転送を行わなかったことを通知する制御手段とを具備し、前記制御手段は、前記ソースアドレスが、自ルータ装置が接続性を確認できているインターネットサービスプロバイダから受信したネットワークプレフィクスを持っているソースアドレスではなかった場合に、前記第１の確認手段により接続性が確認できている前記インターネットサービスプロバイダがその時点で存在しないならば、該パケットの転送を行わず、前記通信ノード宛に該パケットの転送を行わなかったことを通知するとともに、前記パケットの送信先とすべき他のルータ装置を前記通信ノード宛に通知する機能を更に具備することを特徴とする。
また、本発明は、複数のインターネットサービスプロバイダに接続されるとともに、ローカルネットワークに接続され、このローカルネットネットワークに接続された通信ノードのパケットを転送するルータ装置において、前記インターネットサービスプロバイダとの接続性を確認する第１の確認手段と、前記第１の確認手段により接続性が確認できた前記インターネットサービスプロバイダが提供するネットワークプレフィクスを受信する受信手段と、前記受信したネットワークプレフィクスを前記ローカルネットワークに対し通知する通知手段と、前記通信ノードから受信したパケットが、自ルータ装置が接続性を確認できているインターネットサービスプロバイダから受信したネットワークプレフィクスを持つソースアドレスか否かを確認する第２の確認手段と、前記ソースアドレスが、自ルータ装置が接続性を確認できているインターネットサービスプロバイダから受信したネットワークプレフィクスを持っているソースアドレスであった場合は、該ネットワークプレフィクスを受信したインターネットサービスプロバイダ宛に該パケットを転送し、前記ソースアドレスが、自ルータ装置が接続性を確認できているインターネットサービスプロバイダから受信したネットワークプレフィクスを持っているソースアドレスではなかった場合は、該パケットの転送を行わず、前記通信ノード宛に該パケットの転送を行わなかったことを通知する制御手段とを具備し、前記制御手段は、前記ソースアドレスが、自ルータ装置が接続性を確認できているインターネットサービスプロバイダから受信したネットワークプレフィクスを持っているソースアドレスであっても、所定の条件を満たす場合には、前記通信ノード宛に該パケットの転送を行わなかったことを通知するとともに、使用すべき前記インターネットサービスプロバイダが提供するネットワークプレフィクスを前記通信ノード宛に通知する機能を更に具備することを特徴とする。
また、本発明は、複数のインターネットサービスプロバイダに接続されたルータ装置を介して所望の通信ノードとの通信を行う通信ノードにおいて、前記ルータから、インターネットサービスプロバイダが提供するネットワークプレフィクスを受信する受信手段と、前記ネットワークプレフィクスと自通信ノード固有の識別子に基づいてネットワークアドレスを生成する生成手段と、パケットを送信する際に前記ネットワークアドレスをソースアドレスとしてヘッダに付与して送信する送信手段とを具備し、前記送信手段にて送信したパケットに対し前記ルータから転送を行わなかった通知を受けるとともに接続性が確認できた前記インターネットサービスプロバイダのネットワークプレフィクスの通知を受けた場合には、前記パケットのソースアドレスを、新たに前記通知を受けたネットワークプレフィクスと自通信ノード固有の識別子に基づいて生成されたネットワークアドレスに変更し、前記パケットを再度送信することを特徴とする。
【００２７】
なお、装置に係る本発明は方法に係る発明としても成立し、方法に係る本発明は装置に係る発明としても成立する。
また、装置または方法に係る本発明は、コンピュータに当該発明に相当する手順を実行させるための（あるいはコンピュータを当該発明に相当する手段として機能させるための、あるいはコンピュータに当該発明に相当する機能を実現させるための）プログラムとしても成立し、該プログラムを記録したコンピュータ読取り可能な記録媒体としても成立する。
【００２８】
本発明によれば、インターネットサービスプロバイダとの接続状況を考慮し、インターネットへの出口ルータに応じたソースアドレスの選択ができるようにすることで、マルチホーム環境を有効に利用可能とすることができる。
【００２９】
【発明の実施の形態】
以下、図面を参照しながら発明の実施の形態を説明する。
【００３０】
図１に、本発明の一実施形態に係るマルチホーム環境を含むネットワーク・システムの構成例を示す。図１では、家庭内やＳＯＨＯなどにおかれたネットワーク構成の例を示している。
【００３１】
図１において、Ｎは、ＩＰｖ６アドレスを持つ通信ノードである。通信ノードＮは、典型的には、計算機であるが、これに限らず、複数のインターネットサービスプロバイダをそれぞれ介してインターネットに接続することが可能なものであれば、携帯電話端末や情報家電等、どのような形態のものでもよい。
【００３２】
Ｉは、インターネットである。
【００３３】
Ｓは、インターネットに接続されたサーバであり、本実施形態では、通信ノードＮの通信相手の一例として示している。もちろん、通信ノードＮの通信相手は、サーバ以外の種類の通信ノードであっても構わない。
【００３４】
Ｒ１，Ｒ２は、いずれも、ルータであり、通信ノードＮからみたインターネットへの出口ルータである。
【００３５】
ＩＳＰａとＩＳＰｂは、いずれも、インターネットへ接続され、通信ノードに対してインターネットへの接続サービスを提供するインターネットサービスプロバイダ（のネットワーク）であり、通信ノードＮからみると、ルータＲ１側に接続されている。
【００３６】
ＩＳＰｃとＩＳＰｄは、いずれも、インターネットへ接続され、通信ノードに対してインターネットへの接続サービスを提供するインターネットサービスプロバイダ（のネットワーク）であり、通信ノードＮからみると、ルータＲ２側に接続されている。
【００３７】
本例では、各インターネットサービスプロバイダＩＳＰａ〜ＩＳＰｄは、通信ノードＮへ、インターネット上のサーバＳとの通信を可能とするサービスを提供している（以下、インターネットサービスプロバイダを、適宜、プロバイダあるいはＩＳＰと記述する）。
【００３８】
ここで、プロバイダＩＳＰａとルータＲ１との間は、専用線での常時接続のような接続形態であってもよいし、ダイヤルアップのような接続形態であってもよい。プロバイダＩＳＰｂとルータＲ１との間の接続形態、プロバイダＩＳＰｃとルータＲ２との間の接続形態、プロバイダＩＳＰｄとルータＲ２との間の接続形態のいずれについても、同様である。
【００３９】
なお、“Ｐａ”は、プロバイダＩＳＰａが提供するプレフィクス（ネットワークプレフィクス）を示すものとする。同様に、“Ｐｂ”，“Ｐｃ”，“Ｐｄ”は、それぞれ、プロバイダＩＳＰｂ，ＩＳＰｃ，ＩＳＰｄが提供するプレフィクスを示す。
【００４０】
また、通信ノードＮが各プロバイダＩＳＰａ，ＩＳＰｂ，ＩＳＰｃ，ＩＳＰｄからそれぞれプレフィクスをもらうとすると、通信ノードＮのインターフェースＩＤ（Ｉｎｔｅｒｆａｃｅ ＩＤ）（通信ノードＮに固有の識別子）をＮとすれば、通信ノードＮは、“Ｐａ：：Ｎ”，“Ｐｂ：：Ｎ”，“Ｐｃ：：Ｎ”，“Ｐｄ：：Ｎ”の４つのネットワークアドレス（この場合、グローバルアドレス）を持つことになる。ここでは、１２８ｂｉｔのＩＰｖ６アドレスのうち、「上位６４ｂｉｔ」は「プロバイダからもらうプレフィクス」からなり、「下位６４ｂｉｔ」は「インタフェースＩＤ」からなるものと仮定する。なお、ネットワークアドレスは、通常、各インタフェースに付与されることになる。
【００４１】
なお、図１の構成例では、通信ノードＮは、２台のルータのいずれかを介して４つのＩＳＰを利用可能としているが、もちろん、何台のルータであってもよいし、幾つのＩＳＰが利用可能でもよい。また、１台のルータを介して幾つのＩＳＰが利用可能でもよい。
【００４２】
また、図１の構成例では、通信ノードを１台のみ示しているが、通信ノードＮと同一のサブネットに他の通信ノードが存在しても構わない。
【００４３】
また、図１の構成例では、通信ノードＮの通信相手を１台のみ示しているが、もちろん、それ以外にも存在し得る。また、通信ノードＮの通信相手は、直接、インターネットに接続されていてもよいし、通信ノードＮとは異なるＩＳＰを介して接続されていてもよいし、通信ノードＮと同一のＩＳＰを介して接続されていてもよいし、ＩＳＰ以外のサブネットを介して接続されていてもよい。また、通信ノードＮの通信相手が、本発明を適用したマルチホームの利用者であってもよいし、そうでなくてもよい。
【００４４】
以下では、主にルータＲ１を例にとってその構成・動作について説明するが、ルータＲ１のみについて説明している部分は、ルータＲ２についても基本的には同様である。
【００４５】
図２に、本発明の一実施形態に係るルータ（Ｒ１，Ｒ２）の構成例を示す。
【００４６】
図２に示されるように、本実施形態のルータは、通信ノードＮ（に繋がる各回線）側またはＩＳＰ（に繋がる各回線）側からパケットを受信するための受信部３１、通信ノードＮ（に繋がる各回線）側またはＩＳＰ（に繋がる各回線）側へパケットを送信するための送信部３２、通常のルータの役割であるパケットを転送するために必要な処理とともに、詳しくは後述するように、ＩＳＰとの接続性に基づく通信ノードからのパケットのＩＳＰへの転送の可否の判断、パケットを転送しなかった際の通信ノードＮへの通知、通信ノードへの使用すべきプレフィクスの通知等の処理を行うためのパケット転送処理部３３、対象となるＩＳＰの状態を管理（接続性を確認）するためのＩＳＰ状態管理部３４、対象となるＩＳＰから提供されたプレフィクスを管理するためのプレフィクス管理部３５を備えている。なお、ＩＳＰの状態に関する情報（例えば、接続性が確認されているか否かを示す情報）や割当てられたプレフィクス等の必要な情報は、適当な記憶装置に格納される。また、図２では、通信ノードＮが接続されたサブネットに接続するための通信インタフェースや、各々のＩＳＰに繋がる回線に接続するための各々の通信インタフェースは、省略している。
【００４７】
なお、本ルータＲ１は、コンピュータを使用して実現可能であり、また、処理の全部又は一部をプログラムによって実施することが可能であるし、処理の全部又は一部を専用の半導体集積回路によって実施することも可能である。
【００４８】
図３に、本発明の一実施形態に係る通信ノードＮの構成例を示す。
【００４９】
図３に示されるように、本実施形態の通信ノードは、ルータＲ１，Ｒ２が接続されたサブネットからパケットを受信するための受信部１１、該サブネットへパケットを送信するための送信部１２、通信相手との間でパケットのやり取りを行うために必要な処理とともに、詳しくは後述するように、使用すべきＩＳＰの選択や、ルータ（Ｒ１，Ｒ２）からの通知に対する処理等の処理を行うためのパケット転送処理部１３、ルータ（Ｒ１，Ｒ２）から通知されたプレフィクスを管理するためのプレフィクス管理部１４、ルータ（Ｒ１，Ｒ２）から通知されたプレフィクスと自通信ノードのインタフェースＩＤとに基づいてネットワークアドレスを生成するためのネットワークアドレス生成部１５を備えている。なお、それらプレフィクスやネットワークアドレス等の必要な情報は、適当な記憶装置に格納される。また、図３では、通信インタフェースは、省略している。
【００５０】
なお、本通信ノードは、処理の全部又は一部をプログラムによって実施することが可能であるし、処理の全部又は一部を専用の半導体集積回路によって実施することも可能である。
【００５１】
以下、本実施形態の動作について説明する。
【００５２】
まず、初期の段階について説明する。
【００５３】
ルータＲ１は、ＩＳＰａ，ＩＳＰｂとの接続性を確認し、接続性が確認できたＩＳＰが提供するプレフィクスを受信し、受信したプレフィクスを格納して管理するとともに、その全部又は一部を通信ノードＮに通知する（あるいは、サブネット内に広告する）。
【００５４】
同様に、ルータＲ２は、ＩＳＰｃ，ＩＳＰｄとの接続性を確認し、接続性が確認できたＩＳＰが提供するプレフィクスを受信し、受信したプレフィクスを格納して管理するとともに、その全部又は一部を通信ノードＮに通知する（あるいは、サブネット内に広告する）。
【００５５】
一方、通信ノードＮは、ルータＲ１やルータＲ２からプレフィクスを受信し、受信したプレフィクスを格納するとともに、プレフィクスと自通信ノードのインタフェースＩＤとに基づいてネットワークアドレスを生成して、該当するインタフェースへ付与する。例えば、先に例示したように、“Ｐａ：：Ｎ”，“Ｐｂ：：Ｎ”，“Ｐｃ：：Ｎ”，“Ｐｄ：：Ｎ”の４つのネットワークアドレスが生成され、（インタフェースに）付与される。
【００５６】
通信ノードＮは、１つ以上のネットワークアドレスが生成された後に、（当該ＩＳＰに接続性があれば）サーバＳと通信可能になる。
【００５７】
また、通信ノードＮは、２つ以上のネットワークアドレスが生成され同一のインタフェースに付与された後には、該インタフェースについて、ソースアドレスとして使用すべきネットワークアドレスを適宜選択すればよい。なお、選択の方法は、例えば、ランダムに選択する方法、何らかの順番で選択するという基準、プレフィクスがライフタイムを持つ場合には、最も遅く期限が切れるライフタイムを持つものを選択する、など、種々のバリエーションがある。また、通信を行う通信主体（例えば、アプリケーションソフトウェア等）によっては、使用すべきＩＳＰの属性（例えば、転送速度、サービス内容、料金等）に応じて優先順位が指定される場合もある。また、通信主体によっては、使用すべきＩＳＰの属性が指定される場合もある。
【００５８】
次に、ルータによる各ＩＳＰとの接続性の定期的な確認について説明する。
【００５９】
なお、ルータＲ１は、ＩＳＰａ，ＩＳＰｂとの接続性を定期的に確認し、接続性に変化があれば、プレフィクスの管理内容を更新する。例えば、それまで接続性が確認されていたＩＳＰの接続性が確認できなかった場合には、接続性の確認されたＩＳＰから割当てを受けたプレフィクスを保持した管理情報において、その接続性が確認できないものに転じたＩＳＰから割当てを受けていたプレフィクスを使用不可に更新し、あるいは該管理情報から、そのプレフィクスを削除する。また、例えば、それまで接続性が確認されていなかったＩＳＰの接続性が確認できた場合には、接続性の確認されたＩＳＰから割当てを受けたプレフィクスを保持した管理情報において、その接続性が確認でるものに転じたＩＳＰから割当てを受けたプレフィクスを使用可能に更新し、あるいはそのＩＳＰからプレフィクスを受信して該管理情報に追加する。接続性に変化があった場合に、通信ノードＮに通知（あるいは、サブネット内に広告）してもよいが、それ以降に通信ノードＮからパケットを受信した際に必要に応じて（例えば、受信パケットのソースアドレスのプレフィクスに基づいて判断して必要があれば）通信ノードＮに通知するようにしてもよい。
【００６０】
ルータＲ１が各ＩＳＰの接続性を定期的に確認する方法は、特に限定されないが、例えば、所定の間隔で、確認したいＩＳＰを介して近接探索パケットを所望の通信ノード宛に送信するようにしてもよい。また、例えば、ＩＳＰ側から定期的に、接続が正常である通知を受け取るようにしてもよいし、接続されたＩＳＰよりもさらに上流の通信路の状態を受け取るようにしてもよい。
【００６１】
次に、図４に、ルータＲ１が通信ノードＮからパケットを受信した場合の処理手順の一例を示す。
【００６２】
ルータＲ１は、通信ノードＮからのパケットを受け取ると（ステップＳ１）、そのパケットのヘッダ部にあるソースアドレス（ｓｒｃ ａｄｄｒ）が所定の条件を満たすかどうか確認する（ステップＳ２）。
【００６３】
ここで、所定の条件とは、受信パケットのソースアドレスのプレフィクスが、接続性を確認できているＩＳＰから提供されたプレフィクスであること、である。すなわち、例えば、ＩＳＰａとＩＳＰｂの接続性が確認されている場合には、ルータＲ１は、そのソースアドレスが、現在、自ルータが接続しているＩＳＰａから割当てを受けているプレフィクスとＩＳＰｂから割当てを受けているプレフィクスのいずれかに該当するプレフィクスが付いているアドレスであるか否か確認する。また、例えば、ＩＳＰａのみの接続性が確認されている場合には、ルータＲ１は、そのソースアドレスが、現在、自ルータが接続しているＩＳＰａから割当てを受けているプレフィクスのいずれかに該当するプレフィクスが付いているアドレスであるか否か確認する。
【００６４】
通信ノードＮからの受信パケットのソースアドレスが、現在、自ルータが接続しているＩＳＰから割当てを受けているプレフィクスのいずれかに該当するプレフィクスが付いているアドレスであった場合（ステップＳ３）、ルータＲ１は、該受信パケットを該当するＩＳＰに向けて転送する（ステップＳ４）。
【００６５】
一方、そのソースアドレスが、現在、自ルータが接続しているＩＳＰから割当てを受けているプレフィクスのいずれかにも該当しないプレフィクスが付いているアドレスであった場合（ステップＳ３）、そのパケットを送信してきた通信ノードＮに対し、例えばＩＣＭＰ（Ｉｎｔｅｒｎｅｔ Ｃｏｎｔｒｏｌ Ｍｅｓｓａｇｅ Ｐｒｏｔｏｃｏｌ）を用いて、パケットの転送を行わなかった旨（すなわち、そのソースアドレスが持つプレフィクスは使用できない旨）を示す情報（ｐｒｅｆｉｘ−ｉｎｃｏｒｒｅｃｔ）を送信する（ステップＳ５）。
【００６６】
次に、図５に、通信ノードＮがサーバＳを宛先とするパケットを送信し、これがルータＲ１へ転送され、ルータＲ１が該パケットを転送しなかった場合の処理手順の一例を示す。
【００６７】
まず、通信ノードＮが、サーバＳを宛先とするパケットを送信する（ステップＳ１１）。
【００６８】
その際、ソースアドレスとして選択したアドレスのプレフィクスが、ルータＲ１により現在接続性が確認されていない状態になったＩＳＰに係るものであったとする。この場合、前述のように、ルータＲ１は、通信ノードＮに対し、パケットの転送を行わなかった旨を含む通知メッセージを送信することになる。
【００６９】
しかして、通信ノードＮは、ルータＲ１から、パケットの転送を行わなかった旨の通知を受信した場合（ステップＳ１２）、その通知を受けた当該パケットについて送信時に使用したソースアドレスのプレフィクスとは異なるプレフィクスによるネットワークアドレスが、サーバＳを宛先とするパケットのソースアドレスとして使用可能かどうか調べる（ステップＳ１３）。
【００７０】
使用可能であれば（ステップＳ１４）、その使用可能なネットワークアドレスをソースアドレスとしてヘッダに付与して、サーバＳを宛先とするパケットを、再度、送信する（ステップＳ１５）。
【００７１】
一方、使用不可（異なるプレフィクスによるネットワークアドレスがない場合の他に、それがあっても何らかに理由によって当該通信には使用できない場合がある）であれば（ステップＳ１４）、エラー処理を行う（ステップＳ１６）。エラー処理としては、何もしない、上位レイヤに通信に失敗した旨（当該ソースアドレスが持つプレフィクスは使用できない旨）を通知する、一定時間待ってステップＳ１３に戻る、など、種々のバリエーションが考えられる。
【００７２】
なお、ステップＳ１３で、上記の代わりに、その通知を受けた当該パケットについて送信時に使用したソースアドレスのプレフィクスに係るＩＳＰとは異なるＩＳＰに係るプレフィクスによるネットワークアドレスが、サーバＳを宛先とするパケットのソースアドレスとして使用可能かどうか調べるようにしてもよい。
【００７３】
また、ステップＳ１２で、ルータＲ１から、パケットの転送を行わなかった旨の通知を受信した場合には、直ちに、エラー処理（例えば、何もしない、上位レイヤに通信に失敗した旨（当該ソースアドレスが持つプレフィクスは使用できない旨）を通知する、通信に失敗した旨及びその際に使用したプレフィクスを通知する、など）に移行してしまう方法もある（後は、例えば、上位レイヤによる処理あるいはユーザによる対処がなされる）。
【００７４】
次に、図６に、ルータＲ１が通信ノードＮからパケットを受信した場合の処理手順の他の例を示す。
【００７５】
図４の手順例では、受信パケットのソースアドレスが所定の条件を満たさないために該パケットを転送しなかった場合には、ルータＲ１は、通信ノードＮに対し、パケットの転送を行わなかった旨を通知したが、この手順例では、その際に、この通知（例えば、ＩＣＭＰメッセージ）に、現在接続性が確認されているＩＳＰから提供されたプレフィクスをも含めて、通信ノードＮへ通知するようにするものである（ステップＳ２３，Ｓ２５）。
【００７６】
例えば、ＩＳＰａが何らかの理由で接続が絶たれており、ＩＳＰｂのみの接続が確認されている場合に、通信ノードＮからＩＳＰｂに係るプレフィクス以外のプレフィクス（例えば、ＩＳＰａに係るプレフィクス）によるソースアドレスを持つパケットを受信したならば、ＩＳＰｂから提供されたプレフィクスＰｂのみを通信ノードＮに通知する。
【００７７】
また、例えば、ＩＳＰａ及びＩＳＰｂの両方の接続性が確認されてる場合に、通信ノードＮからＩＳＰａ及びＩＳＰｂに係るプレフィクス以外のプレフィクスによるソースアドレスを持つパケットを受信したならば、ＩＳＰａから提供されたプレフィクスＰａ及びＩＳＰｂから提供されたプレフィクスＰｂを通信ノードＮに通知する。
【００７８】
図７に、この場合のＩＣＭＰ（ｐｒｅｆｉｘ−ｉｎｃｏｒｒｅｃｔ）メッセージの構成例を示す。
【００７９】
図７において、
「ＩＰｖ６ヘッダ」（図中、２１）は、ＩＰｖ６パケットであること示すヘッダ、
「ＩＣＭＰヘッダ」（図中、２２）は、ＩＣＭＰメッセージであることを示すヘッダ、
「ｔａｒｇｅｔ ｄｓｔ ｐｒｅｆｉｘｌｅｎ（対象宛先プレフィクス長）」（図中、２３）は、このＩＣＭＰメッセージに含まれるｐｒｅｆｅｒｒｅｄ−ｐｒｅｆｉｘ（推奨プレフィクス）が有効な宛先（ｄｅｓｔｉｎａｔｉｏｎ）となるアドレスレンジを示すためのフィールド、
「ｎｕｍｂｅｒ ｏｆ ｐｒｅｆｅｒｒｅｄ−ｐｒｅｆｉｘ（推奨プレフィクス数）」（図中、２４）は、このＩＣＭＰメッセージに含まれるｐｒｅｆｅｒｒｅｄ−ｐｒｅｆｉｘの数を示すためのフィールド、
「ｐｒｅｆｅｒｒｅｄ−ｐｒｅｆｉｘ（推奨プレフィクス）」（図中、２５〜２７）は、それぞれ、使用を推奨するプレフィクスを示すためのフィールド、
「原因パケット」（図中、２８）は、このＩＣＭＰメッセージがルータＲ１から発せられる原因となったパケットである。
【００８０】
ここで、「ｔａｒｇｅｔ ｄｓｔ ｐｒｅｆｉｘｌｅｎ」は、例えば１２８なら“／１２８”という意味であり、上位１２８ビットで有効なアドレスレンジを指定している。通常、原因となったパケットの宛先そのものにしか有効でないが、例えば、この値が６４なら、上位６４ｂｉｔのプレフィクスが一致する場合に限り、このｐｒｅｆｅｒｒｅｄ−ｐｒｅｆｉｘを使用することで、有効なＩＳＰを介してパケットを送信することができる。ルータＲ１は、何らかの方法でこの値を得られる場合には、得られた適切な値を入れる。そうでなければ、−１を入れる（１２８が入るのは、明らかなホストルータ（ｈｏｓｔ ｒｏｕｔｅ）を持っている場合である）。
【００８１】
次に、図８に、通信ノードＮの処理手順の他の例（図６の手順例に対応する例）を示す。
【００８２】
まず、通信ノードＮが、サーバＳを宛先とするパケットを送信する（ステップＳ３１）。
【００８３】
その際、ソースアドレスとして選択したアドレスのプレフィクスが、ルータＲ１により現在接続性が確認されていない状態になったＩＳＰに係るものであったとすると、ルータＲ１は、通信ノードＮに対し、パケットの転送を行わなかった旨及び現在接続性が確認されているＩＳＰから提供されたプレフィクスを含む通知を含む通知メッセージを送信することになる。
【００８４】
しかして、通信ノードＮは、ルータＲ１から、パケットの転送を行わなかった旨及び現在接続性が確認されているＩＳＰから提供されたプレフィクスを含む通知を受信する（ステップＳ３２）。
【００８５】
この場合、通信ノードＮは、必要に応じて、その通知を受けたプレフィクスとプレフィクスと自通信ノードのインタフェースＩＤとに基づいてネットワークアドレスを生成し（ステップＳ３３）、その通知を受けたパケットについて、ソースアドレスを、この生成されたアドレスに変更して（生成されたアドレスを、ソースアドレスとしてヘッダに付与して）、再度、送信する（ステップＳ３４）。
【００８６】
なお、該当するアドレスが既に生成されて、インタフェースに付与されている場合には、ステップＳ３３はスキップしても構わない。
【００８７】
また、複数のプレフィクスが通知された場合には、複数のネットワークアドレスが生成可能であるが、この場合に、ソースアドレスとして使用すべきネットワークアドレスを先に例示した選択方法などで適宜選択すればよい。
【００８８】
また、アプリケーションソフトウェア等の通信主体によっては、通知されたプレフィクスによるネットワークアドレスがソースアドレスとして使用できない場合もあり得る。
【００８９】
ところで、ルータＲ１において、どのようなパケット転送制御を行うか、あるいはどのようにｐｒｅｆｅｒｒｅｄ−ｐｒｅｆｉｘ（推奨プレフィクス）の通知の仕方をするかについては、種々のバリエーションが考えられる。
【００９０】
例えば、ルータＲ１は、ＩＳＰａ側の回線の帯域が広いことを予め知っており、デフォルトでＩＳＰａ側を使用する設定であったとしても、通信ノードＮ側から受信したパケットのソースアドレスにＩＳＰｂ側のプレフィクスＰｂが使われている場合には、この指示を優先しＩＳＰｂ側にそのパケットを転送するように制御してもよい。
【００９１】
また、例えば、ＩＳＰａ側の回線の帯域がＩＳＰｂよりも大幅に広い場合で通信ノードＮから受信したパケットがＩＳＰｂ側のプレフィクスを使用したソースアドレスであった場合には、（たとえＩＳＰｂの接続性が確認されていても）ＩＣＭＰ（ｐｒｅｆｉｘ−ｉｎｃｏｒｒｅｃｔ）等のメッセージを通信ノードＮに通知すると同時にＩＳＰａのプレフィクスを使用するように通知するようにしてもよい。これにより、通信ノードＮは、最初に送信したパケットではＩＳＰｂを使用していたが、ルータＲ１よりＩＳＰａ側のプレフィクスの通知を受けることにより、より帯域の広いＩＳＰａを介した通信が可能となる。
【００９２】
また、例えば、ルータＲ１は、自通信ノードが接続されるＩＳＰａ，ＩＳＰｂに係るプレフィクスを通信ノードＮに通知する代わりに、ルータＲ２へのリダイレクトを応答する制御も考えられる。
【００９３】
さて、以下では、図９及び図１０のシーケンス例を参照しながら、ルータＲ１の動作例について説明する。
【００９４】
まず、図１の構成例において、ルータＲ１が通信ノードＮからパケットを受信した際にＩＳＰａの接続性が確認されている場合を考える。
【００９５】
この場合に、通信ノードＮが、図９（ａ）のように、ソースアドレス＝“Ｐａ：：Ｎ”、宛先アドレス＝“Ｓ”とするパケット（ｓｒｃ＝Ｐａ：：Ｎ ， ｄｓｔ＝Ｓ）をルータＲ１に向けて送信したとする（Ｓ１０１）。ここで、ＩＳＰａがルータＲ１において優先すべきＩＳＰであると予め定められていたとすると、この場合には、ルータＲ１は、通信ノードＮから受信したパケットをＩＳＰａに転送する（Ｓ１０２）。
【００９６】
次に、ルータＲ１が通信ノードＮからパケットを受信した際にＩＳＰａの接続性が絶たれていた場合を考える。
【００９７】
この場合に、通信ノードＮが、図９（ｂ）のように、ソースアドレス＝“Ｐａ：：Ｎ”、宛先アドレス＝“Ｓ”とするパケット（ｓｒｃ＝Ｐａ：：Ｎ ， ｄｓｔ＝Ｓ）をルータＲ１に向けて送信したとする（Ｓ１２１）。
【００９８】
ここで、受信したパケットを接続性が保たれている他のＩＳＰｂに転送してもｉｎｇｒｅｓｓ ｆｉｌｔｅｒが導入されていることが多く、ＩＳＰｂにてこのパケットの転送を拒絶されることが予めわかっているので、ルータＲ１は、通信ノードＮに対し、ＩＣＭＰメッセージ（図７参照）を送信するものとする（Ｓ１２２）。このＩＣＭＰメッセージは、ｐｒｅｆｉｘ−ｉｎｃｏｒｒｅｃｔと、推奨するｐｒｅｆｆｅｒｅｄ Ｐｒｅｆｉｘ：Ｐｂを含む。
【００９９】
通信ノードＮは、この通知を受けて、ソースアドレス＝“Ｐｂ：：Ｎ”、宛先アドレス＝“Ｓ”とするパケット（ｓｒｃ＝Ｐｂ：：Ｎ ， ｄｓｔ＝Ｓ）をルータＲ１に向けて送信すると（Ｓ１２３）、この場合には、ルータＲ１は、通信ノードＮから受信したパケットをＩＳＰｂに転送する（Ｓ１２４）。
【０１００】
次に、通信ノードＮが、図９（ｃ）のように、ソースアドレス＝“Ｐａ：：Ｎ”、宛先アドレス＝“Ｓ”とするパケット（ｓｒｃ＝Ｐａ：：Ｎ ， ｄｓｔ＝Ｓ）をルータＲ２に向けて送信した場合を考える（Ｓ１３１）。
【０１０１】
この場合には、ルータＲ２は、基本的には、上記のルータＲ１と同じ動作をすることになる。
【０１０２】
すなわち、通信ノードＮから、上記のパケットを受信したルータＲ２は、受信したパケットのソースアドレスに付与されたプレフィクスＰａが自ルータＲ２と接続しているＩＳＰから通知されたプレフィクスかどうかを確認する。
【０１０３】
このプレフィクスＰａは、自ルータＲ２と接続しているＩＳＰから通知されたプレフィクスではないので、通信ノードＮに向けてＩＣＭＰメッセージを送信する（Ｓ１３２）。このＩＣＭＰメッセージは、ｐｒｅｆｉｘ−ｉｎｃｏｒｒｅｃｔと、ルータＲ２が推奨するｐｒｅｆｆｅｒｄ Ｐｒｅｆｉｘ：Ｐｃ，Ｐｄ（ただし、ＩＳＰｃとＩＳＰｄの接続性がいずれも確認できている場合）を含む。ここで、ＩＳＰｃ，ＩＳＰｄの接続性は予め確認しておくものとする。
【０１０４】
通信ノードＮは、この通知を受けて、例えば、Ｐｃを選択して、ソースアドレス＝“Ｐｃ：：Ｎ”、宛先アドレス＝“Ｓ”とするパケット（ｓｒｃ＝Ｐｃ：：Ｎ ， ｄｓｔ＝Ｓ）をルータＲ２に向けて送信し（Ｓ１３３）、ルータＲ２は、通信ノードＮから受信したパケットをＩＳＰｃに転送する（Ｓ１３４）。
【０１０５】
次に、ＩＳＰａ，ＩＳＰｂの両方の接続が絶たれている場合を想定する。この場合、ルータＲ１は、インターネットへの接続性を果たさない。
【０１０６】
ここで、通信ノードＮが、図１０のように、ソースアドレス＝“Ｐａ：：Ｎ”、宛先アドレス＝“Ｓ”とするパケット（ｓｒｃ＝Ｐａ：：Ｎ ， ｄｓｔ＝Ｓ）をルータＲ１に向けて送信したとする（Ｓ１４１）。
【０１０７】
この場合、ルータＲ１は、ＩＳＰａ，ＩＳＰｂの接続が絶たれているため、通信ノードＮに対し、ＩＣＭＰメッセージとしてｒｅｄｉｒｅｃｔ（リダイレクト）を送信し、これにより、通信ノードＮに対し、パケットの送信先としてルータＲ２を選択させるよう指示を行うようにしてもよい（Ｓ１４２）。
【０１０８】
なお、ルータＲ１は、（例えば、ルータ間の情報交換等により）リダイレクトの対象となる他のルータとしてルータＲ２が存在することを知っている（あるいは知ることができる）ものとする。
【０１０９】
通信ノードＮは、このＩＣＭＰメッセージに基づいて、まず、ソースアドレス＝“Ｐａ：：Ｎ”、宛先アドレス＝“Ｓ”とするパケット（ｓｒｃ＝Ｐａ：：Ｎ
， ｄｓｔ＝Ｓ）をルータＲ２に向けて送信する（Ｓ１４３）。
【０１１０】
ここで、ルータＲ２は、自ルータＲ２が接続されていないＩＳＰのプレフィクスであることから、ｐｒｅｆｉｘ−ｉｎｃｏｒｒｅｃｔと、ルータＲ２が推奨するｐｒｅｆｆｅｒｄ Ｐｒｅｆｉｘ：Ｐｃ，Ｐｄ（ただし、ＩＳＰｃとＩＳＰｄの接続性がいずれも確認できている場合）を含むＩＣＭＰメッセージを送信する（Ｓ１４４）。
【０１１１】
通信ノードＮは、この通知を受けて、例えば、Ｐｃを選択して、ソースアドレス＝“Ｐｃ：：Ｎ”、宛先アドレス＝“Ｓ”とするパケット（ｓｒｃ＝Ｐｃ：：Ｎ ， ｄｓｔ＝Ｓ）をルータＲ２に向けて送信し（Ｓ１４５）、ルータＲ２は、通信ノードＮから受信したパケットをＩＳＰｃに転送する（Ｓ１４６）。
【０１１２】
なお、ＩＳＰａ，ＩＳＰｂの両方の接続が絶たれている場合において、ルータＲ１は、リダイレクトの対象となるルータが複数存在するならば、通信ノードＮに対して、それらから適宜選択した１つのルータを返すようにしてもよい。
【０１１３】
また、ＩＳＰａ，ＩＳＰｂの両方の接続が絶たれている場合において、ルータＲ１は、リダイレクトの対象となるルータがもともと存在しないか、またはリダイレクトの対象となるルータがすべてダウンしているとを知っているならば、通信ノードＮに対して、エラーを返すようにすると好ましい。
【０１１４】
次に、以下では、図９及び図１０のシーケンス例を参照しながら、通信ノードＮの動作例について説明する。
【０１１５】
まず、前述のように通信ノードＮがＩＣＭＰメッセージを受信する場合について説明する。
【０１１６】
通信ノードＮは、ソースアドレス＝“Ｐａ：：Ｎ”、宛先アドレス＝“Ｓ”とするパケット（ｓｒｃ＝Ｐａ：：Ｎ ， ｄｓｔ＝Ｓ）をルータＲ１に向けて送信する（図９（ｂ）のＳ１２１参照）。
【０１１７】
ここで、ソースアドレスとして用いられるプレフィクスは、例えば、デフォルトルータであるルータＲ１から予め通知を受けているものとする。
【０１１８】
次に、前述したようにこの受信したパケットが指定しているＩＳＰａの接続が絶たれていた場合を想定する。この場合は、ルータＲ１から図７に示すＩＣＭＰメッセージが届く。このＩＣＭＰメッセージは、ｐｒｅｆｉｘ−ｉｎｃｏｒｒｅｃｔと、推奨するｐｒｅｆｆｅｒｅｄ Ｐｒｅｆｉｘ：Ｐｂを含む（図９（ｂ）のＳ１２２参照）。
【０１１９】
通信ノードＮは、このＩＣＭＰメッセージを受信すると、このメッセージがどのパケットの送信に対するメッセージであるのかを、図７の原因となるパケット（２８）から判断する。
【０１２０】
次に、このメッセージに含まれるｐｒｅｆｆｅｒｅｄ ｐｒｅｆｉｘ（ここでは、Ｐｂ）から原因となった先のパケットのソースアドレスを書き換えて再度送信する。
【０１２１】
その際、ｐｒｅｆｆｅｒｄ ｐｒｅｆｉｘとして受信したプレフィクス（Ｐｂ）と通信ノードＮが持つインターフェースＩＤとの組合せにより作成したネットワークアドレス“Ｐｂ：：Ｎ”が予め用意されていなければ、これを作成して使用する。
【０１２２】
また、ここで、原因となるパケットを調べ、それに対応しているコネクションが現在あるかどうかどうかを調べてからパケットを再送信するよう制御してもよい。
【０１２３】
原因となるパケットに関連するコネクションがある場合、それが確立前、すなわち発呼中であるかを調べる。例えば、ＴＣＰ上でＳＹＮ＿ＳＥＮＴの状態かどうかを調べることにより実現できる。
【０１２４】
発呼中である場合、そのコネクションのソースアドレスを先のＩＣＭＰメッセージで受信したプレフィックスを付与したソースアドレスにより再度コネクションの設定を行う。ただし、アプリケーションがソースアドレスを明示的に指定している場合には、再設定を行わないように制御してもよい。一例として、一般的なソケットを使っている場合には、ｃｏｎｎｅｃｔ（）を呼ぶ前にｂｉｎｄ（）を呼び、そこでソースアドレスを明示的に指定してきた場合などである。
【０１２５】
さらに、ルータＲ１またはＲ２から受信したＩＣＭＰメッセージを、図１１に例示するようなプレフィクス管理テーブルとして保持するようにしてもよい。ここでは、ＩＣＭＰメッセージを受信したら、その結果を、宛先のアドレスまたはアドレスレンジと、ｐｒｅｆｅｒｒｅｄ−ｐｒｅｆｉｘとの組で、記憶する。
【０１２６】
一例として、“Ｓ：：ａ”にパケットを送信して、これに対しルータＲ１からｐｒｅｆｉｃ−ｉｎｃｏｒｒｅｃｔのＩＣＭＰメッセージを受信した場合について説明する。
【０１２７】
このＩＣＭＰメッセージの中には、ｐｒｅｆｅｒｒｅｄ−ｐｒｅｆｉｘ（推奨プレフィクス）として“Ｐａ”が記載されている。この結果を、アドレスまたはアドレスレンジと、プレフィクスとの組で記憶しておくことにより、次回、“Ｓ：：ａ”宛にパケットを送信する際に、このテーブルを参照し、ソースアドレスを推奨プレフィクスである“Ｐａ：：ａ”と変更してパケットを送信する。
【０１２８】
また、“Ｓ：：／６４”というプレフィクスを持つアドレスの場合、このテーブルを参照し、Ｐａを優先的に使用するように制御してもよい。これにより、予め推奨のプレフィクスを優先的に使用することができるため、ルータからＩＣＭＰメッセージを受信する回数を少なくすることができる。さらに、このテーブルの記憶は、デフォルトルータが変更になったり、通信ノードＮにおけるパケット送信先のルールが変更になった場合は、破棄するようにしてもよい。
【０１２９】
次に、通信ノードＮが、ソースアドレス＝“Ｐａ：：Ｎ”、宛先アドレス＝“Ｓ”とするパケット（ｓｒｃ＝Ｐａ：：Ｎ ， ｄｓｔ＝Ｓ）をルータＲ２に向けて送信した場合について説明する（図１０のＳ１３１参照）。このパケットは、例えば、ＴＣＰコネクション設定のためのパケットである場合を想定する。
【０１３０】
このパケットを受信したルータＲ２は、このパケットのソースアドレスに含まれるＰａのプレフィクスを検出することにより、このＰａのプレフィクスはルータＲ２の上流のＩＳＰからは割り当てられていないことがわかる。
【０１３１】
これにより、ルータＲ２は、このパケットを送信した通信ノードＮに対して、ＩＣＭＰメッセージ（ｐｒｅｆｉｘ−ｉｎｃｏｒｒｅｃｔ）を送信する（図１０のＳ１３２参照）。このＩＣＭＰメッセージには、ルータＲ２が推奨するプレフィクスであるｐｒｅｆｅｒｒｅｄ−ｐｒｅｆｉｘ：Ｐｃ，Ｐｄが含まれている。
【０１３２】
通信ノードＮは、このＩＣＭＰメッセージを受信すると、まず、自通信ノードＮ（通信ノードＮのインターフェースであるインターフェースＮ）に設定されているアドレスと受信したｐｒｅｆｅｒｒｅｄ−ｐｒｅｆｉｘとを比較する。通信ノードＮは、ＰｃとＰｄのプレフィクスをもつアドレスも保持しているため、いずれかを選択してソースアドレスとする。ここでは、Ｐｃを選択し、ソースアドレスを“Ｐｃ：：Ｎ”とする。
【０１３３】
次に、ＩＣＭＰメッセージの中の原因となったパケットを調べる。この際、原因となったパケットのソースアドレス（ｓｒｃ ａｄｄｒ）、宛先アドレス（ｄｓｔ ａｄｄｒ）、ソースポート（ｓｒｃ ｐｏｒｔ）、宛先ポート（ｄｓｔ ｐｏｒｔ）の４つの組を調べることにより、どの接続先へのどのような要求かがわかる。次に、前述したようにこの要求が確立前、すなわち発呼中であるかを調べる。その後、確立前であった場合には、ソースアドレスを“Ｐｃ：：Ｎ”に変更してパケットを再度送信する。
【０１３４】
以下では、通信ノードＮにおける、ルータからＩＣＭＰメッセージ等で通知されたプレフィクスの管理方法について説明する。
【０１３５】
ルータからＩＣＭＰメッセージ等で通知されたプレフィクスを、いつまで使用するか、あるいはいつ破棄するかについては、種々のバリエーションがある。
【０１３６】
なお、プレフィクス管理テーブルを、キャッシュとすれば、基本的には、いつ破棄しても通信に支障はない。
【０１３７】
以下、幾つかのバリエーションを示す。
【０１３８】
（１）通知されたプレフィクスは、そのときのパケットの再送にのみ使用して、破棄する。
メモリの量が少ない通信ノードが通信する場合には、このようにすると、好ましい。同じ通信相手に対して、再度、新しいコネクションを張ろうとする場合には、同じ手順が繰り返される。
【０１３９】
（２）通知されたプレフィクスは、予め定められたイベントが起きるまで、保持し、予め定められたイベントが起きたら、その全部又は一部を破棄する、という処理を、定常的に行う。
例えば、テーブルの大きさを決めて、データが溢れたならば、その時点で、（例えば、最後に参照したエントリを）順次捨てる。
【０１４０】
（３）基本的には、定常的な処理としては、破棄は行わず、破棄すべき状況になった際に、通知されたプレフィクスの全部又は一部を破棄する。
破棄すべき状況とは、例えば、
（３−１）Ｒｅｄｉｒｅｃｔを受けた
（３−２）使っていたルータが（今さっき）ダウンした
などである。
【０１４１】
上記の（３−１）のＲｅｄｉｒｅｃｔを受けた場合について説明する。
例えば、ノードＮが、ルータＲ１とルータＲ２を介してインターネットに接続可能な状況で、過去にルータＲ２から、Ｐｒｅｆｉｘ−ｉｎｃｏｒｒｅｃｔを受けて、ｐｒｅｆｉｘ：ｐｄを通知されたとする。すると、通信ノードＮは、Ｒ２から「Ｓについてはプレフィクスｐｄを推奨する」という通知を受けたことを記憶する。しばらく、ｐｄによって通信可能であったが、ある時点で、ルータＲ２から「Ｓについては、ルータＲ１を推奨する」と通知された（ＩＣＭＰ ｒｅｄｉｒｅｃｔ）とする。このような場合に、ｐｄは、ルータＲ２に依存したプレフィクスなので、少なくともこれは破棄する。また、いままで使ってた経路で突然ｒｅｄｉｒｅｃｔを受けるのは、ルータＲ１，Ｒ２を取り巻く状況が大きく変化した可能性が高いので（例えば、ルータＲ２の先のｌｉｎｋが全部落ちたなど）、プレフィクスを全て破棄するようにしてもよい。
【０１４２】
上記の（３−２）の使っていたルータが（今さっき）ダウンした場合について説明する。
「ＳについてはルータＲ２に転送する」という情報を保持している場合に、ルータＲ２がダウンしたことがわかったならば（例えば、ＩＰｖ６ノードは、定期的に自分が使ってるルータに対して、生存確認を行うので（ＮＵＤ，ＲＦＣ２４６１）、これによって知ることができる）、かなり状況が変わっているので、保持しているプレフィクスは、無意味であり、それらを全て廃棄するようにしてもよい。
【０１４３】
この（３）の処理は、（１）のケースでない限り、実施するのが望ましい（無駄な手順の増加を回避できる）。
【０１４４】
（４）ライフタイム（ｌｉｆｅｔｉｍｅ）を使う
通信ノードＮは、プレフィクスをテーブル等に登録する際に、そのライフタイム（例えば、ｎ秒）を、（例えば通信ノードＮが独自に）決定して、該プレフィクスに対応付けて登録するようにしてもよい。この場合には、その時間が経過した際に、破棄する。
【０１４５】
なお、以上の各機能は、ソフトウェアとして実現可能である。
また、本実施形態は、コンピュータに所定の手段を実行させるための（あるいはコンピュータを所定の手段として機能させるための、あるいはコンピュータに所定の機能を実現させるための）プログラムとして実施することもでき、該プログラムを記録したコンピュータ読取り可能な記録媒体として実施することもできる。
【０１４６】
なお、この発明の実施の形態で例示した構成は一例であって、それ以外の構成を排除する趣旨のものではなく、例示した構成の一部を他のもので置き換えたり、例示した構成の一部を省いたり、例示した構成に別の機能あるいは要素を付加したり、それらを組み合わせたりすることなどによって得られる別の構成も可能である。また、例示した構成と論理的に等価な別の構成、例示した構成と論理的に等価な部分を含む別の構成、例示した構成の要部と論理的に等価な別の構成なども可能である。また、例示した構成と同一もしくは類似の目的を達成する別の構成、例示した構成と同一もしくは類似の効果を奏する別の構成なども可能である。
また、この発明の実施の形態で例示した各種構成部分についての各種バリエーションは、適宜組み合わせて実施することが可能である。
また、この発明の実施の形態は、個別装置としての発明、関連を持つ２以上の装置についての発明、システム全体としての発明、個別装置内部の構成部分についての発明、またはそれらに対応する方法の発明等、種々の観点、段階、概念またはカテゴリに係る発明を包含・内在するものである。
従って、この発明の実施の形態に開示した内容からは、例示した構成に限定されることなく発明を抽出することができるものである。
【０１４７】
本発明は、上述した実施の形態に限定されるものではなく、その技術的範囲において種々変形して実施することができる。
【０１４８】
【発明の効果】
本発明によれば、マルチホーム環境を有効に利用することが可能になる。
【図面の簡単な説明】
【図１】本発明の一実施形態に係るネットワーク・システムの構成例を示す図
【図２】同実施形態に係るルータの構成例を示す図
【図３】同実施形態に係る通信ノードの構成例を示す図
【図４】同実施形態に係るルータの処理手順の一例を示すフローチャート
【図５】同実施形態に係る通信ノードの処理手順の一例を示すフローチャート
【図６】同実施形態に係るルータの処理手順の他の例を示すフローチャート
【図７】同実施形態に係るＩＣＭＰメッセージの構成例を示す図
【図８】同実施形態に係る通信ノードの処理手順の他の例を示すフローチャート
【図９】同実施形態に係るネットワーク・システムのシーケンス例を示す図
【図１０】同実施形態に係るネットワーク・システムのシーケンス例を示す図
【図１１】同実施形態に係るプレフィクス管理テーブルの構成例を示す図
【図１２】従来のマルチホーム環境のネットワーク・システムについて説明するための図
【符号の説明】
Ｎ…通信ノード
Ｒ１，Ｒ２…ルータ
Ｉ…インターネット
ＩＳＰａ，ＩＳＰｂ，ＩＳＰｃ，ＩＳＰｄ…インターネットサービスプロバイダ
Ｓ…サーバ
１１，３１…受信部
１２，３２…送信部
１３，３３…パケット転送処理部
１４，３５…プレフィクス管理部
１５…ネットワークアドレス生成部
３４…ＩＳＰ状態管理部
【発明の属する技術分野】
本発明は、家庭やＳＯＨＯなどがＩＰｖ６を用いて複数のＩＳＰを介してインターネットで常時接続された場合において、適切に出口ルータを選択するためのソースアドレス選択システム、ルータ装置、通信ノード及びソースアドレス選択方法に関する。
【０００２】
【従来の技術】
近年、世界最大のコンピュータネットワーク「インターネット（Ｉｎｔｅｒｎｅｔ）」の利用が普及しており、このインターネットと接続し、公開された情報、サービスを利用したり、逆にインターネットを通してアクセスしてくる外部ユーザに対し、情報、サービスを提供することで、新たなコンピュータビジネスが開拓されている。また、インターネット利用に関して、新たな技術開発、展開がなされている。インターネットでは、各計算機がＩＰアドレスと呼ばれる識別子を持ち、このＩＰアドレスをもとに、パケットの交換が行われる。通常、インターネットに接続する場合には、ＩＳＰ（Ｉｎｔｅｒｎｅｔ Ｓｅｒｖｉｃｅ Ｐｒｏｖｉｄｅｒ）と契約してアドレスの割り当てを受けることになる。
【０００３】
現在のＩＰｖ６のアドレスの割り当ては、プロバイダ・ベース（ｒｏｖｉｄｅｒ Ｂａｓｅ）である。すなわち、あるプロバイダと契約した場合に、そのプロバイダがすでに割り当てられているアドレスの部分集合を、割り当ててもらうことになる。
【０００４】
今後、家庭やＳＯＨＯなど小規模なネットワークであっても、インターネットの安定した利用等を目的として、複数のプロバイダと契約をすることが考えられる。この場合、このネットワークとインターネットとの接続点は複数となり、このような状況をマルチホームと呼ぶ。
【０００５】
図１２に示すように、ノードＮがプロバイダＡとＢを介してインターネットと接続しているとする。ＩＰｖ６では、ノードが複数のアドレスを持てるため、この場合、ノードＮは、プロバイダＡにより割り当てられたアドレスと、プロバイダＢにより割り当てられたアドレスとを使うことが可能である。
【０００６】
【発明が解決しようとする課題】
ここで、図１２において、プロバイダＡで障害が発生し、インターネットからＡを経由してノードＮにパケットを届けることができなくなったとする。
【０００７】
もし、ノードＮが、プロバイダＡに属するアドレスをソースアドレス（送信元アドレス）（ｓｏｕｒｃｅ ａｄｄｒｅｓｓ）に使ってサーバＳと通信しようとした場合には、サーバＳと通信することはできないことになる。ノードＮから、プロバイダＡに属するアドレスをソースアドレスとして、パケットを送信すると、プロバイダＡ側は障害が発生しているため、サーバＳへの経路が絶たれてしまっているからである。
【０００８】
そこで、例えば、現在のＩＰｖ４プロトコルが行なっているように、プロバイダＡに属するアドレス宛のパケットをプロバイダＢを経由して届くように経路を変更することができれば解決可能であるが、このような変更は経路表の大幅な増加につながり、アドレス空間が広大なＩＰｖ６プロトコルでの実現は、従来の技術では極めて困難である。
【０００９】
なお、かりに、上記のプロバイダＡに属するアドレスをソースアドレスとしたパケットがプロバイダＢの経路を経由してサーバＳへ到達したと仮定する。この場合、サーバＳは、前述したプロバイダＡに属するアドレスをソースアドレスとして持つパケットを受信すると、このソースアドレスに基づいて送信元ノードと通信しようと試みるため、プロバイダＡの経路を経由した通信を確立しようとする。しかしながら、サーバＳからの返信パケットは、プロバイダＡに障害があるためノードＮに到達することができず、通信ができない。加えて、ＩＰｖ６では、ｉｎｇｒｅｓｓ ｆｉｌｔｅｒ（イングレス・フィルタ）（ＩＥＴＦ ＲＦＣ２２６７、ＲＦＣ２８２７）が導入される場合が非常に多いが、それが導入されるている場合には、そもそもプロバイダＡに属するするアドレスを宛先に持つパケットがプロバイダＢを通ることが許されず、サーバＳにパケットが届かない。
【００１０】
ＳＯＨＯなどにおいて、このような問題のためにマルチホームが効率的に利用出来ない場合、インターネットの信頼性を向上させることは困難である。
【００１１】
以上のように、従来の技術では、ＩＰｖ６環境でマルチホームを有効に利用することは困難であった。
【００１２】
本発明は、上記事情を考慮してなされたもので、マルチホーム環境を有効に利用することを可能とするソースアドレス選択システム、ルータ装置、通信ノード及びソースアドレス選択方法を提供することを目的とする。
【００１３】
【課題を解決するための手段】
本発明は、複数のインターネットサービスプロバイダに接続されたルータ装置と、このルータに接続された通信ノードとを含むソースアドレス選択システムにおいて、前記ルータ装置は、前記インターネットサービスプロバイダとの接続性を確認する第１の確認手段と、前記第１の確認手段により接続性が確認できた前記インターネットサービスプロバイダが提供するネットワークプレフィクスを受信する第１の受信手段と、前記受信したネットワークプレフィクスを前記通信ノード宛に通知する通知手段とを具備し、前記通信ノードは、前記ルータから前記ネットワークプレフィクスを受信する第２の受信手段と、前記ネットワークプレフィクスと自通信ノード固有の識別子に基づいてネットワークアドレスを生成する生成手段と、パケットを送信する際に前記ネットワークアドレスをソースアドレスとしてヘッダに付与して送信する送信手段とを具備し、前記ルータ装置は更に、前記通信ノードから受信したパケットが、自ルータ装置が接続性を確認できているインターネットサービスプロバイダから受信したネットワークプレフィクスを持つソースアドレスか否かを確認する第２の確認手段と、前記ソースアドレスが、自ルータ装置が接続性を確認できているインターネットサービスプロバイダから受信したネットワークプレフィクスを持っているソースアドレスであった場合は、該ネットワークプレフィクスを受信したインターネットサービスプロバイダ宛に該パケットを転送し、前記ソースアドレスが、自ルータ装置が接続性を確認できているインターネットサービスプロバイダから受信したネットワークプレフィクスを持っているソースアドレスではなかった場合は、該パケットの転送を行わず、前記通信ノード宛に該パケットの転送を行わなかったことを通知するとともに、前記第１の確認手段により接続性が確認できた前記インターネットサービスプロバイダが提供するネットワークプレフィクスを前記通信ノード宛に通知する制御手段とを具備したことを特徴とする。
また、本発明は、複数のインターネットサービスプロバイダに接続されたルータ装置と、このルータに接続された通信ノードとを含むソースアドレス選択システムにおいて、前記ルータ装置は、前記インターネットサービスプロバイダとの接続性を確認する第１の確認手段と、前記第１の確認手段により接続性が確認できた前記インターネットサービスプロバイダが提供するネットワークプレフィクスを受信する第１の受信手段と、前記受信したネットワークプレフィクスを前記通信ノード宛に通知する通知手段とを具備し、前記通信ノードは、前記ルータから前記ネットワークプレフィクスを受信する第２の受信手段と、前記ネットワークプレフィクスと自通信ノード固有の識別子に基づいてネットワークアドレスを生成する生成手段と、パケットを送信する際に前記ネットワークアドレスをソースアドレスとしてヘッダに付与して送信する送信手段とを具備し、前記ルータ装置は更に、前記通信ノードから受信したパケットが、自ルータ装置が接続性を確認できているインターネットサービスプロバイダから受信したネットワークプレフィクスを持つソースアドレスか否かを確認する第２の確認手段と、前記ソースアドレスが、自ルータ装置が接続性を確認できているインターネットサービスプロバイダから受信したネットワークプレフィクスを持っているソースアドレスであった場合は、該ネットワークプレフィクスを受信したインターネットサービスプロバイダ宛に該パケットを転送し、前記ソースアドレスが、自ルータ装置が接続性を確認できているインターネットサービスプロバイダから受信したネットワークプレフィクスを持っているソースアドレスではなかった場合は、該パケットの転送を行わず、前記通信ノード宛に該パケットの転送を行わなかったことを通知する制御手段とを具備し、前記ルータ装置の前記制御手段は、前記ソースアドレスが、自ルータ装置が接続性を確認できているインターネットサービスプロバイダから受信したネットワークプレフィクスを持っているソースアドレスではなかった場合に、前記第１の確認手段により接続性が確認できている前記インターネットサービスプロバイダがその時点で存在しないならば、該パケットの転送を行わず、前記通信ノード宛に該パケットの転送を行わなかったことを通知するとともに、前記パケットの送信先とすべき他のルータ装置を前記通信ノード宛に通知する機能を更に具備することを特徴とする。
また、本発明は、複数のインターネットサービスプロバイダに接続されたルータ装置と、このルータに接続された通信ノードとを含むソースアドレス選択システムにおいて、前記ルータ装置は、前記インターネットサービスプロバイダとの接続性を確認する第１の確認手段と、前記第１の確認手段により接続性が確認できた前記インターネットサービスプロバイダが提供するネットワークプレフィクスを受信する第１の受信手段と、前記受信したネットワークプレフィクスを前記通信ノード宛に通知する通知手段とを具備し、前記通信ノードは、前記ルータから前記ネットワークプレフィクスを受信する第２の受信手段と、前記ネットワークプレフィクスと自通信ノード固有の識別子に基づいてネットワークアドレスを生成する生成手段と、パケットを送信する際に前記ネットワークアドレスをソースアドレスとしてヘッダに付与して送信する送信手段とを具備し、前記ルータ装置は更に、前記通信ノードから受信したパケットが、自ルータ装置が接続性を確認できているインターネットサービスプロバイダから受信したネットワークプレフィクスを持つソースアドレスか否かを確認する第２の確認手段と、前記ソースアドレスが、自ルータ装置が接続性を確認できているインターネットサービスプロバイダから受信したネットワークプレフィクスを持っているソースアドレスであった場合は、該ネットワークプレフィクスを受信したインターネットサービスプロバイダ宛に該パケットを転送し、前記ソースアドレスが、自ルータ装置が接続性を確認できているインターネットサービスプロバイダから受信したネットワークプレフィクスを持っているソースアドレスではなかった場合は、該パケットの転送を行わず、前記通信ノード宛に該パケットの転送を行わなかったことを通知する制御手段とを具備し、前記ルータ装置の前記制御手段は、前記ソースアドレスが、自ルータ装置が接続性を確認できているインターネットサービスプロバイダから受信したネットワークプレフィクスを持っているソースアドレスであっても、所定の条件を満たす場合には、前記通信ノード宛に該パケットの転送を行わなかったことを通知するとともに、使用すべき前記インターネットサービスプロバイダが提供するネットワークプレフィクスを前記通信ノード宛に通知する機能を更に具備することを特徴とする。
また、本発明は、複数のインターネットサービスプロバイダに接続されるとともに、ローカルネットワークに接続され、このローカルネットネットワークに接続された通信ノードのパケットを転送するルータ装置において、前記インターネットサービスプロバイダとの接続性を確認する第１の確認手段と、前記第１の確認手段により接続性が確認できた前記インターネットサービスプロバイダが提供するネットワークプレフィクスを受信する受信手段と、前記受信したネットワークプレフィクスを前記ローカルネットワークに対し通知する通知手段と、前記通信ノードから受信したパケットが、自ルータ装置が接続性を確認できているインターネットサービスプロバイダから受信したネットワークプレフィクスを持つソースアドレスか否かを確認する第２の確認手段と、前記ソースアドレスが、自ルータ装置が接続性を確認できているインターネットサービスプロバイダから受信したネットワークプレフィクスを持っているソースアドレスであった場合は、該ネットワークプレフィクスを受信したインターネットサービスプロバイダ宛に該パケットを転送し、前記ソースアドレスが、自ルータ装置が接続性を確認できているインターネットサービスプロバイダから受信したネットワークプレフィクスを持っているソースアドレスではなかった場合は、該パケットの転送を行わず、前記通信ノード宛に該パケットの転送を行わなかったことを通知するとともに、前記第１の確認手段により接続性が確認できた前記インターネットサービスプロバイダが提供するネットワークプレフィクスを前記通信ノード宛に通知する制御手段とを具備したことを特徴とする。
また、本発明は、複数のインターネットサービスプロバイダに接続されるとともに、ローカルネットワークに接続され、このローカルネットネットワークに接続された通信ノードのパケットを転送するルータ装置において、前記インターネットサービスプロバイダとの接続性を確認する第１の確認手段と、前記第１の確認手段により接続性が確認できた前記インターネットサービスプロバイダが提供するネットワークプレフィクスを受信する受信手段と、前記受信したネットワークプレフィクスを前記ローカルネットワークに対し通知する通知手段と、前記通信ノードから受信したパケットが、自ルータ装置が接続性を確認できているインターネットサービスプロバイダから受信したネットワークプレフィクスを持つソースアドレスか否かを確認する第２の確認手段と、前記ソースアドレスが、自ルータ装置が接続性を確認できているインターネットサービスプロバイダから受信したネットワークプレフィクスを持っているソースアドレスであった場合は、該ネットワークプレフィクスを受信したインターネットサービスプロバイダ宛に該パケットを転送し、前記ソースアドレスが、自ルータ装置が接続性を確認できているインターネットサービスプロバイダから受信したネットワークプレフィクスを持っているソースアドレスではなかった場合は、該パケットの転送を行わず、前記通信ノード宛に該パケットの転送を行わなかったことを通知する制御手段とを具備し、前記制御手段は、前記ソースアドレスが、自ルータ装置が接続性を確認できているインターネットサービスプロバイダから受信したネットワークプレフィクスを持っているソースアドレスではなかった場合に、前記第１の確認手段により接続性が確認できている前記インターネットサービスプロバイダがその時点で存在しないならば、該パケットの転送を行わず、前記通信ノード宛に該パケットの転送を行わなかったことを通知するとともに、前記パケットの送信先とすべき他のルータ装置を前記通信ノード宛に通知する機能を更に具備することを特徴とする。
また、本発明は、複数のインターネットサービスプロバイダに接続されるとともに、ローカルネットワークに接続され、このローカルネットネットワークに接続された通信ノードのパケットを転送するルータ装置において、前記インターネットサービスプロバイダとの接続性を確認する第１の確認手段と、前記第１の確認手段により接続性が確認できた前記インターネットサービスプロバイダが提供するネットワークプレフィクスを受信する受信手段と、前記受信したネットワークプレフィクスを前記ローカルネットワークに対し通知する通知手段と、前記通信ノードから受信したパケットが、自ルータ装置が接続性を確認できているインターネットサービスプロバイダから受信したネットワークプレフィクスを持つソースアドレスか否かを確認する第２の確認手段と、前記ソースアドレスが、自ルータ装置が接続性を確認できているインターネットサービスプロバイダから受信したネットワークプレフィクスを持っているソースアドレスであった場合は、該ネットワークプレフィクスを受信したインターネットサービスプロバイダ宛に該パケットを転送し、前記ソースアドレスが、自ルータ装置が接続性を確認できているインターネットサービスプロバイダから受信したネットワークプレフィクスを持っているソースアドレスではなかった場合は、該パケットの転送を行わず、前記通信ノード宛に該パケットの転送を行わなかったことを通知する制御手段とを具備し、前記制御手段は、前記ソースアドレスが、自ルータ装置が接続性を確認できているインターネットサービスプロバイダから受信したネットワークプレフィクスを持っているソースアドレスであっても、所定の条件を満たす場合には、前記通信ノード宛に該パケットの転送を行わなかったことを通知するとともに、使用すべき前記インターネットサービスプロバイダが提供するネットワークプレフィクスを前記通信ノード宛に通知する機能を更に具備することを特徴とする。
また、本発明は、複数のインターネットサービスプロバイダに接続されたルータ装置を介して所望の通信ノードとの通信を行う通信ノードにおいて、前記ルータから、インターネットサービスプロバイダが提供するネットワークプレフィクスを受信する受信手段と、前記ネットワークプレフィクスと自通信ノード固有の識別子に基づいてネットワークアドレスを生成する生成手段と、パケットを送信する際に前記ネットワークアドレスをソースアドレスとしてヘッダに付与して送信する送信手段とを具備し、前記送信手段にて送信したパケットに対し前記ルータから転送を行わなかった通知を受けるとともに接続性が確認できた前記インターネットサービスプロバイダのネットワークプレフィクスの通知を受けた場合には、前記パケットのソースアドレスを、新たに前記通知を受けたネットワークプレフィクスと自通信ノード固有の識別子に基づいて生成されたネットワークアドレスに変更し、前記パケットを再度送信することを特徴とする。
【００２７】
なお、装置に係る本発明は方法に係る発明としても成立し、方法に係る本発明は装置に係る発明としても成立する。
また、装置または方法に係る本発明は、コンピュータに当該発明に相当する手順を実行させるための（あるいはコンピュータを当該発明に相当する手段として機能させるための、あるいはコンピュータに当該発明に相当する機能を実現させるための）プログラムとしても成立し、該プログラムを記録したコンピュータ読取り可能な記録媒体としても成立する。
【００２８】
本発明によれば、インターネットサービスプロバイダとの接続状況を考慮し、インターネットへの出口ルータに応じたソースアドレスの選択ができるようにすることで、マルチホーム環境を有効に利用可能とすることができる。
【００２９】
【発明の実施の形態】
以下、図面を参照しながら発明の実施の形態を説明する。
【００３０】
図１に、本発明の一実施形態に係るマルチホーム環境を含むネットワーク・システムの構成例を示す。図１では、家庭内やＳＯＨＯなどにおかれたネットワーク構成の例を示している。
【００３１】
図１において、Ｎは、ＩＰｖ６アドレスを持つ通信ノードである。通信ノードＮは、典型的には、計算機であるが、これに限らず、複数のインターネットサービスプロバイダをそれぞれ介してインターネットに接続することが可能なものであれば、携帯電話端末や情報家電等、どのような形態のものでもよい。
【００３２】
Ｉは、インターネットである。
【００３３】
Ｓは、インターネットに接続されたサーバであり、本実施形態では、通信ノードＮの通信相手の一例として示している。もちろん、通信ノードＮの通信相手は、サーバ以外の種類の通信ノードであっても構わない。
【００３４】
Ｒ１，Ｒ２は、いずれも、ルータであり、通信ノードＮからみたインターネットへの出口ルータである。
【００３５】
ＩＳＰａとＩＳＰｂは、いずれも、インターネットへ接続され、通信ノードに対してインターネットへの接続サービスを提供するインターネットサービスプロバイダ（のネットワーク）であり、通信ノードＮからみると、ルータＲ１側に接続されている。
【００３６】
ＩＳＰｃとＩＳＰｄは、いずれも、インターネットへ接続され、通信ノードに対してインターネットへの接続サービスを提供するインターネットサービスプロバイダ（のネットワーク）であり、通信ノードＮからみると、ルータＲ２側に接続されている。
【００３７】
本例では、各インターネットサービスプロバイダＩＳＰａ〜ＩＳＰｄは、通信ノードＮへ、インターネット上のサーバＳとの通信を可能とするサービスを提供している（以下、インターネットサービスプロバイダを、適宜、プロバイダあるいはＩＳＰと記述する）。
【００３８】
ここで、プロバイダＩＳＰａとルータＲ１との間は、専用線での常時接続のような接続形態であってもよいし、ダイヤルアップのような接続形態であってもよい。プロバイダＩＳＰｂとルータＲ１との間の接続形態、プロバイダＩＳＰｃとルータＲ２との間の接続形態、プロバイダＩＳＰｄとルータＲ２との間の接続形態のいずれについても、同様である。
【００３９】
なお、“Ｐａ”は、プロバイダＩＳＰａが提供するプレフィクス（ネットワークプレフィクス）を示すものとする。同様に、“Ｐｂ”，“Ｐｃ”，“Ｐｄ”は、それぞれ、プロバイダＩＳＰｂ，ＩＳＰｃ，ＩＳＰｄが提供するプレフィクスを示す。
【００４０】
また、通信ノードＮが各プロバイダＩＳＰａ，ＩＳＰｂ，ＩＳＰｃ，ＩＳＰｄからそれぞれプレフィクスをもらうとすると、通信ノードＮのインターフェースＩＤ（Ｉｎｔｅｒｆａｃｅ ＩＤ）（通信ノードＮに固有の識別子）をＮとすれば、通信ノードＮは、“Ｐａ：：Ｎ”，“Ｐｂ：：Ｎ”，“Ｐｃ：：Ｎ”，“Ｐｄ：：Ｎ”の４つのネットワークアドレス（この場合、グローバルアドレス）を持つことになる。ここでは、１２８ｂｉｔのＩＰｖ６アドレスのうち、「上位６４ｂｉｔ」は「プロバイダからもらうプレフィクス」からなり、「下位６４ｂｉｔ」は「インタフェースＩＤ」からなるものと仮定する。なお、ネットワークアドレスは、通常、各インタフェースに付与されることになる。
【００４１】
なお、図１の構成例では、通信ノードＮは、２台のルータのいずれかを介して４つのＩＳＰを利用可能としているが、もちろん、何台のルータであってもよいし、幾つのＩＳＰが利用可能でもよい。また、１台のルータを介して幾つのＩＳＰが利用可能でもよい。
【００４２】
また、図１の構成例では、通信ノードを１台のみ示しているが、通信ノードＮと同一のサブネットに他の通信ノードが存在しても構わない。
【００４３】
また、図１の構成例では、通信ノードＮの通信相手を１台のみ示しているが、もちろん、それ以外にも存在し得る。また、通信ノードＮの通信相手は、直接、インターネットに接続されていてもよいし、通信ノードＮとは異なるＩＳＰを介して接続されていてもよいし、通信ノードＮと同一のＩＳＰを介して接続されていてもよいし、ＩＳＰ以外のサブネットを介して接続されていてもよい。また、通信ノードＮの通信相手が、本発明を適用したマルチホームの利用者であってもよいし、そうでなくてもよい。
【００４４】
以下では、主にルータＲ１を例にとってその構成・動作について説明するが、ルータＲ１のみについて説明している部分は、ルータＲ２についても基本的には同様である。
【００４５】
図２に、本発明の一実施形態に係るルータ（Ｒ１，Ｒ２）の構成例を示す。
【００４６】
図２に示されるように、本実施形態のルータは、通信ノードＮ（に繋がる各回線）側またはＩＳＰ（に繋がる各回線）側からパケットを受信するための受信部３１、通信ノードＮ（に繋がる各回線）側またはＩＳＰ（に繋がる各回線）側へパケットを送信するための送信部３２、通常のルータの役割であるパケットを転送するために必要な処理とともに、詳しくは後述するように、ＩＳＰとの接続性に基づく通信ノードからのパケットのＩＳＰへの転送の可否の判断、パケットを転送しなかった際の通信ノードＮへの通知、通信ノードへの使用すべきプレフィクスの通知等の処理を行うためのパケット転送処理部３３、対象となるＩＳＰの状態を管理（接続性を確認）するためのＩＳＰ状態管理部３４、対象となるＩＳＰから提供されたプレフィクスを管理するためのプレフィクス管理部３５を備えている。なお、ＩＳＰの状態に関する情報（例えば、接続性が確認されているか否かを示す情報）や割当てられたプレフィクス等の必要な情報は、適当な記憶装置に格納される。また、図２では、通信ノードＮが接続されたサブネットに接続するための通信インタフェースや、各々のＩＳＰに繋がる回線に接続するための各々の通信インタフェースは、省略している。
【００４７】
なお、本ルータＲ１は、コンピュータを使用して実現可能であり、また、処理の全部又は一部をプログラムによって実施することが可能であるし、処理の全部又は一部を専用の半導体集積回路によって実施することも可能である。
【００４８】
図３に、本発明の一実施形態に係る通信ノードＮの構成例を示す。
【００４９】
図３に示されるように、本実施形態の通信ノードは、ルータＲ１，Ｒ２が接続されたサブネットからパケットを受信するための受信部１１、該サブネットへパケットを送信するための送信部１２、通信相手との間でパケットのやり取りを行うために必要な処理とともに、詳しくは後述するように、使用すべきＩＳＰの選択や、ルータ（Ｒ１，Ｒ２）からの通知に対する処理等の処理を行うためのパケット転送処理部１３、ルータ（Ｒ１，Ｒ２）から通知されたプレフィクスを管理するためのプレフィクス管理部１４、ルータ（Ｒ１，Ｒ２）から通知されたプレフィクスと自通信ノードのインタフェースＩＤとに基づいてネットワークアドレスを生成するためのネットワークアドレス生成部１５を備えている。なお、それらプレフィクスやネットワークアドレス等の必要な情報は、適当な記憶装置に格納される。また、図３では、通信インタフェースは、省略している。
【００５０】
なお、本通信ノードは、処理の全部又は一部をプログラムによって実施することが可能であるし、処理の全部又は一部を専用の半導体集積回路によって実施することも可能である。
【００５１】
以下、本実施形態の動作について説明する。
【００５２】
まず、初期の段階について説明する。
【００５３】
ルータＲ１は、ＩＳＰａ，ＩＳＰｂとの接続性を確認し、接続性が確認できたＩＳＰが提供するプレフィクスを受信し、受信したプレフィクスを格納して管理するとともに、その全部又は一部を通信ノードＮに通知する（あるいは、サブネット内に広告する）。
【００５４】
同様に、ルータＲ２は、ＩＳＰｃ，ＩＳＰｄとの接続性を確認し、接続性が確認できたＩＳＰが提供するプレフィクスを受信し、受信したプレフィクスを格納して管理するとともに、その全部又は一部を通信ノードＮに通知する（あるいは、サブネット内に広告する）。
【００５５】
一方、通信ノードＮは、ルータＲ１やルータＲ２からプレフィクスを受信し、受信したプレフィクスを格納するとともに、プレフィクスと自通信ノードのインタフェースＩＤとに基づいてネットワークアドレスを生成して、該当するインタフェースへ付与する。例えば、先に例示したように、“Ｐａ：：Ｎ”，“Ｐｂ：：Ｎ”，“Ｐｃ：：Ｎ”，“Ｐｄ：：Ｎ”の４つのネットワークアドレスが生成され、（インタフェースに）付与される。
【００５６】
通信ノードＮは、１つ以上のネットワークアドレスが生成された後に、（当該ＩＳＰに接続性があれば）サーバＳと通信可能になる。
【００５７】
また、通信ノードＮは、２つ以上のネットワークアドレスが生成され同一のインタフェースに付与された後には、該インタフェースについて、ソースアドレスとして使用すべきネットワークアドレスを適宜選択すればよい。なお、選択の方法は、例えば、ランダムに選択する方法、何らかの順番で選択するという基準、プレフィクスがライフタイムを持つ場合には、最も遅く期限が切れるライフタイムを持つものを選択する、など、種々のバリエーションがある。また、通信を行う通信主体（例えば、アプリケーションソフトウェア等）によっては、使用すべきＩＳＰの属性（例えば、転送速度、サービス内容、料金等）に応じて優先順位が指定される場合もある。また、通信主体によっては、使用すべきＩＳＰの属性が指定される場合もある。
【００５８】
次に、ルータによる各ＩＳＰとの接続性の定期的な確認について説明する。
【００５９】
なお、ルータＲ１は、ＩＳＰａ，ＩＳＰｂとの接続性を定期的に確認し、接続性に変化があれば、プレフィクスの管理内容を更新する。例えば、それまで接続性が確認されていたＩＳＰの接続性が確認できなかった場合には、接続性の確認されたＩＳＰから割当てを受けたプレフィクスを保持した管理情報において、その接続性が確認できないものに転じたＩＳＰから割当てを受けていたプレフィクスを使用不可に更新し、あるいは該管理情報から、そのプレフィクスを削除する。また、例えば、それまで接続性が確認されていなかったＩＳＰの接続性が確認できた場合には、接続性の確認されたＩＳＰから割当てを受けたプレフィクスを保持した管理情報において、その接続性が確認でるものに転じたＩＳＰから割当てを受けたプレフィクスを使用可能に更新し、あるいはそのＩＳＰからプレフィクスを受信して該管理情報に追加する。接続性に変化があった場合に、通信ノードＮに通知（あるいは、サブネット内に広告）してもよいが、それ以降に通信ノードＮからパケットを受信した際に必要に応じて（例えば、受信パケットのソースアドレスのプレフィクスに基づいて判断して必要があれば）通信ノードＮに通知するようにしてもよい。
【００６０】
ルータＲ１が各ＩＳＰの接続性を定期的に確認する方法は、特に限定されないが、例えば、所定の間隔で、確認したいＩＳＰを介して近接探索パケットを所望の通信ノード宛に送信するようにしてもよい。また、例えば、ＩＳＰ側から定期的に、接続が正常である通知を受け取るようにしてもよいし、接続されたＩＳＰよりもさらに上流の通信路の状態を受け取るようにしてもよい。
【００６１】
次に、図４に、ルータＲ１が通信ノードＮからパケットを受信した場合の処理手順の一例を示す。
【００６２】
ルータＲ１は、通信ノードＮからのパケットを受け取ると（ステップＳ１）、そのパケットのヘッダ部にあるソースアドレス（ｓｒｃ ａｄｄｒ）が所定の条件を満たすかどうか確認する（ステップＳ２）。
【００６３】
ここで、所定の条件とは、受信パケットのソースアドレスのプレフィクスが、接続性を確認できているＩＳＰから提供されたプレフィクスであること、である。すなわち、例えば、ＩＳＰａとＩＳＰｂの接続性が確認されている場合には、ルータＲ１は、そのソースアドレスが、現在、自ルータが接続しているＩＳＰａから割当てを受けているプレフィクスとＩＳＰｂから割当てを受けているプレフィクスのいずれかに該当するプレフィクスが付いているアドレスであるか否か確認する。また、例えば、ＩＳＰａのみの接続性が確認されている場合には、ルータＲ１は、そのソースアドレスが、現在、自ルータが接続しているＩＳＰａから割当てを受けているプレフィクスのいずれかに該当するプレフィクスが付いているアドレスであるか否か確認する。
【００６４】
通信ノードＮからの受信パケットのソースアドレスが、現在、自ルータが接続しているＩＳＰから割当てを受けているプレフィクスのいずれかに該当するプレフィクスが付いているアドレスであった場合（ステップＳ３）、ルータＲ１は、該受信パケットを該当するＩＳＰに向けて転送する（ステップＳ４）。
【００６５】
一方、そのソースアドレスが、現在、自ルータが接続しているＩＳＰから割当てを受けているプレフィクスのいずれかにも該当しないプレフィクスが付いているアドレスであった場合（ステップＳ３）、そのパケットを送信してきた通信ノードＮに対し、例えばＩＣＭＰ（Ｉｎｔｅｒｎｅｔ Ｃｏｎｔｒｏｌ Ｍｅｓｓａｇｅ Ｐｒｏｔｏｃｏｌ）を用いて、パケットの転送を行わなかった旨（すなわち、そのソースアドレスが持つプレフィクスは使用できない旨）を示す情報（ｐｒｅｆｉｘ−ｉｎｃｏｒｒｅｃｔ）を送信する（ステップＳ５）。
【００６６】
次に、図５に、通信ノードＮがサーバＳを宛先とするパケットを送信し、これがルータＲ１へ転送され、ルータＲ１が該パケットを転送しなかった場合の処理手順の一例を示す。
【００６７】
まず、通信ノードＮが、サーバＳを宛先とするパケットを送信する（ステップＳ１１）。
【００６８】
その際、ソースアドレスとして選択したアドレスのプレフィクスが、ルータＲ１により現在接続性が確認されていない状態になったＩＳＰに係るものであったとする。この場合、前述のように、ルータＲ１は、通信ノードＮに対し、パケットの転送を行わなかった旨を含む通知メッセージを送信することになる。
【００６９】
しかして、通信ノードＮは、ルータＲ１から、パケットの転送を行わなかった旨の通知を受信した場合（ステップＳ１２）、その通知を受けた当該パケットについて送信時に使用したソースアドレスのプレフィクスとは異なるプレフィクスによるネットワークアドレスが、サーバＳを宛先とするパケットのソースアドレスとして使用可能かどうか調べる（ステップＳ１３）。
【００７０】
使用可能であれば（ステップＳ１４）、その使用可能なネットワークアドレスをソースアドレスとしてヘッダに付与して、サーバＳを宛先とするパケットを、再度、送信する（ステップＳ１５）。
【００７１】
一方、使用不可（異なるプレフィクスによるネットワークアドレスがない場合の他に、それがあっても何らかに理由によって当該通信には使用できない場合がある）であれば（ステップＳ１４）、エラー処理を行う（ステップＳ１６）。エラー処理としては、何もしない、上位レイヤに通信に失敗した旨（当該ソースアドレスが持つプレフィクスは使用できない旨）を通知する、一定時間待ってステップＳ１３に戻る、など、種々のバリエーションが考えられる。
【００７２】
なお、ステップＳ１３で、上記の代わりに、その通知を受けた当該パケットについて送信時に使用したソースアドレスのプレフィクスに係るＩＳＰとは異なるＩＳＰに係るプレフィクスによるネットワークアドレスが、サーバＳを宛先とするパケットのソースアドレスとして使用可能かどうか調べるようにしてもよい。
【００７３】
また、ステップＳ１２で、ルータＲ１から、パケットの転送を行わなかった旨の通知を受信した場合には、直ちに、エラー処理（例えば、何もしない、上位レイヤに通信に失敗した旨（当該ソースアドレスが持つプレフィクスは使用できない旨）を通知する、通信に失敗した旨及びその際に使用したプレフィクスを通知する、など）に移行してしまう方法もある（後は、例えば、上位レイヤによる処理あるいはユーザによる対処がなされる）。
【００７４】
次に、図６に、ルータＲ１が通信ノードＮからパケットを受信した場合の処理手順の他の例を示す。
【００７５】
図４の手順例では、受信パケットのソースアドレスが所定の条件を満たさないために該パケットを転送しなかった場合には、ルータＲ１は、通信ノードＮに対し、パケットの転送を行わなかった旨を通知したが、この手順例では、その際に、この通知（例えば、ＩＣＭＰメッセージ）に、現在接続性が確認されているＩＳＰから提供されたプレフィクスをも含めて、通信ノードＮへ通知するようにするものである（ステップＳ２３，Ｓ２５）。
【００７６】
例えば、ＩＳＰａが何らかの理由で接続が絶たれており、ＩＳＰｂのみの接続が確認されている場合に、通信ノードＮからＩＳＰｂに係るプレフィクス以外のプレフィクス（例えば、ＩＳＰａに係るプレフィクス）によるソースアドレスを持つパケットを受信したならば、ＩＳＰｂから提供されたプレフィクスＰｂのみを通信ノードＮに通知する。
【００７７】
また、例えば、ＩＳＰａ及びＩＳＰｂの両方の接続性が確認されてる場合に、通信ノードＮからＩＳＰａ及びＩＳＰｂに係るプレフィクス以外のプレフィクスによるソースアドレスを持つパケットを受信したならば、ＩＳＰａから提供されたプレフィクスＰａ及びＩＳＰｂから提供されたプレフィクスＰｂを通信ノードＮに通知する。
【００７８】
図７に、この場合のＩＣＭＰ（ｐｒｅｆｉｘ−ｉｎｃｏｒｒｅｃｔ）メッセージの構成例を示す。
【００７９】
図７において、
「ＩＰｖ６ヘッダ」（図中、２１）は、ＩＰｖ６パケットであること示すヘッダ、
「ＩＣＭＰヘッダ」（図中、２２）は、ＩＣＭＰメッセージであることを示すヘッダ、
「ｔａｒｇｅｔ ｄｓｔ ｐｒｅｆｉｘｌｅｎ（対象宛先プレフィクス長）」（図中、２３）は、このＩＣＭＰメッセージに含まれるｐｒｅｆｅｒｒｅｄ−ｐｒｅｆｉｘ（推奨プレフィクス）が有効な宛先（ｄｅｓｔｉｎａｔｉｏｎ）となるアドレスレンジを示すためのフィールド、
「ｎｕｍｂｅｒ ｏｆ ｐｒｅｆｅｒｒｅｄ−ｐｒｅｆｉｘ（推奨プレフィクス数）」（図中、２４）は、このＩＣＭＰメッセージに含まれるｐｒｅｆｅｒｒｅｄ−ｐｒｅｆｉｘの数を示すためのフィールド、
「ｐｒｅｆｅｒｒｅｄ−ｐｒｅｆｉｘ（推奨プレフィクス）」（図中、２５〜２７）は、それぞれ、使用を推奨するプレフィクスを示すためのフィールド、
「原因パケット」（図中、２８）は、このＩＣＭＰメッセージがルータＲ１から発せられる原因となったパケットである。
【００８０】
ここで、「ｔａｒｇｅｔ ｄｓｔ ｐｒｅｆｉｘｌｅｎ」は、例えば１２８なら“／１２８”という意味であり、上位１２８ビットで有効なアドレスレンジを指定している。通常、原因となったパケットの宛先そのものにしか有効でないが、例えば、この値が６４なら、上位６４ｂｉｔのプレフィクスが一致する場合に限り、このｐｒｅｆｅｒｒｅｄ−ｐｒｅｆｉｘを使用することで、有効なＩＳＰを介してパケットを送信することができる。ルータＲ１は、何らかの方法でこの値を得られる場合には、得られた適切な値を入れる。そうでなければ、−１を入れる（１２８が入るのは、明らかなホストルータ（ｈｏｓｔ ｒｏｕｔｅ）を持っている場合である）。
【００８１】
次に、図８に、通信ノードＮの処理手順の他の例（図６の手順例に対応する例）を示す。
【００８２】
まず、通信ノードＮが、サーバＳを宛先とするパケットを送信する（ステップＳ３１）。
【００８３】
その際、ソースアドレスとして選択したアドレスのプレフィクスが、ルータＲ１により現在接続性が確認されていない状態になったＩＳＰに係るものであったとすると、ルータＲ１は、通信ノードＮに対し、パケットの転送を行わなかった旨及び現在接続性が確認されているＩＳＰから提供されたプレフィクスを含む通知を含む通知メッセージを送信することになる。
【００８４】
しかして、通信ノードＮは、ルータＲ１から、パケットの転送を行わなかった旨及び現在接続性が確認されているＩＳＰから提供されたプレフィクスを含む通知を受信する（ステップＳ３２）。
【００８５】
この場合、通信ノードＮは、必要に応じて、その通知を受けたプレフィクスとプレフィクスと自通信ノードのインタフェースＩＤとに基づいてネットワークアドレスを生成し（ステップＳ３３）、その通知を受けたパケットについて、ソースアドレスを、この生成されたアドレスに変更して（生成されたアドレスを、ソースアドレスとしてヘッダに付与して）、再度、送信する（ステップＳ３４）。
【００８６】
なお、該当するアドレスが既に生成されて、インタフェースに付与されている場合には、ステップＳ３３はスキップしても構わない。
【００８７】
また、複数のプレフィクスが通知された場合には、複数のネットワークアドレスが生成可能であるが、この場合に、ソースアドレスとして使用すべきネットワークアドレスを先に例示した選択方法などで適宜選択すればよい。
【００８８】
また、アプリケーションソフトウェア等の通信主体によっては、通知されたプレフィクスによるネットワークアドレスがソースアドレスとして使用できない場合もあり得る。
【００８９】
ところで、ルータＲ１において、どのようなパケット転送制御を行うか、あるいはどのようにｐｒｅｆｅｒｒｅｄ−ｐｒｅｆｉｘ（推奨プレフィクス）の通知の仕方をするかについては、種々のバリエーションが考えられる。
【００９０】
例えば、ルータＲ１は、ＩＳＰａ側の回線の帯域が広いことを予め知っており、デフォルトでＩＳＰａ側を使用する設定であったとしても、通信ノードＮ側から受信したパケットのソースアドレスにＩＳＰｂ側のプレフィクスＰｂが使われている場合には、この指示を優先しＩＳＰｂ側にそのパケットを転送するように制御してもよい。
【００９１】
また、例えば、ＩＳＰａ側の回線の帯域がＩＳＰｂよりも大幅に広い場合で通信ノードＮから受信したパケットがＩＳＰｂ側のプレフィクスを使用したソースアドレスであった場合には、（たとえＩＳＰｂの接続性が確認されていても）ＩＣＭＰ（ｐｒｅｆｉｘ−ｉｎｃｏｒｒｅｃｔ）等のメッセージを通信ノードＮに通知すると同時にＩＳＰａのプレフィクスを使用するように通知するようにしてもよい。これにより、通信ノードＮは、最初に送信したパケットではＩＳＰｂを使用していたが、ルータＲ１よりＩＳＰａ側のプレフィクスの通知を受けることにより、より帯域の広いＩＳＰａを介した通信が可能となる。
【００９２】
また、例えば、ルータＲ１は、自通信ノードが接続されるＩＳＰａ，ＩＳＰｂに係るプレフィクスを通信ノードＮに通知する代わりに、ルータＲ２へのリダイレクトを応答する制御も考えられる。
【００９３】
さて、以下では、図９及び図１０のシーケンス例を参照しながら、ルータＲ１の動作例について説明する。
【００９４】
まず、図１の構成例において、ルータＲ１が通信ノードＮからパケットを受信した際にＩＳＰａの接続性が確認されている場合を考える。
【００９５】
この場合に、通信ノードＮが、図９（ａ）のように、ソースアドレス＝“Ｐａ：：Ｎ”、宛先アドレス＝“Ｓ”とするパケット（ｓｒｃ＝Ｐａ：：Ｎ ， ｄｓｔ＝Ｓ）をルータＲ１に向けて送信したとする（Ｓ１０１）。ここで、ＩＳＰａがルータＲ１において優先すべきＩＳＰであると予め定められていたとすると、この場合には、ルータＲ１は、通信ノードＮから受信したパケットをＩＳＰａに転送する（Ｓ１０２）。
【００９６】
次に、ルータＲ１が通信ノードＮからパケットを受信した際にＩＳＰａの接続性が絶たれていた場合を考える。
【００９７】
この場合に、通信ノードＮが、図９（ｂ）のように、ソースアドレス＝“Ｐａ：：Ｎ”、宛先アドレス＝“Ｓ”とするパケット（ｓｒｃ＝Ｐａ：：Ｎ ， ｄｓｔ＝Ｓ）をルータＲ１に向けて送信したとする（Ｓ１２１）。
【００９８】
ここで、受信したパケットを接続性が保たれている他のＩＳＰｂに転送してもｉｎｇｒｅｓｓ ｆｉｌｔｅｒが導入されていることが多く、ＩＳＰｂにてこのパケットの転送を拒絶されることが予めわかっているので、ルータＲ１は、通信ノードＮに対し、ＩＣＭＰメッセージ（図７参照）を送信するものとする（Ｓ１２２）。このＩＣＭＰメッセージは、ｐｒｅｆｉｘ−ｉｎｃｏｒｒｅｃｔと、推奨するｐｒｅｆｆｅｒｅｄ Ｐｒｅｆｉｘ：Ｐｂを含む。
【００９９】
通信ノードＮは、この通知を受けて、ソースアドレス＝“Ｐｂ：：Ｎ”、宛先アドレス＝“Ｓ”とするパケット（ｓｒｃ＝Ｐｂ：：Ｎ ， ｄｓｔ＝Ｓ）をルータＲ１に向けて送信すると（Ｓ１２３）、この場合には、ルータＲ１は、通信ノードＮから受信したパケットをＩＳＰｂに転送する（Ｓ１２４）。
【０１００】
次に、通信ノードＮが、図９（ｃ）のように、ソースアドレス＝“Ｐａ：：Ｎ”、宛先アドレス＝“Ｓ”とするパケット（ｓｒｃ＝Ｐａ：：Ｎ ， ｄｓｔ＝Ｓ）をルータＲ２に向けて送信した場合を考える（Ｓ１３１）。
【０１０１】
この場合には、ルータＲ２は、基本的には、上記のルータＲ１と同じ動作をすることになる。
【０１０２】
すなわち、通信ノードＮから、上記のパケットを受信したルータＲ２は、受信したパケットのソースアドレスに付与されたプレフィクスＰａが自ルータＲ２と接続しているＩＳＰから通知されたプレフィクスかどうかを確認する。
【０１０３】
このプレフィクスＰａは、自ルータＲ２と接続しているＩＳＰから通知されたプレフィクスではないので、通信ノードＮに向けてＩＣＭＰメッセージを送信する（Ｓ１３２）。このＩＣＭＰメッセージは、ｐｒｅｆｉｘ−ｉｎｃｏｒｒｅｃｔと、ルータＲ２が推奨するｐｒｅｆｆｅｒｄ Ｐｒｅｆｉｘ：Ｐｃ，Ｐｄ（ただし、ＩＳＰｃとＩＳＰｄの接続性がいずれも確認できている場合）を含む。ここで、ＩＳＰｃ，ＩＳＰｄの接続性は予め確認しておくものとする。
【０１０４】
通信ノードＮは、この通知を受けて、例えば、Ｐｃを選択して、ソースアドレス＝“Ｐｃ：：Ｎ”、宛先アドレス＝“Ｓ”とするパケット（ｓｒｃ＝Ｐｃ：：Ｎ ， ｄｓｔ＝Ｓ）をルータＲ２に向けて送信し（Ｓ１３３）、ルータＲ２は、通信ノードＮから受信したパケットをＩＳＰｃに転送する（Ｓ１３４）。
【０１０５】
次に、ＩＳＰａ，ＩＳＰｂの両方の接続が絶たれている場合を想定する。この場合、ルータＲ１は、インターネットへの接続性を果たさない。
【０１０６】
ここで、通信ノードＮが、図１０のように、ソースアドレス＝“Ｐａ：：Ｎ”、宛先アドレス＝“Ｓ”とするパケット（ｓｒｃ＝Ｐａ：：Ｎ ， ｄｓｔ＝Ｓ）をルータＲ１に向けて送信したとする（Ｓ１４１）。
【０１０７】
この場合、ルータＲ１は、ＩＳＰａ，ＩＳＰｂの接続が絶たれているため、通信ノードＮに対し、ＩＣＭＰメッセージとしてｒｅｄｉｒｅｃｔ（リダイレクト）を送信し、これにより、通信ノードＮに対し、パケットの送信先としてルータＲ２を選択させるよう指示を行うようにしてもよい（Ｓ１４２）。
【０１０８】
なお、ルータＲ１は、（例えば、ルータ間の情報交換等により）リダイレクトの対象となる他のルータとしてルータＲ２が存在することを知っている（あるいは知ることができる）ものとする。
【０１０９】
通信ノードＮは、このＩＣＭＰメッセージに基づいて、まず、ソースアドレス＝“Ｐａ：：Ｎ”、宛先アドレス＝“Ｓ”とするパケット（ｓｒｃ＝Ｐａ：：Ｎ
， ｄｓｔ＝Ｓ）をルータＲ２に向けて送信する（Ｓ１４３）。
【０１１０】
ここで、ルータＲ２は、自ルータＲ２が接続されていないＩＳＰのプレフィクスであることから、ｐｒｅｆｉｘ−ｉｎｃｏｒｒｅｃｔと、ルータＲ２が推奨するｐｒｅｆｆｅｒｄ Ｐｒｅｆｉｘ：Ｐｃ，Ｐｄ（ただし、ＩＳＰｃとＩＳＰｄの接続性がいずれも確認できている場合）を含むＩＣＭＰメッセージを送信する（Ｓ１４４）。
【０１１１】
通信ノードＮは、この通知を受けて、例えば、Ｐｃを選択して、ソースアドレス＝“Ｐｃ：：Ｎ”、宛先アドレス＝“Ｓ”とするパケット（ｓｒｃ＝Ｐｃ：：Ｎ ， ｄｓｔ＝Ｓ）をルータＲ２に向けて送信し（Ｓ１４５）、ルータＲ２は、通信ノードＮから受信したパケットをＩＳＰｃに転送する（Ｓ１４６）。
【０１１２】
なお、ＩＳＰａ，ＩＳＰｂの両方の接続が絶たれている場合において、ルータＲ１は、リダイレクトの対象となるルータが複数存在するならば、通信ノードＮに対して、それらから適宜選択した１つのルータを返すようにしてもよい。
【０１１３】
また、ＩＳＰａ，ＩＳＰｂの両方の接続が絶たれている場合において、ルータＲ１は、リダイレクトの対象となるルータがもともと存在しないか、またはリダイレクトの対象となるルータがすべてダウンしているとを知っているならば、通信ノードＮに対して、エラーを返すようにすると好ましい。
【０１１４】
次に、以下では、図９及び図１０のシーケンス例を参照しながら、通信ノードＮの動作例について説明する。
【０１１５】
まず、前述のように通信ノードＮがＩＣＭＰメッセージを受信する場合について説明する。
【０１１６】
通信ノードＮは、ソースアドレス＝“Ｐａ：：Ｎ”、宛先アドレス＝“Ｓ”とするパケット（ｓｒｃ＝Ｐａ：：Ｎ ， ｄｓｔ＝Ｓ）をルータＲ１に向けて送信する（図９（ｂ）のＳ１２１参照）。
【０１１７】
ここで、ソースアドレスとして用いられるプレフィクスは、例えば、デフォルトルータであるルータＲ１から予め通知を受けているものとする。
【０１１８】
次に、前述したようにこの受信したパケットが指定しているＩＳＰａの接続が絶たれていた場合を想定する。この場合は、ルータＲ１から図７に示すＩＣＭＰメッセージが届く。このＩＣＭＰメッセージは、ｐｒｅｆｉｘ−ｉｎｃｏｒｒｅｃｔと、推奨するｐｒｅｆｆｅｒｅｄ Ｐｒｅｆｉｘ：Ｐｂを含む（図９（ｂ）のＳ１２２参照）。
【０１１９】
通信ノードＮは、このＩＣＭＰメッセージを受信すると、このメッセージがどのパケットの送信に対するメッセージであるのかを、図７の原因となるパケット（２８）から判断する。
【０１２０】
次に、このメッセージに含まれるｐｒｅｆｆｅｒｅｄ ｐｒｅｆｉｘ（ここでは、Ｐｂ）から原因となった先のパケットのソースアドレスを書き換えて再度送信する。
【０１２１】
その際、ｐｒｅｆｆｅｒｄ ｐｒｅｆｉｘとして受信したプレフィクス（Ｐｂ）と通信ノードＮが持つインターフェースＩＤとの組合せにより作成したネットワークアドレス“Ｐｂ：：Ｎ”が予め用意されていなければ、これを作成して使用する。
【０１２２】
また、ここで、原因となるパケットを調べ、それに対応しているコネクションが現在あるかどうかどうかを調べてからパケットを再送信するよう制御してもよい。
【０１２３】
原因となるパケットに関連するコネクションがある場合、それが確立前、すなわち発呼中であるかを調べる。例えば、ＴＣＰ上でＳＹＮ＿ＳＥＮＴの状態かどうかを調べることにより実現できる。
【０１２４】
発呼中である場合、そのコネクションのソースアドレスを先のＩＣＭＰメッセージで受信したプレフィックスを付与したソースアドレスにより再度コネクションの設定を行う。ただし、アプリケーションがソースアドレスを明示的に指定している場合には、再設定を行わないように制御してもよい。一例として、一般的なソケットを使っている場合には、ｃｏｎｎｅｃｔ（）を呼ぶ前にｂｉｎｄ（）を呼び、そこでソースアドレスを明示的に指定してきた場合などである。
【０１２５】
さらに、ルータＲ１またはＲ２から受信したＩＣＭＰメッセージを、図１１に例示するようなプレフィクス管理テーブルとして保持するようにしてもよい。ここでは、ＩＣＭＰメッセージを受信したら、その結果を、宛先のアドレスまたはアドレスレンジと、ｐｒｅｆｅｒｒｅｄ−ｐｒｅｆｉｘとの組で、記憶する。
【０１２６】
一例として、“Ｓ：：ａ”にパケットを送信して、これに対しルータＲ１からｐｒｅｆｉｃ−ｉｎｃｏｒｒｅｃｔのＩＣＭＰメッセージを受信した場合について説明する。
【０１２７】
このＩＣＭＰメッセージの中には、ｐｒｅｆｅｒｒｅｄ−ｐｒｅｆｉｘ（推奨プレフィクス）として“Ｐａ”が記載されている。この結果を、アドレスまたはアドレスレンジと、プレフィクスとの組で記憶しておくことにより、次回、“Ｓ：：ａ”宛にパケットを送信する際に、このテーブルを参照し、ソースアドレスを推奨プレフィクスである“Ｐａ：：ａ”と変更してパケットを送信する。
【０１２８】
また、“Ｓ：：／６４”というプレフィクスを持つアドレスの場合、このテーブルを参照し、Ｐａを優先的に使用するように制御してもよい。これにより、予め推奨のプレフィクスを優先的に使用することができるため、ルータからＩＣＭＰメッセージを受信する回数を少なくすることができる。さらに、このテーブルの記憶は、デフォルトルータが変更になったり、通信ノードＮにおけるパケット送信先のルールが変更になった場合は、破棄するようにしてもよい。
【０１２９】
次に、通信ノードＮが、ソースアドレス＝“Ｐａ：：Ｎ”、宛先アドレス＝“Ｓ”とするパケット（ｓｒｃ＝Ｐａ：：Ｎ ， ｄｓｔ＝Ｓ）をルータＲ２に向けて送信した場合について説明する（図１０のＳ１３１参照）。このパケットは、例えば、ＴＣＰコネクション設定のためのパケットである場合を想定する。
【０１３０】
このパケットを受信したルータＲ２は、このパケットのソースアドレスに含まれるＰａのプレフィクスを検出することにより、このＰａのプレフィクスはルータＲ２の上流のＩＳＰからは割り当てられていないことがわかる。
【０１３１】
これにより、ルータＲ２は、このパケットを送信した通信ノードＮに対して、ＩＣＭＰメッセージ（ｐｒｅｆｉｘ−ｉｎｃｏｒｒｅｃｔ）を送信する（図１０のＳ１３２参照）。このＩＣＭＰメッセージには、ルータＲ２が推奨するプレフィクスであるｐｒｅｆｅｒｒｅｄ−ｐｒｅｆｉｘ：Ｐｃ，Ｐｄが含まれている。
【０１３２】
通信ノードＮは、このＩＣＭＰメッセージを受信すると、まず、自通信ノードＮ（通信ノードＮのインターフェースであるインターフェースＮ）に設定されているアドレスと受信したｐｒｅｆｅｒｒｅｄ−ｐｒｅｆｉｘとを比較する。通信ノードＮは、ＰｃとＰｄのプレフィクスをもつアドレスも保持しているため、いずれかを選択してソースアドレスとする。ここでは、Ｐｃを選択し、ソースアドレスを“Ｐｃ：：Ｎ”とする。
【０１３３】
次に、ＩＣＭＰメッセージの中の原因となったパケットを調べる。この際、原因となったパケットのソースアドレス（ｓｒｃ ａｄｄｒ）、宛先アドレス（ｄｓｔ ａｄｄｒ）、ソースポート（ｓｒｃ ｐｏｒｔ）、宛先ポート（ｄｓｔ ｐｏｒｔ）の４つの組を調べることにより、どの接続先へのどのような要求かがわかる。次に、前述したようにこの要求が確立前、すなわち発呼中であるかを調べる。その後、確立前であった場合には、ソースアドレスを“Ｐｃ：：Ｎ”に変更してパケットを再度送信する。
【０１３４】
以下では、通信ノードＮにおける、ルータからＩＣＭＰメッセージ等で通知されたプレフィクスの管理方法について説明する。
【０１３５】
ルータからＩＣＭＰメッセージ等で通知されたプレフィクスを、いつまで使用するか、あるいはいつ破棄するかについては、種々のバリエーションがある。
【０１３６】
なお、プレフィクス管理テーブルを、キャッシュとすれば、基本的には、いつ破棄しても通信に支障はない。
【０１３７】
以下、幾つかのバリエーションを示す。
【０１３８】
（１）通知されたプレフィクスは、そのときのパケットの再送にのみ使用して、破棄する。
メモリの量が少ない通信ノードが通信する場合には、このようにすると、好ましい。同じ通信相手に対して、再度、新しいコネクションを張ろうとする場合には、同じ手順が繰り返される。
【０１３９】
（２）通知されたプレフィクスは、予め定められたイベントが起きるまで、保持し、予め定められたイベントが起きたら、その全部又は一部を破棄する、という処理を、定常的に行う。
例えば、テーブルの大きさを決めて、データが溢れたならば、その時点で、（例えば、最後に参照したエントリを）順次捨てる。
【０１４０】
（３）基本的には、定常的な処理としては、破棄は行わず、破棄すべき状況になった際に、通知されたプレフィクスの全部又は一部を破棄する。
破棄すべき状況とは、例えば、
（３−１）Ｒｅｄｉｒｅｃｔを受けた
（３−２）使っていたルータが（今さっき）ダウンした
などである。
【０１４１】
上記の（３−１）のＲｅｄｉｒｅｃｔを受けた場合について説明する。
例えば、ノードＮが、ルータＲ１とルータＲ２を介してインターネットに接続可能な状況で、過去にルータＲ２から、Ｐｒｅｆｉｘ−ｉｎｃｏｒｒｅｃｔを受けて、ｐｒｅｆｉｘ：ｐｄを通知されたとする。すると、通信ノードＮは、Ｒ２から「Ｓについてはプレフィクスｐｄを推奨する」という通知を受けたことを記憶する。しばらく、ｐｄによって通信可能であったが、ある時点で、ルータＲ２から「Ｓについては、ルータＲ１を推奨する」と通知された（ＩＣＭＰ ｒｅｄｉｒｅｃｔ）とする。このような場合に、ｐｄは、ルータＲ２に依存したプレフィクスなので、少なくともこれは破棄する。また、いままで使ってた経路で突然ｒｅｄｉｒｅｃｔを受けるのは、ルータＲ１，Ｒ２を取り巻く状況が大きく変化した可能性が高いので（例えば、ルータＲ２の先のｌｉｎｋが全部落ちたなど）、プレフィクスを全て破棄するようにしてもよい。
【０１４２】
上記の（３−２）の使っていたルータが（今さっき）ダウンした場合について説明する。
「ＳについてはルータＲ２に転送する」という情報を保持している場合に、ルータＲ２がダウンしたことがわかったならば（例えば、ＩＰｖ６ノードは、定期的に自分が使ってるルータに対して、生存確認を行うので（ＮＵＤ，ＲＦＣ２４６１）、これによって知ることができる）、かなり状況が変わっているので、保持しているプレフィクスは、無意味であり、それらを全て廃棄するようにしてもよい。
【０１４３】
この（３）の処理は、（１）のケースでない限り、実施するのが望ましい（無駄な手順の増加を回避できる）。
【０１４４】
（４）ライフタイム（ｌｉｆｅｔｉｍｅ）を使う
通信ノードＮは、プレフィクスをテーブル等に登録する際に、そのライフタイム（例えば、ｎ秒）を、（例えば通信ノードＮが独自に）決定して、該プレフィクスに対応付けて登録するようにしてもよい。この場合には、その時間が経過した際に、破棄する。
【０１４５】
なお、以上の各機能は、ソフトウェアとして実現可能である。
また、本実施形態は、コンピュータに所定の手段を実行させるための（あるいはコンピュータを所定の手段として機能させるための、あるいはコンピュータに所定の機能を実現させるための）プログラムとして実施することもでき、該プログラムを記録したコンピュータ読取り可能な記録媒体として実施することもできる。
【０１４６】
なお、この発明の実施の形態で例示した構成は一例であって、それ以外の構成を排除する趣旨のものではなく、例示した構成の一部を他のもので置き換えたり、例示した構成の一部を省いたり、例示した構成に別の機能あるいは要素を付加したり、それらを組み合わせたりすることなどによって得られる別の構成も可能である。また、例示した構成と論理的に等価な別の構成、例示した構成と論理的に等価な部分を含む別の構成、例示した構成の要部と論理的に等価な別の構成なども可能である。また、例示した構成と同一もしくは類似の目的を達成する別の構成、例示した構成と同一もしくは類似の効果を奏する別の構成なども可能である。
また、この発明の実施の形態で例示した各種構成部分についての各種バリエーションは、適宜組み合わせて実施することが可能である。
また、この発明の実施の形態は、個別装置としての発明、関連を持つ２以上の装置についての発明、システム全体としての発明、個別装置内部の構成部分についての発明、またはそれらに対応する方法の発明等、種々の観点、段階、概念またはカテゴリに係る発明を包含・内在するものである。
従って、この発明の実施の形態に開示した内容からは、例示した構成に限定されることなく発明を抽出することができるものである。
【０１４７】
本発明は、上述した実施の形態に限定されるものではなく、その技術的範囲において種々変形して実施することができる。
【０１４８】
【発明の効果】
本発明によれば、マルチホーム環境を有効に利用することが可能になる。
【図面の簡単な説明】
【図１】本発明の一実施形態に係るネットワーク・システムの構成例を示す図
【図２】同実施形態に係るルータの構成例を示す図
【図３】同実施形態に係る通信ノードの構成例を示す図
【図４】同実施形態に係るルータの処理手順の一例を示すフローチャート
【図５】同実施形態に係る通信ノードの処理手順の一例を示すフローチャート
【図６】同実施形態に係るルータの処理手順の他の例を示すフローチャート
【図７】同実施形態に係るＩＣＭＰメッセージの構成例を示す図
【図８】同実施形態に係る通信ノードの処理手順の他の例を示すフローチャート
【図９】同実施形態に係るネットワーク・システムのシーケンス例を示す図
【図１０】同実施形態に係るネットワーク・システムのシーケンス例を示す図
【図１１】同実施形態に係るプレフィクス管理テーブルの構成例を示す図
【図１２】従来のマルチホーム環境のネットワーク・システムについて説明するための図
【符号の説明】
Ｎ…通信ノード
Ｒ１，Ｒ２…ルータ
Ｉ…インターネット
ＩＳＰａ，ＩＳＰｂ，ＩＳＰｃ，ＩＳＰｄ…インターネットサービスプロバイダ
Ｓ…サーバ
１１，３１…受信部
１２，３２…送信部
１３，３３…パケット転送処理部
１４，３５…プレフィクス管理部
１５…ネットワークアドレス生成部
３４…ＩＳＰ状態管理部
Claims (23)
- 複数のインターネットサービスプロバイダに接続されたルータ装置と、このルータに接続された通信ノードとを含むソースアドレス選択システムにおいて、
前記ルータ装置は、
前記インターネットサービスプロバイダとの接続性を確認する第１の確認手段と、
前記第１の確認手段により接続性が確認できた前記インターネットサービスプロバイダが提供するネットワークプレフィクスを受信する第１の受信手段と、
前記受信したネットワークプレフィクスを前記通信ノード宛に通知する通知手段とを具備し、
前記通信ノードは、
前記ルータから前記ネットワークプレフィクスを受信する第２の受信手段と、
前記ネットワークプレフィクスと自通信ノード固有の識別子に基づいてネットワークアドレスを生成する生成手段と、
パケットを送信する際に前記ネットワークアドレスをソースアドレスとしてヘッダに付与して送信する送信手段とを具備し、
前記ルータ装置は更に、
前記通信ノードから受信したパケットが、自ルータ装置が接続性を確認できているインターネットサービスプロバイダから受信したネットワークプレフィクスを持つソースアドレスか否かを確認する第２の確認手段と、
前記ソースアドレスが、自ルータ装置が接続性を確認できているインターネットサービスプロバイダから受信したネットワークプレフィクスを持っているソースアドレスであった場合は、該ネットワークプレフィクスを受信したインターネットサービスプロバイダ宛に該パケットを転送し、前記ソースアドレスが、自ルータ装置が接続性を確認できているインターネットサービスプロバイダから受信したネットワークプレフィクスを持っているソースアドレスではなかった場合は、該パケットの転送を行わず、前記通信ノード宛に該パケットの転送を行わなかったことを通知するとともに、前記第１の確認手段により接続性が確認できた前記インターネットサービスプロバイダが提供するネットワークプレフィクスを前記通信ノード宛に通知する制御手段とを具備したことを特徴とするソースアドレス選択システム。 - 前記通信ノードは、送信したパケットに対し前記ルータから転送を行わなかった通知を受けるとともに接続性が確認できた前記インターネットサービスプロバイダのネットワークプレフィクスの通知を受けた場合には、前記パケットのソースアドレスを、新たに前記通知を受けたネットワークプレフィクスと自通信ノード固有の識別子に基づいて生成されたネットワークアドレスに変更し、前記パケットを再度送信することを特徴とする請求項１に記載のソースアドレス選択システム。
- 前記通信ノードは、送信したパケットに対し前記ルータから転送を行わなかった通知を受けるとともに接続性が確認できた前記インターネットサービスプロバイダのネットワークプレフィクスの通知を受けた場合に、該ネットワークプレフィクスに基づく前記ネットワークアドレスを、当該パケットの再送信についてのみ使用することを特徴と請求項２に記載のソースアドレス選択システム。
- 前記通信ノードは、送信したパケットに対し前記ルータから転送を行わなかった通知を受けるとともに接続性が確認できた前記インターネットサービスプロバイダのネットワークプレフィクスの通知を受けた場合に、該ネットワークプレフィクスに基づく前記ネットワークアドレスを、それが無効になるまで使用することを特徴と請求項２に記載のソースアドレス選択システム。
- 複数のインターネットサービスプロバイダに接続されたルータ装置と、このルータに接続された通信ノードとを含むソースアドレス選択システムにおいて、
前記ルータ装置は、
前記インターネットサービスプロバイダとの接続性を確認する第１の確認手段と、
前記第１の確認手段により接続性が確認できた前記インターネットサービスプロバイダが提供するネットワークプレフィクスを受信する第１の受信手段と、
前記受信したネットワークプレフィクスを前記通信ノード宛に通知する通知手段とを具備し、
前記通信ノードは、
前記ルータから前記ネットワークプレフィクスを受信する第２の受信手段と、
前記ネットワークプレフィクスと自通信ノード固有の識別子に基づいてネットワークアドレスを生成する生成手段と、
パケットを送信する際に前記ネットワークアドレスをソースアドレスとしてヘッダに付与して送信する送信手段とを具備し、
前記ルータ装置は更に、
前記通信ノードから受信したパケットが、自ルータ装置が接続性を確認できているインターネットサービスプロバイダから受信したネットワークプレフィクスを持つソースアドレスか否かを確認する第２の確認手段と、
前記ソースアドレスが、自ルータ装置が接続性を確認できているインターネットサービスプロバイダから受信したネットワークプレフィクスを持っているソースアドレスであった場合は、該ネットワークプレフィクスを受信したインターネットサービスプロバイダ宛に該パケットを転送し、前記ソースアドレスが、自ルータ装置が接続性を確認できているインターネットサービスプロバイダから受信したネットワークプレフィクスを持っているソースアドレスではなかった場合は、該パケットの転送を行わず、前記通信ノード宛に該パケットの転送を行わなかったことを通知する制御手段とを具備し、
前記ルータ装置の前記制御手段は、前記ソースアドレスが、自ルータ装置が接続性を確認できているインターネットサービスプロバイダから受信したネットワークプレフィクスを持っているソースアドレスではなかった場合に、前記第１の確認手段により接続性が確認できている前記インターネットサービスプロバイダがその時点で存在しないならば、該パケットの転送を行わず、前記通信ノード宛に該パケットの転送を行わなかったことを通知するとともに、前記パケットの送信先とすべき他のルータ装置を前記通信ノード宛に通知する機能を更に具備することを特徴とするソースアドレス選択システム。 - 複数のインターネットサービスプロバイダに接続されたルータ装置と、このルータに接続された通信ノードとを含むソースアドレス選択システムにおいて、
前記ルータ装置は、
前記インターネットサービスプロバイダとの接続性を確認する第１の確認手段と、
前記第１の確認手段により接続性が確認できた前記インターネットサービスプロバイダが提供するネットワークプレフィクスを受信する第１の受信手段と、
前記受信したネットワークプレフィクスを前記通信ノード宛に通知する通知手段とを具備し、
前記通信ノードは、
前記ルータから前記ネットワークプレフィクスを受信する第２の受信手段と、
前記ネットワークプレフィクスと自通信ノード固有の識別子に基づいてネットワークアドレスを生成する生成手段と、
パケットを送信する際に前記ネットワークアドレスをソースアドレスとしてヘッダに付与して送信する送信手段とを具備し、
前記ルータ装置は更に、
前記通信ノードから受信したパケットが、自ルータ装置が接続性を確認できているインターネットサービスプロバイダから受信したネットワークプレフィクスを持つソースアド レスか否かを確認する第２の確認手段と、
前記ソースアドレスが、自ルータ装置が接続性を確認できているインターネットサービスプロバイダから受信したネットワークプレフィクスを持っているソースアドレスであった場合は、該ネットワークプレフィクスを受信したインターネットサービスプロバイダ宛に該パケットを転送し、前記ソースアドレスが、自ルータ装置が接続性を確認できているインターネットサービスプロバイダから受信したネットワークプレフィクスを持っているソースアドレスではなかった場合は、該パケットの転送を行わず、前記通信ノード宛に該パケットの転送を行わなかったことを通知する制御手段とを具備し、
前記ルータ装置の前記制御手段は、前記ソースアドレスが、自ルータ装置が接続性を確認できているインターネットサービスプロバイダから受信したネットワークプレフィクスを持っているソースアドレスであっても、所定の条件を満たす場合には、前記通信ノード宛に該パケットの転送を行わなかったことを通知するとともに、使用すべき前記インターネットサービスプロバイダが提供するネットワークプレフィクスを前記通信ノード宛に通知する機能を更に具備することを特徴とするソースアドレス選択システム。 - 複数のインターネットサービスプロバイダに接続されるとともに、ローカルネットワークに接続され、このローカルネットネットワークに接続された通信ノードのパケットを転送するルータ装置において、
前記インターネットサービスプロバイダとの接続性を確認する第１の確認手段と、
前記第１の確認手段により接続性が確認できた前記インターネットサービスプロバイダが提供するネットワークプレフィクスを受信する受信手段と、
前記受信したネットワークプレフィクスを前記ローカルネットワークに対し通知する通知手段と、
前記通信ノードから受信したパケットが、自ルータ装置が接続性を確認できているインターネットサービスプロバイダから受信したネットワークプレフィクスを持つソースアドレスか否かを確認する第２の確認手段と、
前記ソースアドレスが、自ルータ装置が接続性を確認できているインターネットサービスプロバイダから受信したネットワークプレフィクスを持っているソースアドレスであった場合は、該ネットワークプレフィクスを受信したインターネットサービスプロバイダ宛に該パケットを転送し、前記ソースアドレスが、自ルータ装置が接続性を確認できているインターネットサービスプロバイダから受信したネットワークプレフィクスを持っているソースアドレスではなかった場合は、該パケットの転送を行わず、前記通信ノード宛に該パケットの転送を行わなかったことを通知するとともに、前記第１の確認手段により接続性が確認できた前記インターネットサービスプロバイダが提供するネットワークプレフィクスを前記通信ノード宛に通知する制御手段とを具備したことを特徴とするルータ装置。 - 複数のインターネットサービスプロバイダに接続されるとともに、ローカルネットワークに接続され、このローカルネットネットワークに接続された通信ノードのパケットを転送するルータ装置において、
前記インターネットサービスプロバイダとの接続性を確認する第１の確認手段と、
前記第１の確認手段により接続性が確認できた前記インターネットサービスプロバイダが提供するネットワークプレフィクスを受信する受信手段と、
前記受信したネットワークプレフィクスを前記ローカルネットワークに対し通知する通知手段と、
前記通信ノードから受信したパケットが、自ルータ装置が接続性を確認できているインターネットサービスプロバイダから受信したネットワークプレフィクスを持つソースアドレスか否かを確認する第２の確認手段と、
前記ソースアドレスが、自ルータ装置が接続性を確認できているインターネットサービスプロバイダから受信したネットワークプレフィクスを持っているソースアドレスであった場合は、該ネットワークプレフィクスを受信したインターネットサービスプロバイダ宛 に該パケットを転送し、前記ソースアドレスが、自ルータ装置が接続性を確認できているインターネットサービスプロバイダから受信したネットワークプレフィクスを持っているソースアドレスではなかった場合は、該パケットの転送を行わず、前記通信ノード宛に該パケットの転送を行わなかったことを通知する制御手段とを具備し、
前記制御手段は、前記ソースアドレスが、自ルータ装置が接続性を確認できているインターネットサービスプロバイダから受信したネットワークプレフィクスを持っているソースアドレスではなかった場合に、前記第１の確認手段により接続性が確認できている前記インターネットサービスプロバイダがその時点で存在しないならば、該パケットの転送を行わず、前記通信ノード宛に該パケットの転送を行わなかったことを通知するとともに、前記パケットの送信先とすべき他のルータ装置を前記通信ノード宛に通知する機能を更に具備することを特徴とするルータ装置。 - 複数のインターネットサービスプロバイダに接続されるとともに、ローカルネットワークに接続され、このローカルネットネットワークに接続された通信ノードのパケットを転送するルータ装置において、
前記インターネットサービスプロバイダとの接続性を確認する第１の確認手段と、
前記第１の確認手段により接続性が確認できた前記インターネットサービスプロバイダが提供するネットワークプレフィクスを受信する受信手段と、
前記受信したネットワークプレフィクスを前記ローカルネットワークに対し通知する通知手段と、
前記通信ノードから受信したパケットが、自ルータ装置が接続性を確認できているインターネットサービスプロバイダから受信したネットワークプレフィクスを持つソースアドレスか否かを確認する第２の確認手段と、
前記ソースアドレスが、自ルータ装置が接続性を確認できているインターネットサービスプロバイダから受信したネットワークプレフィクスを持っているソースアドレスであった場合は、該ネットワークプレフィクスを受信したインターネットサービスプロバイダ宛に該パケットを転送し、前記ソースアドレスが、自ルータ装置が接続性を確認できているインターネットサービスプロバイダから受信したネットワークプレフィクスを持っているソースアドレスではなかった場合は、該パケットの転送を行わず、前記通信ノード宛に該パケットの転送を行わなかったことを通知する制御手段とを具備し、
前記制御手段は、前記ソースアドレスが、自ルータ装置が接続性を確認できているインターネットサービスプロバイダから受信したネットワークプレフィクスを持っているソースアドレスであっても、所定の条件を満たす場合には、前記通信ノード宛に該パケットの転送を行わなかったことを通知するとともに、使用すべき前記インターネットサービスプロバイダが提供するネットワークプレフィクスを前記通信ノード宛に通知する機能を更に具備することを特徴とするルータ装置。 - 複数のインターネットサービスプロバイダに接続されたルータ装置を介して所望の通信ノードとの通信を行う通信ノードにおいて、
前記ルータから、インターネットサービスプロバイダが提供するネットワークプレフィクスを受信する受信手段と、
前記ネットワークプレフィクスと自通信ノード固有の識別子に基づいてネットワークアドレスを生成する生成手段と、
パケットを送信する際に前記ネットワークアドレスをソースアドレスとしてヘッダに付与して送信する送信手段とを具備し、
前記送信手段にて送信したパケットに対し前記ルータから転送を行わなかった通知を受けるとともに接続性が確認できた前記インターネットサービスプロバイダのネットワークプレフィクスの通知を受けた場合には、前記パケットのソースアドレスを、新たに前記通知を受けたネットワークプレフィクスと自通信ノード固有の識別子に基づいて生成されたネットワークアドレスに変更し、前記パケットを再度送信することを特徴とする通信ノード。 - 前記通信ノードは、送信したパケットに対し前記ルータから転送を行わなかった通知を受けるとともに接続性が確認できた前記インターネットサービスプロバイダのネットワークプレフィクスの通知を受けた場合に、該ネットワークプレフィクスに基づく前記ネットワークアドレスを、当該パケットの再送信についてのみ使用することを特徴と請求項１０に記載の通信ノード。
- 前記通信ノードは、送信したパケットに対し前記ルータから転送を行わなかった通知を受けるとともに接続性が確認できた前記インターネットサービスプロバイダのネットワークプレフィクスの通知を受けた場合に、該ネットワークプレフィクスに基づく前記ネットワークアドレスを、それが無効になるまで使用することを特徴と請求項１０に記載の通信ノード。
- 複数のインターネットサービスプロバイダに接続されるとともに、ローカルネットワークに接続され、このローカルネットネットワークに接続された通信ノードのパケットを転送するルータ装置におけるソースアドレス選択方法であって、
前記インターネットサービスプロバイダとの接続性を確認する確認ステップと、
接続性が確認できた前記インターネットサービスプロバイダが提供するネットワークプレフィクスを受信するステップと、
前記受信したネットワークプレフィクスを前記ローカルネットワークに対し通知するステップと、
前記通信ノードから受信したパケットが、自ルータ装置が接続性を確認できているインターネットサービスプロバイダから受信したネットワークプレフィクスを持つソースアドレスか否かを確認するステップと、
前記ソースアドレスが、自ルータ装置が接続性を確認できているインターネットサービスプロバイダから受信したネットワークプレフィクスを持っているソースアドレスであった場合は、該ネットワークプレフィクスを受信したインターネットサービスプロバイダ宛に該パケットを転送し、前記ソースアドレスが、自ルータ装置が接続性を確認できているインターネットサービスプロバイダから受信したネットワークプレフィクスを持っているソースアドレスではなかった場合は、該パケットの転送を行わず、前記通信ノード宛に該パケットの転送を行わなかったことを通知するとともに、前記確認ステップにおいて接続性が確認できた前記インターネットサービスプロバイダが提供するネットワークプレフィクスを前記通信ノード宛に通知する制御ステップとを有することを特徴とするソースアドレス選択方法。 - 複数のインターネットサービスプロバイダに接続されるとともに、ローカルネットワークに接続され、このローカルネットネットワークに接続された通信ノードのパケットを転送するルータ装置におけるソースアドレス選択方法であって、
前記インターネットサービスプロバイダとの接続性を確認する確認ステップと、
接続性が確認できた前記インターネットサービスプロバイダが提供するネットワークプレフィクスを受信するステップと、
前記受信したネットワークプレフィクスを前記ローカルネットワークに対し通知するステップと、
前記通信ノードから受信したパケットが、自ルータ装置が接続性を確認できているインターネットサービスプロバイダから受信したネットワークプレフィクスを持つソースアドレスか否かを確認するステップと、
前記ソースアドレスが、自ルータ装置が接続性を確認できているインターネットサービスプロバイダから受信したネットワークプレフィクスを持っているソースアドレスであった場合は、該ネットワークプレフィクスを受信したインターネットサービスプロバイダ宛 に該パケットを転送し、前記ソースアドレスが、自ルータ装置が接続性を確認できているインターネットサービスプロバイダから受信したネットワークプレフィクスを持っているソースアドレスではなかった場合は、該パケットの転送を行わず、前記通信ノード宛に該パケットの転送を行わなかったことを通知する制御ステップとを有し、
前記制御ステップにおいては、前記ソースアドレスが、自ルータ装置が接続性を確認できているインターネットサービスプロバイダから受信したネットワークプレフィクスを持っているソースアドレスではなかった場合に、前記確認ステップにおいて接続性が確認できている前記インターネットサービスプロバイダがその時点で存在しないならば、該パケットの転送を行わず、前記通信ノード宛に該パケットの転送を行わなかったことを通知するとともに、前記パケットの送信先とすべき他のルータ装置を前記通信ノード宛に通知することを特徴とするソースアドレス選択方法。 - 複数のインターネットサービスプロバイダに接続されるとともに、ローカルネットワークに接続され、このローカルネットネットワークに接続された通信ノードのパケットを転送するルータ装置におけるソースアドレス選択方法であって、
前記インターネットサービスプロバイダとの接続性を確認する確認ステップと、
接続性が確認できた前記インターネットサービスプロバイダが提供するネットワークプレフィクスを受信するステップと、
前記受信したネットワークプレフィクスを前記ローカルネットワークに対し通知するステップと、
前記通信ノードから受信したパケットが、自ルータ装置が接続性を確認できているインターネットサービスプロバイダから受信したネットワークプレフィクスを持つソースアドレスか否かを確認するステップと、
前記ソースアドレスが、自ルータ装置が接続性を確認できているインターネットサービスプロバイダから受信したネットワークプレフィクスを持っているソースアドレスであった場合は、該ネットワークプレフィクスを受信したインターネットサービスプロバイダ宛に該パケットを転送し、前記ソースアドレスが、自ルータ装置が接続性を確認できているインターネットサービスプロバイダから受信したネットワークプレフィクスを持っているソースアドレスではなかった場合は、該パケットの転送を行わず、前記通信ノード宛に該パケットの転送を行わなかったことを通知する制御ステップとを有し、
前記制御ステップにおいては、前記ソースアドレスが、自ルータ装置が接続性を確認できているインターネットサービスプロバイダから受信したネットワークプレフィクスを持っているソースアドレスであっても、所定の条件を満たす場合には、前記通信ノード宛に該パケットの転送を行わなかったことを通知するとともに、使用すべき前記インターネットサービスプロバイダが提供するネットワークプレフィクスを前記通信ノード宛に通知することを特徴とするソースアドレス選択方法。 - 複数のインターネットサービスプロバイダに接続されるとともに、ローカルネットワークに接続され、このローカルネットネットワークに接続された通信ノードのパケットを転送するルータ装置としてコンピュータを機能させるためのプログラムであって、
前記プログラムは、
前記インターネットサービスプロバイダとの接続性を確認する第１の確認機能と、
前記第１の確認機能により接続性が確認できた前記インターネットサービスプロバイダが提供するネットワークプレフィクスを受信する第１の受信機能と、
前記受信したネットワークプレフィクスを前記ローカルネットワークに対し通知する通知機能と、
前記通信ノードから受信したパケットが、自ルータ装置が接続性を確認できているインターネットサービスプロバイダから受信したネットワークプレフィクスを持つソースアドレスか否かを確認する第２の確認機能と、
前記ソースアドレスが、自ルータ装置が接続性を確認できているインターネットサービスプロバイダから受信したネットワークプレフィクスを持っているソースアドレスであった場合は、該ネットワークプレフィクスを受信したインターネットサービスプロバイダ宛に該パケットを転送し、前記ソースアドレスが、自ルータ装置が接続性を確認できているインターネットサービスプロバイダから受信したネットワークプレフィクスを持っているソースアドレスではなかった場合は、該パケットの転送を行わず、前記通信ノード宛に該パケットの転送を行わなかったことを通知するとともに、前記第１の確認機能により接続性が確認できた前記インターネットサービスプロバイダが提供するネットワークプレフィクスを前記通信ノード宛に通知する制御機能とをコンピュータに実現させるためのプログラム。 - 複数のインターネットサービスプロバイダに接続されるとともに、ローカルネットワークに接続され、このローカルネットネットワークに接続された通信ノードのパケットを転送するルータ装置としてコンピュータを機能させるためのプログラムであって、
前記プログラムは、
前記インターネットサービスプロバイダとの接続性を確認する第１の確認機能と、
前記第１の確認機能により接続性が確認できた前記インターネットサービスプロバイダが提供するネットワークプレフィクスを受信する第１の受信機能と、
前記受信したネットワークプレフィクスを前記ローカルネットワークに対し通知する通知機能と、
前記通信ノードから受信したパケットが、自ルータ装置が接続性を確認できているインターネットサービスプロバイダから受信したネットワークプレフィクスを持つソースアドレスか否かを確認する第２の確認機能と、
前記ソースアドレスが、自ルータ装置が接続性を確認できているインターネットサービスプロバイダから受信したネットワークプレフィクスを持っているソースアドレスであった場合は、該ネットワークプレフィクスを受信したインターネットサービスプロバイダ宛に該パケットを転送し、前記ソースアドレスが、自ルータ装置が接続性を確認できているインターネットサービスプロバイダから受信したネットワークプレフィクスを持っているソースアドレスではなかった場合は、該パケットの転送を行わず、前記通信ノード宛に該パケットの転送を行わなかったことを通知する制御機能とをコンピュータに実現させるためのものであるとともに、
前記制御機能は、前記ソースアドレスが、自ルータ装置が接続性を確認できているインターネットサービスプロバイダから受信したネットワークプレフィクスを持っているソースアドレスではなかった場合に、前記第１の確認機能により接続性が確認できている前記インターネットサービスプロバイダがその時点で存在しないならば、該パケットの転送を行わず、前記通信ノード宛に該パケットの転送を行わなかったことを通知するとともに、前記パケットの送信先とすべき他のルータ装置を前記通信ノード宛に通知するものであることを特徴とするプログラム。 - 複数のインターネットサービスプロバイダに接続されるとともに、ローカルネットワークに接続され、このローカルネットネットワークに接続された通信ノードのパケットを転送するルータ装置としてコンピュータを機能させるためのプログラムであって、
前記プログラムは、
前記インターネットサービスプロバイダとの接続性を確認する第１の確認機能と、
前記第１の確認機能により接続性が確認できた前記インターネットサービスプロバイダが提供するネットワークプレフィクスを受信する第１の受信機能と、
前記受信したネットワークプレフィクスを前記ローカルネットワークに対し通知する通知機能と、
前記通信ノードから受信したパケットが、自ルータ装置が接続性を確認できているインターネットサービスプロバイダから受信したネットワークプレフィクスを持つソースアドレスか否かを確認する第２の確認機能と、
前記ソースアドレスが、自ルータ装置が接続性を確認できているインターネットサービスプロバイダから受信したネットワークプレフィクスを持っているソースアドレスであった場合は、該ネットワークプレフィクスを受信したインターネットサービスプロバイダ宛に該パケットを転送し、前記ソースアドレスが、自ルータ装置が接続性を確認できているインターネットサービスプロバイダから受信したネットワークプレフィクスを持っているソースアドレスではなかった場合は、該パケットの転送を行わず、前記通信ノード宛に該パケットの転送を行わなかったことを通知する制御機能とをコンピュータに実現させるためのものであるとともに、
前記制御機能は、前記ソースアドレスが、自ルータ装置が接続性を確認できているインターネットサービスプロバイダから受信したネットワークプレフィクスを持っているソースアドレスであっても、所定の条件を満たす場合には、前記通信ノード宛に該パケットの転送を行わなかったことを通知するとともに、使用すべき前記インターネットサービスプロバイダが提供するネットワークプレフィクスを前記通信ノード宛に通知するものであることを特徴とするプログラム。 - 複数のインターネットサービスプロバイダに接続されたルータ装置を介して所望の通信ノードとの通信を行う通信ノードにおけるソースアドレス選択方法であって、
前記ルータから、インターネットサービスプロバイダが提供するネットワークプレフィクスを受信し、
前記ネットワークプレフィクスと自通信ノード固有の識別子に基づいてネットワークアドレスを生成し、
パケットを送信する際に前記ネットワークアドレスをソースアドレスとしてヘッダに付与して送信し、
送信した前記パケットに対し前記ルータから転送を行わなかった通知を受けるとともに接続性が確認できた前記インターネットサービスプロバイダのネットワークプレフィクスの通知を受けた場合には、前記パケットのソースアドレスを、新たに前記通知を受けたネットワークプレフィクスと自通信ノード固有の識別子に基づいて生成されたネットワークアドレスに変更し、前記パケットを再度送信することを特徴とする通信ノードにおけるソースアドレス選択方法。 - 複数のインターネットサービスプロバイダに接続されたルータ装置を介して所望の通信ノードとの通信を行う通信ノードとしてコンピュータを機能させるためのプログラムであって、
前記ルータから、インターネットサービスプロバイダが提供するネットワークプレフィクスを受信する受信機能と、
前記ネットワークプレフィクスと自通信ノード固有の識別子に基づいてネットワークアドレスを生成する生成機能と、
パケットを送信する際に前記ネットワークアドレスをソースアドレスとしてヘッダに付与して送信する送信機能と、
前記送信機能にて送信したパケットに対し前記ルータから転送を行わなかった通知を受けるとともに接続性が確認できた前記インターネットサービスプロバイダのネットワークプレフィクスの通知を受けた場合には、前記パケットのソースアドレスを、新たに前記通知を受けたネットワークプレフィクスと自通信ノード固有の識別子に基づいて生成されたネットワークアドレスに変更し、前記パケットを再度送信する機能とをコンピュータに実現させるためのプログラム。 - 複数のインターネットサービスプロバイダに接続されたルータ装置と、このルータに接続された通信ノードとを含むソースアドレス選択システムにおけるソースアドレス選択方法であって、
前記ルータ装置は、
前記インターネットサービスプロバイダとの接続性を確認する確認ステップと、
前記確認ステップにおいて接続性が確認できた前記インターネットサービスプロバイダが提供するネットワークプレフィクスを受信するステップと、
前記受信したネットワークプレフィクスを前記通信ノード宛に通知するステップとを有し、
前記通信ノードは、
前記ルータから前記ネットワークプレフィクスを受信するステップと、
前記ネットワークプレフィクスと自通信ノード固有の識別子に基づいてネットワークアドレスを生成するステップと、
パケットを送信する際に前記ネットワークアドレスをソースアドレスとしてヘッダに付与して送信するステップとを有し、
前記ルータ装置は更に、
前記通信ノードから受信したパケットが、自ルータ装置が接続性を確認できているインターネットサービスプロバイダから受信したネットワークプレフィクスを持つソースアドレスか否かを確認するステップと、
前記ソースアドレスが、自ルータ装置が接続性を確認できているインターネットサービスプロバイダから受信したネットワークプレフィクスを持っているソースアドレスであった場合は、該ネットワークプレフィクスを受信したインターネットサービスプロバイダ宛に該パケットを転送し、前記ソースアドレスが、自ルータ装置が接続性を確認できているインターネットサービスプロバイダから受信したネットワークプレフィクスを持っているソースアドレスではなかった場合は、該パケットの転送を行わず、前記通信ノード宛に該パケットの転送を行わなかったことを通知するとともに、前記確認ステップにおいて接続性が確認できた前記インターネットサービスプロバイダが提供するネットワークプレフィクスを前記通信ノード宛に通知する制御ステップとを有することを特徴とするソースアドレス選択方法。 - 複数のインターネットサービスプロバイダに接続されたルータ装置と、このルータに接続された通信ノードとを含むソースアドレス選択システムにおけるソースアドレス選択方法であって、
前記ルータ装置は、
前記インターネットサービスプロバイダとの接続性を確認する確認ステップと、
前記確認ステップにおいて接続性が確認できた前記インターネットサービスプロバイダが提供するネットワークプレフィクスを受信するステップと、
前記受信したネットワークプレフィクスを前記通信ノード宛に通知するステップとを有し、
前記通信ノードは、
前記ルータから前記ネットワークプレフィクスを受信するステップと、
前記ネットワークプレフィクスと自通信ノード固有の識別子に基づいてネットワークアドレスを生成するステップと、
パケットを送信する際に前記ネットワークアドレスをソースアドレスとしてヘッダに付与して送信するステップとを有し、
前記ルータ装置は更に、
前記通信ノードから受信したパケットが、自ルータ装置が接続性を確認できているインターネットサービスプロバイダから受信したネットワークプレフィクスを持つソースアドレスか否かを確認するステップと、
前記ソースアドレスが、自ルータ装置が接続性を確認できているインターネットサービスプロバイダから受信したネットワークプレフィクスを持っているソースアドレスであった場合は、該ネットワークプレフィクスを受信したインターネットサービスプロバイダ宛に該パケットを転送し、前記ソースアドレスが、自ルータ装置が接続性を確認できているインターネットサービスプロバイダから受信したネットワークプレフィクスを持っている ソースアドレスではなかった場合は、該パケットの転送を行わず、前記通信ノード宛に該パケットの転送を行わなかったことを通知する制御ステップとを有し、
前記ルータ装置における前記制御ステップにおいて、前記ソースアドレスが、自ルータ装置が接続性を確認できているインターネットサービスプロバイダから受信したネットワークプレフィクスを持っているソースアドレスではなかった場合に、前記確認ステップにおいて接続性が確認できている前記インターネットサービスプロバイダがその時点で存在しないならば、該パケットの転送を行わず、前記通信ノード宛に該パケットの転送を行わなかったことを通知するとともに、前記パケットの送信先とすべき他のルータ装置を前記通信ノード宛に通知することを特徴とするソースアドレス選択方法。 - 複数のインターネットサービスプロバイダに接続されたルータ装置と、このルータに接続された通信ノードとを含むソースアドレス選択システムにおけるソースアドレス選択方法であって、
前記ルータ装置は、
前記インターネットサービスプロバイダとの接続性を確認する確認ステップと、
前記確認ステップにおいて接続性が確認できた前記インターネットサービスプロバイダが提供するネットワークプレフィクスを受信するステップと、
前記受信したネットワークプレフィクスを前記通信ノード宛に通知するステップとを有し、
前記通信ノードは、
前記ルータから前記ネットワークプレフィクスを受信するステップと、
前記ネットワークプレフィクスと自通信ノード固有の識別子に基づいてネットワークアドレスを生成するステップと、
パケットを送信する際に前記ネットワークアドレスをソースアドレスとしてヘッダに付与して送信するステップとを有し、
前記ルータ装置は更に、
前記通信ノードから受信したパケットが、自ルータ装置が接続性を確認できているインターネットサービスプロバイダから受信したネットワークプレフィクスを持つソースアドレスか否かを確認するステップと、
前記ソースアドレスが、自ルータ装置が接続性を確認できているインターネットサービスプロバイダから受信したネットワークプレフィクスを持っているソースアドレスであった場合は、該ネットワークプレフィクスを受信したインターネットサービスプロバイダ宛に該パケットを転送し、前記ソースアドレスが、自ルータ装置が接続性を確認できているインターネットサービスプロバイダから受信したネットワークプレフィクスを持っているソースアドレスではなかった場合は、該パケットの転送を行わず、前記通信ノード宛に該パケットの転送を行わなかったことを通知する制御ステップとを有し、
前記ルータ装置における前記制御ステップにおいては、前記ソースアドレスが、自ルータ装置が接続性を確認できているインターネットサービスプロバイダから受信したネットワークプレフィクスを持っているソースアドレスであっても、所定の条件を満たす場合には、前記通信ノード宛に該パケットの転送を行わなかったことを通知するとともに、使用すべき前記インターネットサービスプロバイダが提供するネットワークプレフィクスを前記通信ノード宛に通知することを特徴とするソースアドレス選択方法。
Priority Applications (6)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2002097652A JP3665622B2 (ja) | 2002-03-29 | 2002-03-29 | ソースアドレス選択システム、ルータ装置、通信ノード及びソースアドレス選択方法 |
| CNB031083919A CN1242593C (zh) | 2002-03-29 | 2003-03-28 | 源地址选择***、路由器装置、通信节点和源地址选择方法 |
| EP20030252002 EP1349323B1 (en) | 2002-03-29 | 2003-03-28 | Source address selection system suitable for a multi-home environment |
| KR20030019560A KR100693320B1 (ko) | 2002-03-29 | 2003-03-28 | 소스 어드레스 선택시스템, 라우터장치, 라우터장치로서 컴퓨터를 기능시키기 위한 프로그램을 기록한 컴퓨터 독출가능한 기록매체, 통신노드 및 소스 어드레스 선택방법 |
| DE2003600299 DE60300299T2 (de) | 2002-03-29 | 2003-03-28 | System zur Auswahl von Quell-Adressen geeignet für eine Umgebung mit mehreren Heimatnetzen |
| US10/401,874 US7680949B2 (en) | 2002-03-29 | 2003-03-31 | Source address selection scheme suitable for multi-home environment |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2002097652A JP3665622B2 (ja) | 2002-03-29 | 2002-03-29 | ソースアドレス選択システム、ルータ装置、通信ノード及びソースアドレス選択方法 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2003298635A JP2003298635A (ja) | 2003-10-17 |
| JP3665622B2 true JP3665622B2 (ja) | 2005-06-29 |
Family
ID=27800582
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2002097652A Expired - Fee Related JP3665622B2 (ja) | 2002-03-29 | 2002-03-29 | ソースアドレス選択システム、ルータ装置、通信ノード及びソースアドレス選択方法 |
Country Status (6)
| Country | Link |
|---|---|
| US (1) | US7680949B2 (ja) |
| EP (1) | EP1349323B1 (ja) |
| JP (1) | JP3665622B2 (ja) |
| KR (1) | KR100693320B1 (ja) |
| CN (1) | CN1242593C (ja) |
| DE (1) | DE60300299T2 (ja) |
Families Citing this family (26)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| KR100580169B1 (ko) * | 2003-06-05 | 2006-05-15 | 삼성전자주식회사 | 복수 ｉｓｐ들을 유동적으로 선택하여 라우팅하는 장치 및방법 |
| JP2004364109A (ja) * | 2003-06-06 | 2004-12-24 | Canon Inc | テンポラリアドレス通信装置、プログラム、記録媒体、および方法 |
| US20050021782A1 (en) * | 2003-06-16 | 2005-01-27 | Malik Dale W. | Validating user information prior to switching internet service providers |
| US20040254991A1 (en) * | 2003-06-16 | 2004-12-16 | Malik Dale W. | Switching Internet service providers |
| US20040254976A1 (en) * | 2003-06-16 | 2004-12-16 | Malik Dale W. | Migrating from an old instant messaging (IM) platform to a new IM platform |
| US7574524B2 (en) * | 2003-09-30 | 2009-08-11 | International Business Machines Corporation | Method and system for on-demand allocation of a dynamic network of services |
| CN100454882C (zh) * | 2003-12-19 | 2009-01-21 | 华为技术有限公司 | 多isp局域网的出口选择方法及装置 |
| US7440451B2 (en) * | 2004-04-16 | 2008-10-21 | The Boeing Company | Global internet protocol prefix number mobility |
| US20050286490A1 (en) * | 2004-06-23 | 2005-12-29 | Inventec Appliances Corporation | Method for automatically selecting lowest rate for dialing phone call via wireless telecommunication device |
| KR100807817B1 (ko) | 2004-12-17 | 2008-02-27 | 엔에이치엔(주) | 버스형 네트워크 구조의 통신 네트워크 시스템에서서브시스템 사이의 로드를 조절하는 방법 |
| JP2006261768A (ja) * | 2005-03-15 | 2006-09-28 | Toshiba Corp | 通信装置、通信方法および通信プログラム |
| JP4616882B2 (ja) * | 2005-03-29 | 2011-01-19 | パナソニック株式会社 | 通信制御方法及びアドレス管理ノード並びにモバイルノード |
| US7894433B2 (en) * | 2005-08-08 | 2011-02-22 | Cisco Technology, Inc. | Default gateway router supplying IP address prefixes ordered for source address selection by host device |
| JP4751788B2 (ja) * | 2005-08-24 | 2011-08-17 | 株式会社リコー | 通信機器、通信方法および通信プログラム |
| JP2007288315A (ja) * | 2006-04-13 | 2007-11-01 | Nec Corp | アドレス管理装置、アドレス管理システムおよびアドレス管理方法 |
| US7953868B2 (en) * | 2007-01-31 | 2011-05-31 | International Business Machines Corporation | Method and system for preventing web crawling detection |
| EP2048857A1 (en) * | 2007-10-12 | 2009-04-15 | PacketFront Systems AB | Method of configuring routers using external servers |
| CN101753419B (zh) * | 2008-12-08 | 2012-08-15 | 华为技术有限公司 | 发送数据、转发数据的方法、设备和多地址空间移动网络 |
| JP5326863B2 (ja) | 2009-06-29 | 2013-10-30 | ブラザー工業株式会社 | アドレス情報提供装置 |
| WO2011117959A1 (ja) * | 2010-03-23 | 2011-09-29 | キヤノン株式会社 | 通信装置、通信装置の制御方法、プログラム |
| JP5105124B2 (ja) * | 2011-02-24 | 2012-12-19 | Ｎｅｃアクセステクニカ株式会社 | ルータ装置、プレフィクス管理にもとづくパケット制御方法およびプログラム |
| JP5626408B2 (ja) * | 2013-06-03 | 2014-11-19 | ブラザー工業株式会社 | アドレス情報提供装置 |
| US10405365B2 (en) | 2015-12-16 | 2019-09-03 | At&T Intellectual Property I, L.P. | Method and apparatus for web browsing on multihomed mobile devices |
| CN107734528B (zh) * | 2017-11-03 | 2021-01-15 | Oppo广东移动通信有限公司 | 无线网络检测方法、装置、存储介质及终端 |
| US10812445B2 (en) * | 2018-02-13 | 2020-10-20 | Sling Media Pvt Ltd | Cloud access to local network addresses |
| CN115733820A (zh) * | 2022-11-01 | 2023-03-03 | 海尔优家智能科技（北京）有限公司 | 地址前缀的分配方法及装置、存储介质及电子装置 |
Family Cites Families (10)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5790548A (en) * | 1996-04-18 | 1998-08-04 | Bell Atlantic Network Services, Inc. | Universal access multimedia data network |
| WO2000014919A2 (en) * | 1998-09-02 | 2000-03-16 | N.C.C. Export Systems 1995 Ltd. | Apparatus and methods for connecting a network user to a network service provider |
| JP3463607B2 (ja) | 1999-05-24 | 2003-11-05 | 日本電気株式会社 | 通信ネットワークシステムにおける始点アドレスの選択方法、選択装置および同方法が記録された記録媒体 |
| FI107421B (fi) * | 1999-06-28 | 2001-07-31 | Stonesoft Oy | Yhteyksien valintamenetelmä |
| US6603758B1 (en) * | 1999-10-01 | 2003-08-05 | Webtv Networks, Inc. | System for supporting multiple internet service providers on a single network |
| AU2001250888A1 (en) * | 2000-03-20 | 2001-10-03 | At And T Corp. | Service selection in a shared access network using policy routing |
| US6981055B1 (en) * | 2000-08-22 | 2005-12-27 | Internap Network Services Corporation | Method and system for optimizing routing through multiple available internet route providers |
| US20030172170A1 (en) * | 2002-03-08 | 2003-09-11 | Johnson Gerald R. | Providing multiple ISP access to devices behind NAT |
| KR100424614B1 (ko) * | 2002-04-27 | 2004-03-27 | 삼성전자주식회사 | 인터넷 프로토콜 기반 통신 시스템 및 그의 호스트 주소설정 및 소스 주소 선택 방법 |
| US20040111529A1 (en) * | 2002-12-10 | 2004-06-10 | Intel Corporation (A Delaware Corporation) | Dynamic host based load balancing of a multihomed network |
-
2002
- 2002-03-29 JP JP2002097652A patent/JP3665622B2/ja not_active Expired - Fee Related
-
2003
- 2003-03-28 DE DE2003600299 patent/DE60300299T2/de not_active Expired - Fee Related
- 2003-03-28 CN CNB031083919A patent/CN1242593C/zh not_active Expired - Fee Related
- 2003-03-28 KR KR20030019560A patent/KR100693320B1/ko not_active IP Right Cessation
- 2003-03-28 EP EP20030252002 patent/EP1349323B1/en not_active Expired - Lifetime
- 2003-03-31 US US10/401,874 patent/US7680949B2/en not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| DE60300299T2 (de) | 2006-05-11 |
| KR20030078770A (ko) | 2003-10-08 |
| JP2003298635A (ja) | 2003-10-17 |
| US20050102415A1 (en) | 2005-05-12 |
| EP1349323B1 (en) | 2005-02-02 |
| CN1242593C (zh) | 2006-02-15 |
| EP1349323A1 (en) | 2003-10-01 |
| US7680949B2 (en) | 2010-03-16 |
| CN1455555A (zh) | 2003-11-12 |
| KR100693320B1 (ko) | 2007-03-13 |
| DE60300299D1 (de) | 2005-03-10 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP3665622B2 (ja) | ソースアドレス選択システム、ルータ装置、通信ノード及びソースアドレス選択方法 | |
| JP4020576B2 (ja) | パケット転送方法、移動端末装置及びルータ装置 | |
| JP3545987B2 (ja) | 通信方法及びモバイルｉｐ環境 | |
| EP2426885B9 (en) | Method, device and system for mobile virtual private network communication | |
| JP3501994B2 (ja) | デスティネーションノードへパケットを分配するルーティングパスを確立する方法 | |
| US7729312B2 (en) | Router apparatus, route information distributing method, and communications system | |
| JP5097620B2 (ja) | マルチパス通信システム | |
| KR100811890B1 (ko) | 인터넷 시스템에서 서비스 플로우를 보장하는 애니캐스트라우팅 방법 및 장치 | |
| JP2006086800A (ja) | ソースアドレスを選択する通信装置 | |
| JP2001244957A (ja) | Ｔｃｐ終端機能付きｉｐルータ装置および媒体 | |
| US7324439B2 (en) | Application-transparent IP redundancy | |
| US20140317296A1 (en) | Allocating internet protocol (ip) addresses to nodes in communications networks which use integrated is-is | |
| TWI323101B (en) | Communication system and its terminal | |
| CN110881006B (zh) | 发送报文的方法、网络设备及计算机存储介质 | |
| JP2003521137A (ja) | モバイルノードから対応ノードに送信されるデータに関してサービス品質をサポートする方法及び移動局ｉｐ環境 | |
| US6826623B1 (en) | Detecting a dead gateway for subsequent non-TCP transmission by sending a first TCP packet and deleting an ARP entry associated with the gateway | |
| JP3710711B2 (ja) | 外部エージェントおよび複数のモバイル・ノードを備えた外部ネットワークに対するサービス品質をサポートする方法及びモバイルｉｐ環境 | |
| JP4463838B2 (ja) | ネットワークにおけるサービス機器要素を設定する方法及び装置 | |
| JP2004511961A (ja) | Ｉｐネットワークにおいて移動性と特別サービスを可能にする通信システム | |
| KR101410510B1 (ko) | Ｓｃｔｐ를 이용한 데이터 전송 방법 및 장치 | |
| JP6898120B2 (ja) | ネットワークシステム、ネットワークシステムのアドレス解決方法、および、拠点側接続装置 | |
| Narten et al. | RFC1970: Neighbor Discovery for IP version 6 (IPv6) | |
| JP2004248257A (ja) | 通信システム及び端末 | |
| JP4093265B2 (ja) | 通信システム | |
| CN112804141A (zh) | 发送报文的方法、网络设备及计算机存储介质 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20041209 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20041214 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20050214 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20050329 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20050401 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20080408 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20090408 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100408 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100408 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110408 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130408 Year of fee payment: 8 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20140408 Year of fee payment: 9 |
|
| LAPS | Cancellation because of no payment of annual fees |