JP2010502036A - 複数のアドレスを登録する際にアドレスを検証するための方法及び装置 - Google Patents

Abstract

【課題】モバイルノードが一括登録の際に指定した特定の気付けアドレスを実際に使用していることを検証するために、一括登録を受信するすべてのノードのための方法を提供すること。
【解決手段】一括登録は、１回のバインディング更新（ＢＵ）によってホーム・エージェント（ＨＡ）において、複数の気付けアドレス（ＣｏＡ）をマルチモード・ノードのホーム・アドレスにバインドすることができる方法である。しかし、モバイルＩＰｖ６が、マルチモード・ノード及びそのＨＡがすでに相互認証を確立していることを意味する場合には、ＨＡは暗黙にマルチモード・ノードを信用し、それ故、１つのＢＵ内のマルチモード・ノードが指定したＣｏＡを検証しないで、一括登録を受け入れることができる。しかし、この信用関係は、悪意のあるマルチモード・ノードが、ＨＡがマルチモード・ノードが前記ＣｏＡを使用していることを検証しないで、ＨＡ内のそのＣｏＡとしてビクティムのアドレスをうまくバインディングすることができることを意味する。アドレスがバインドされると、悪意のあるマルチモード・ノードは、ビクティムのアドレスに不必要なパケットを大量に流すことをＨＡに指示することにより再送信攻撃を行うことができる。それ故、本発明の場合には、ＨＡがマルチモード・ノードに対して一括登録を行っている場合には、ＨＡは１つのＢＵ内に指定されているこれらＣｏＡに未検証のタグを付ける。ＨＡのところで実施する検証機構は、前記未検証ＣｏＡを使用する前に、未検証ＣｏＡのアドレス可能性を試験するためにトリガされる。この検証方法は、前記未検証ＣｏＡのアドレス可能性を試験するために、ＨＡがマルチモード・ノードの未検証ＣｏＡに確認メッセージを送信するステップを含む。マルチモード・ノードがＨＡから確認メッセージを受信した場合には、マルチモード・ノードはＨＡに他の１つのＢＵで応答する。マルチモード・ノードから第２の１つのＢＵを受信した場合には、ＨＡはマルチモード・ノードの前記未検証ＣｏＡを検証することができる。
【選択図】図４

Description

本発明は、移動通信ネットワーク内の電気通信の分野に関し、特に、気付けアドレスを検証するための方法に関する。

モバイルＩＰｖ６［非特許文献１］、すなわちＭＩＰｖ６を使用すれば、モバイルノード（ＭＮ：移動ノード）は、そのホーム・ネットワークの外に出ている場合でも、通信することができるように、そのホーム・エージェント（ＨＡ）のところでその気付けアドレス（ＣｏＡ）をそのホーム・アドレス（ＨｏＡ）にバインド（結合）することができる。この方法の場合には、ＭＮはそのＨｏＡにバインドしたいＣｏＡを指定するバインディング更新（ＢＵ）メッセージをそのＨＡに送信しなければならない。さらに、それほど遠くない将来、ラップトップ又は他のハンドヘルド電子周辺機器をいくつかのネットワーク・インタフェースと統合することができるようになり、そのためＭＮは１つのホーム・アドレスとバインドしているいくつかのＣｏＡを処理することができるようになる。ＭＩＰｖ６を使用すれば、ＭＮが１つのＢＵで複数のＣｏＡを定義することができるように、別の気付けアドレス・オプションを使用することができる。しかし、このオプションは、ＭＮが複数のバインディングをうまく行うための手段を有していない。何故なら、現在のＭＩＰｖ６は所与のＨｏＡに１つのＣｏＡしかバインドできないからである。

現在、ＩＰｖ６（Ｍｏｎａｍｉ６）作業グループ内のモバイルノード及び複数のインタフェースは、所与のホーム・エージェント・アドレスのところで複数のＣｏＡの登録をサポートするための方法を定義している。インターネットドラフト「複数の気付けアドレスの登録」（Ｍｕｌｔｉｐｌｅ Ｃａｒｅ−ｏｆ Ａｄｄｒｅｓｓｅｓ Ｒｅｇｉｓｔｒａｔｉｏｎ）［非特許文献２］は、ＨｏＡへの複数のバインディングを区別するためにバインディング一意識別（ＢＩＤ）番号と呼ばれる識別番号を導入している。ＢＩＤは、モバイルノードの１つのホーム・アドレス（ＨｏＡ）にバインドしているインタフェース又はＣｏＡに割り当てられる。それ故、ＨｏＡはモバイルノード自身に関連していて、一方、ＢＩＤは、モバイルノードが登録する各バインディングを識別する。モバイルノードは、ＢＵによりそのホーム・エージェントにＢＩＤを通知する。ホーム・エージェントはそのバインディングキャッシュにＢＩＤを記録する。

さらに、両方のインターネットドラフト「複数の気付けアドレスの登録」（Ｍｕｌｔｉｐｌｅ Ｃａｒｅ−ｏｆ Ａｄｄｒｅｓｓｅｓ Ｒｅｇｉｓｔｒａｔｉｏｎ）［非特許文献２］及び「複数のＣｏＡ性能の分析」（Ｍｕｌｔｉｐｌｅ ＣｏＡ Ｐｅｒｆｏｒｍａｎｃｅ Ａｎａｌｙｓｉｓ）［非特許文献３］において、起草者は、ＨＡに複数のＣｏＡを登録するための最適化方法を提案している。以後一括登録と呼ぶこの最適化方法を使用すれば、ＭＮは１つのＢＵメッセージにより１つのＨｏＡに複数のＣｏＡをバインドすることができる。

［特許文献１］は、１つ又は複数のホーム・エージェントの複数のホーム・アドレスを、１つのモバイルＩＰシグナリングフェーズにより導入し、リフレッシュし、及び削除することができるようにする統合バインディング更新メッセージの使用を提案している。１つのシグナリングインスタンスを使用することにより、信号帯域幅及び信号状態の量を従来のモバイルＩＰメッセージを使用する場合よりも低減することができる。エンドツーエンド・ノード間の認証は、認証、許可及び課金管理（ＡＡＡ）サーバにより行われる。

第３世代パートナーシップ・プロジェクト（３ＧＰＰ：Ｔｈｉｒｄ Ｇｅｎｅｒａｔｉｏｎ Ｐａｒｔｎｅｒｓｈｉｐ Ｐｒｏｊｅｃｔ）によって扱われるロング・ターム・エボリューション（ＬＴＥ：Ｌｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ）プロジェクトは、第４世代（４Ｇ）移動通信技術に適合するように現在のＵＭＴＳ（Ｕｎｉｖｅｒｓａｌ Ｍｏｂｉｌｅ Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓ Ｓｙｓｔｅｍ）標準規格を改良することを目的としている。４Ｇネットワークの特徴は、既存の回線及びパケット交換ネットワークをオールＩＰシステムにシフトさせることにある。オールＩＰシステムは、通信及びシグナリングのためにインターネット・プロトコル（ＩＰ）を使用することに基づくネットワークについて言及している。したがって、システムにおけるシフトでは、既存のＵＭＴＳアーキテクチャの発展が必要となり、この作業は、３ＧＰＰにおけるシステム・アーキテクチャ・エボリューション（ＳＡＥ：Ｓｙｓｔｅｍｓ Ａｒｃｈｉｔｅｃｔｕｒｅ Ｅｖｏｌｕｔｉｏｎ）によって取り扱われている。セルラのオペレータにとって、４Ｇへのシフトは、どのようにオールＩＰシステムにおいて加入者のモビリティをサポートするかを考慮する必要がある。したがって、モバイルＩＰは、こうした必要条件を満たす候補として、セルラのオペレータによって選択される。これは、セルラのオペレータが、その加入者のモバイルノードに対してモバイルＩＰシグナリング（例えば、ＣｏＡバインディング）の処理を行うような次世代システムの中に、ホーム・エージェント（ＨＡ：Ｈｏｍｅ Ａｇｅｎｔ）を配置することを意味している。

［特許文献２］及び［特許文献３］の両方には、マルチ・インタフェースを有するモバイルノード（ＭＮ：Ｍｏｂｉｌｅ Ｎｏｄｅ）（マルチモード・ノードと呼ばれる）が、オールＩＰシステムにおいて同時接続を実現するシナリオが説明されている。両方の従来技術において、ＭＮは、モビリティ・サービスをＭＮに提供しているセルラのオペレータへの加入者である。ＭＮは１つのインタフェースをセルラ網（ホーム・ネットワークと呼ばれる）に接続させる。このホームに接続されたインタフェースは、通信にホーム・アドレス（ＨｏＡ：Ｈｏｍｅ Ａｄｄｒｅｓｓ）を使用する。同時に、ＭＮは、無線ローカル・エリア・ネットワーク（ＷＬＡＮ：ｗｉｒｅｌｅｓｓ ｌｏｃａｌ ａｒｅａ ｎｅｔｗｏｒｋ）に接続されている別のインタフェースを有している。この外部（ｆｏｒｅｉｇｎ）に接続されたインタフェースは、通信に気付けアドレス（ＣｏＡ．ＷＬＡＮ）を使用する。ＭＮがそのホーム及び外部に接続されたインタフェースを両方使用できるようにするため、ＭＮは、ＨｏＡ及びＣｏＡの両方をＭＮへの有効なルート経路としてバインドさせる単一のバインディング更新（ＢＵ）をＨＡに送信する。この動作は、ＨＡに対して、バインディングキャッシュエントリ（ＢＣＥ：ｂｉｎｄｉｎｇ ｃａｃｈｅ ｅｎｔｒｙ）のＣｏＡエントリとしてＨｏＡをバインドする処理を行わせるものであり、これによって、ＨＡは、ＭＮへのＨｏＡ及びＣｏＡルート経路を使用できるようになる。

［非特許文献４］は、バインディング更新（ＢＵ）メッセージ内の代替ＣｏＡの到達可能性を検証するために、状態クッキーを使用することを提案している。モバイルノード（ＭＮ）は、代替ＣｏＡオプションが存在する第１のＢＵを通信相手（例えば、ホーム・エージェント）へ送信する。通信相手がＢＵを受信すると、通信相手は、新たな専用のステータス及びクッキー・オプションを有するバインディング応答（ＢＡ：Ｂｉｎｄｉｎｇ Ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ）メッセージを、代替ＣｏＡオプションに記載されているＣｏＡへ送信することによってＢＵを拒絶する。同時に、通信相手は、一時的にＭＮのバインディングキャッシュエントリを無効化する。これは、第２のＢＵが受信された後に代替ＣｏＡを検証するまで、通信相手が通信にＭＮのホーム・アドレス（ＨｏＡ）を使用することを意味している。ＭＮがＢＡを受信すると、ＭＮは、クッキー・オプションにクッキーを埋め込んだ第２のＢＵを通信相手へ再送する処理を行う。通信相手は、第２のＢＵ内のクッキーをチェックし、代替ＣｏＡ経由でＭＮへ送信されたものと同一か否かを確かめる。同一である場合、通信相手は、代替ＣｏＡが到達可能状態であるという検証を完了し、ＭＮの現在のＣｏＡとして代替ＣｏＡを受け入れる。

［非特許文献５］は、通信相手ノード（ＣＮ：ｃｏｒｒｅｓｐｏｎｄｅｎｔ ｎｏｄｅ）がモバイルノード（ＭＮ）からの早期バインディング更新（ＥＢＵ：ｅａｒｌｙ ｂｉｎｄｉｎｇ ｕｐｄａｔｅ）メッセージに記載されているＣｏＡを検証するメカニズムを提案している。ＥＢＵは、ＭＮの気付けアドレスを検証する前に、ＣＮがＭＮに関して一時的な状態を作成できるようにすることを目的としている。したがって、ＣＮは、各バインディングに関して、“確認済み気付けアドレス”として知られる状態に対応する追加の１ビットフラグを保持している。この状態は、ＭＮの各気付けアドレスが確認されているか否かを示す。“確認済み気付けアドレス”状態が“１”であれば、気付けアドレスはその到達可能性が既に検証されていることを意味する。しかしながら、“確認済み気付けアドレス”状態が“０”であれば、気付けアドレスはその到達可能性がまだ検証されていないことを意味する。［非特許文献５］は、定期的に確認済みの気付けアドレスにおけるＭＮの存在を調べるために、ＣＮが気付けアドレス・スポット・チェックと呼ばれるメカニズムを使用することを提案している。したがって、ＣＮは、インターネット制御メッセージプロトコル（ＩＣＭＰ：Ｉｎｔｅｒｎｅｔ Ｃｏｎｔｒｏｌ Ｍｅｓｓａｇｅ Ｐｒｏｔｏｃｏｌ）エコー要求をＭＮの気付けアドレスへ送信し、ＭＮからＩＣＭＰ応答による返答が来ることを予測して、特定の気付けアドレスに関する到達可能性を検証する。
O'NEILL, Alan, "METHODS AND APPARATUS FOR AGGREGATING MIP AND AAA MESSAGES", PCT Patent Application Publication, WO 03/096592A2, May 2003. J. Bachmann, K. Weniger and R. Hakenberg, "Enabling simultaneous use of home network and foreign network by a multihomed mobile", PCT Patent Application Publication, WO 07/039016A1, 17 August, 2006. J. Hirano, C-W. Ng, B. Koh and PY. Tan, "Mobile node and communication control method", PCT Patent Application Publication, WO 07/007856A1, 7 July, 2006 D. Johnson, C. Perkins and J. Arkko, "Mobility Support in IPv6", Internet Engineering Task Force Request For Comments 3775, June 2004. R. Wakikawa, T. Ernst and K. Nagami, "Multiple Care-of Addresses Registration", draft-ietf-monami6-multiplecoa-00, Monami6 Working Group Internet-Draft, June 12, 2006. M. Kuparinen, H. Mahkonen and T. Kauppinen, "Multiple CoA Performance Analysis", draft-kuparinen-monami6-mcoa-performance-00, Network Working Group Internet-Draft, April 20, 2006.. F. Dupont, and J-M. Combes, "Care-of Address Test for MIPv6 using a State Cookie", draft-dupont-mipv6-rrcookie-00, Internet Engineering Task Force Internet-Draft, January 10, 2005. C. Vogt, J. Arkko, R. Bless, M. Doll and T. Kfner, "Credit-Based Authorization for Mobile IPv6 Early Binding Updates", draft-vogt-mipv6-credit-based-authorization-00, Internet Engineering Task Force Internet-Draft, May 21, 2004.

しかし、すべての上記従来技術（特に［特許文献１〜３］及び［非特許文献１〜３］）の場合には、ＭＮ及びＨＡがすでに相互認証を確立しているので、ＨＡは暗黙にＭＮを信用し、そのため一括登録を受け入れることができる。しかし、この信用関係は、ＭＮが上記ＣｏＡを使用していることをＨＡが検証しないで、悪意のあるＭＮが、ＨＡ内にそのＣｏＡとしてビクティム（犠牲者）のアドレスをうまくバインドすることができることを意味する。アドレスがバインドされると、悪意のあるＭＮは、不必要なパケットをビクティムのアドレスに大量に流すことをＨＡに指示することにより再送信攻撃を行うことができる。

セルラのオペレータに関して、オペレータと加入との間の信頼関係の構築によって、オペレータは加入者にサービスを提供することが可能となる。例えば、ネットワークは、モバイルノードを操作しているユーザが本物の加入者であって、加入者の識別情報を盗んだ他の誰かではないと信用する。この本当の信用関係を強化するため、オペレータは、そのシステム内に認証、認可、及び課金処理（ＡＡＡ：Ａｕｔｈｅｎｔｉｃａｔｉｏｎ， Ａｕｔｈｏｒｉｚａｔｉｏｎ ａｎｄ Ａｃｃｏｕｎｔｉｎｇ）プロトコルを使用して、サービスを提供する前に加入者の認証を行う。さらに、オペレータと加入者とのビジネス契約によって、加入者は、オペレータから提供されるサービスを使用する場合には、オペレータによって規定された規則に従わなければならない。以降、こうしたビジネス契約を、契約条件と呼ぶことにする。加入者が不法に動作しているとオペレータが判断した場合には、オペレータは、契約条件を使用して、加入者へのサービスを終了することが可能である。以降、こうした加入者による不法な動作を、悪意のある動作と呼ぶことにする。

しかしながら、モバイルノード（ＭＮ）がセルラ・ネットワーク及びＷＬＡＮネットワークへ同時に接続する場合には、ＭＮは、一括登録を使用してセルラ・ネットワーク経由でＣｏＡ．ＷＬＡＮをバインドすることができる。例えば、ＭＮは、ホームに接続されたインタフェースを経由して、ソース・アドレスとしてＨｏＡが設定され、代替ＣｏＡとしてＣｏＡ．ＷＬＡＮが設定されたＢＵを送信することができる。セルラ・ネットワークでは既にＭＮがセルラシステムにおいて信用あるユーザと認証されているため、ＨＡはそのＢＵを受け入れ、ＭＮの有効なルートとしてＣｏＡ．ＷＬＡＮをバインドする。ＨＡによる信用によって、悪意のあるＭＮがビクティムのＣｏＡをバインドさせて再送信攻撃を実行できてしまう可能性がある。

上記問題の他に、すべてのノードは、バックボーン・インフラストラクチャが自身のパケットを正しく経路指定すると信じている。このことは、あるノードが他のノードからそのＣｏＡがソース・アドレスであると記述しているメッセージを受信した場合、受信ノードは、送信ノードの現在の位置でイングレス（ｉｎｇｒｅｓｓ）フィルタリングが行われたものとルーティング・インフラストラクチャを信用する。これにより、イングレス・フィルタリングにより、受信ノードは、入力パケットが実際にパケットが要求をしているネットワークからのものであることを確信することができる。さらに、受信ノードは、また、受信ノードによって受信されたパケットが、ルーティング・インフラストラクチャのルーティング処理によって目的の宛先に送信されたものと信用する。それ故、ルーティング・インフラストラクチャを信用しているノードにより、ソース・アドレスとして指定されたＣｏＡは受信ノードにより信用される。しかし、一括登録に対するバインディング更新で別のＣｏＡを使用すると、ＣｏＡはＢＵで指定される。それ故、送信ノードと受信ノードの間のこのような信頼関係は失われる。

それ故、本発明の１つの目的は、モバイルノードが一括登録の際に指定した特定の気付けアドレスを実際に使用していることを検証するために、一括登録を受信するすべてのノードのための方法を提供することである。

本発明は、ホーム・エージェントが、モバイルノードが要求したこれらのＣｏＡが実際にアドレスできることを検証しないで、モバイルノードが指定した別の気付けアドレス（ＣｏＡ）をバインドする場合に、一括登録中に生じた問題の解決方法を提供する。本発明のこの態様は、ホーム・エージェントが別のＣｏＡを検証する方法であり、そのため悪意のあるＭＮによる再送信攻撃に対して追加のセキュリティを提供する。

本発明の１つの好ましい実施の形態は、ホーム・エージェントが、マルチモード・ノードの一括バインディング更新（ＢＢＵ）メッセージ内のすべてのＣｏＡに未検証というタグを付けるステップを含むマルチモード・ノードのＢＢＵメッセージ内の複数のＣｏＡをホーム・エージェントが検証できるようにする方法を提供する。さらに、マルチモード・ノードのＣｏＡの検証方法は、ホーム・エージェントが、ソース・アドレスとして上記未検証ＣｏＡを含むマルチモード・ノードからのバインディング更新（ＢＵ）メッセージを受信する方法であってもよく、又は、ホームエージェントが、上記未検証ＣｏＡにホーム・エージェントから送信されたバインディング確認（ＢＡ：Ｂｉｎｄｉｎｇ Ａｃｋｎｏｗｌｅｄｇｍｅｎｔ）メッセージをマルチモード・ノードが受信したことを把握する方法であってもよい。

本発明の他の好ましい実施の形態は、ホーム・エージェントが、マルチモード・ノードが、上記マルチモード・ノード未検証ＣｏＡにホーム・エージェントが送信したバインディング確認（ＢＡ）メッセージを受信したか否かを知ることができるようにする方法を提供する。この方法は、ホーム・エージェントが、試験のためにマルチモード・ノードの第１及び第２の未検証ＣｏＡを選択するステップと、ホーム・エージェントが、上記第１の未検証ＣｏＡを通してマルチモード・ノードにバインディング確認（ＢＡ）メッセージを送信するステップを有し、確認メッセージが上記第２の未検証ＣｏＡによりホーム・エージェントに応答するようにとのマルチモード・ノードへの要求を含み、マルチモード・ノードが、ホーム・エージェントからのＢＡを受信した場合に、上記第２の未検証ＣｏＡにより、第２のＢＢＵでホーム・エージェントに応答し、ホーム・エージェントが、マルチモード・ノードから第２のＢＢＵを受信した後で、上記第１及び第２の未検証ＣｏＡ両方のアドレス可能性を検証する。

本発明のさらに他の好ましい実施の形態は、ホーム・エージェントが、マルチモード・ノードが、上記マルチモード・ノード未検証ＣｏＡにホーム・エージェントが送信したバインディング確認（ＢＡ）メッセージを受信したか否かを知ることができるようにする他の方法を提供する。この方法は、ホーム・エージェントが、試験のためにマルチモード・ノードの未検証ＣｏＡを選択するステップと、ホーム・エージェントが、上記未検証ＣｏＡを通してマルチモード・ノードにバインディング確認（ＢＡ）メッセージを送信するステップを有し、確認メッセージが、マルチモード・ノードが提案した最初の有効期間よりも短い有効期間を含み、そのためマルチモード・ノードに第２のＢＢＵメッセージを強制的に送信させ、マルチモード・ノードが、ホーム・エージェントからＢＡを受信した場合に、ホーム・エージェントと通信しているマルチモード・ノードＣｏＡのうちのいずれかにより、第２のＢＢＵでホーム・エージェントに応答し、ホーム・エージェントが、マルチモード・ノードから第２のＢＢＵを受信した後で、上記未検証ＣｏＡのアドレス可能性を検証する。

以下の説明においては、説明の目的で、本発明を完全に理解してもらうために特定の番号、時間、構造、プロトコル名、他のパラメータを記載する。しかし、当業者であれば、これらの特定の詳細を使用しなくても本発明を実行することができることを理解することができるだろう。他の例の場合、本発明を不必要に分かりにくくするのを避けるために、周知の構成要素及びモジュールをブロック図の形で示してある。

本発明は、マルチモード・ノードが指定する種々のルート経路を検証するために、一括登録をサポートする機能を有するモバイルＩＰｖ４又はモバイルＩＰｖ６適合ホーム・エージェント（ＨＡ）を含む。本発明の説明を分かり易くするために、以下の説明においては、「一括登録」という用語は、複数の気付けアドレスをバインディング更新（ＢＵ）メッセージの１つのホーム・アドレスにバインドするための方法を示すために使用する。本発明の場合、このＢＵメッセージは、以後、一括バインディング更新（ＢＢＵ）メッセージと呼ぶ。さらに、以下の説明においては、「マルチモード・ノード」という用語は、選択するためにいくつかのＩＰｖ４又はＩＰｖ６アドレスを有する任意のノード（ホスト又はルータ）を指すために使用する。このことは、ノードは、取り付けられるリンク上で広告される複数のプレフィックスを受信するか、同じリンク又は他のリンク上で選択するために複数のインタフェースを有する任意の組合せであってもよいことを意味する。

図１は、本発明の好適なシステムである。この好適なシステムの場合には、モバイルノード（ＭＮ）１０は、１つ又は複数の同じ又は異なるアクセス・システム１２上に、複数の気付けアドレス（ＣｏＡ）を有することができるマルチモード・ノードである。このような好適なシステムの場合には、アクセス・システム１２は、Ｗｉ−Ｆｉ、Ｂｌｕｅｔｏｏｔｈ又はセル方式であってもよいが、これらに限定されない。さらに、ＭＮ１０は、ワイド・エリア・ネットワーク（ＷＡＮ）１３を通してホーム・エージェント（ＨＡ）とメッセージを送受信する機能を有する。この好適なシステムの場合には、ＭＮ１０とＨＡ１１の間で交換したメッセージは、一括バインディング更新（ＢＢＵ）又はバインディング確認（ＢＡ）であってもよいが、これらに限定されない。本発明の場合には、ＢＢＵは、ＭＮ１０からＨＡ１１に送信され、それにより複数のＣｏＡをＭＮ１０の１つのホーム・アドレス（ＨｏＡ）にバインドすることができる。さらに、ＢＡはＨＡ１１からＭＮ１０に送信され、ＭＮ１０に最近のバインディング要求の状況を知らせる。

好適なシステムについて説明すると、ＭＮ１０とＨＡ１１の間で交換したメッセージは、さらに、ＭＮ１０とＨＡ１１の間に確立している１つ又は複数の双方向トンネル１４により確実に送信される。この好適なシステムのＭＮ１０とＨＡ１１の間の双方向トンネルを確立する手段は、インターネット・キー交換（ＩＫＥ）のような技術により達成することができるが、使用できる技術はこれに限定されない。この好適なシステムのＨＡ１１は、ホーム・ネットワークの外に出ている場合に、ＭＮ１０にパケットを転送することができるルータである。さらに、ＨＡ１１は、ＭＮ１０から受信するメッセージを処理する追加の機能を有する。好適なシステムの場合には、これらのメッセージは、ＭＮ１０が送信したＢＢＵであってもよいが、これに限定されない。

このような好適なシステムの場合には、ＭＮ１０は、プリンタ、パーソナル・コンピュータ、ルータ又は他の電子周辺機器であってもよいが、これらに限定されない。さらに、ＭＮ１０は、好適にはモバイルノード又は固定ノードとして実施することが好ましい。この好適なシステムの場合には、モバイルノード１０はＨＡ１１と通信している。しかし、当業者であれば、モバイルノード１０は、ＨＡ１１と通信しているモバイルルータであってもよいし、ＭＮ１０の任意の機能もモバイルルータに適用することができることを理解することができるだろう。

それ故、上記好適なシステムを含む本発明の１つの目的は、ＨＡ１１がＭＮ１０からの一括バインディング更新（ＢＢＵ）メッセージ内のＣｏＡを検証する手段を有することである。この好ましい実施の形態の場合には、ＨＡ１１は、ＭＮ１０から受信するすべてのＣｏＡに未検証のタグを付ける。ＨＡ１１のタグ付けのプロセスは、フラグをＨＡ１１のバインディングエントリ・キャッシュ内のＣｏＡと関連づけるＨＡ１１であってもよいが、これに限定されない。ＨＡ１１は、自身が上記ＣｏＡとして指定されたソース・アドレスを含むＭＮ１０からのバインディングメッセージを受信した場合、ＣｏＡを検証することができる。さらに、本発明の好ましい実施の形態の場合には、ＨＡ１１が、ＭＮ１０の未検証ＣｏＡを検証するための方法は、上記未検証ＣｏＡにＨＡ１１が第１のバインディングメッセージを送信し、ＭＮ１０から第２のバインディングメッセージを受信する方法である。未検証ＣｏＡに第１のバインディングメッセージを送信するＨＡ１１の目的は、ＨＡ１１に、ＭＮ１０が上記未検証ＣｏＡでアドレスできることをある程度確実にすることである。ＭＮ１０から第２のバインディングメッセージを受信すると、ＨＡ１１は、ＭＮ１０が第１のバインディングメッセージを正しく受信したことを知ることができる。それ故、ＨＡ１１は、ＭＮ１０が上記ＣｏＡでアドレスできることを検証することができる。この好ましい実施の形態で使用する第１のバインディングメッセージは、バインディング確認（ＢＡ）メッセージであってもよいが、これに限定されない。この好ましい実施の形態で使用する第２のバインディングメッセージは、一括バインディング更新（ＢＢＵ）メッセージ又はバインディング更新（ＢＵ）メッセージであってもよいが、これに限定されない。

本発明のシステムを使用することにより、ＨＡ１１は、一括登録中ＭＮ１０が指定する他のＣｏＡを検証するための簡単であるが効果的な機構を実質的に備える。図２は、１つ又は複数のネットワーク・インタフェース２０と、バインディングメッセージ・エンティティ２１と、バインディングエントリ・リスト２２と、ルート決定機能２３とを備えるこのようなホーム・エージェントの種々の好適な構成要素を示す。ネットワーク・インタフェース２０は、ある通信媒体を介して他のノードと通信するのに、ＨＡ１１が必要とするすべてのハードウェア及びソフトウェアを含む機能ブロックである。関連技術分野で周知の用語により、ネットワーク・インタフェース２０は、レイヤ１（物理層）及びレイヤ２（データ・リンク層）の通信構成要素、ファームウェア、ドライバ、及び通信プロトコルを示す。当業者であれば、ホーム・エージェントが、１つ又は複数のネットワーク・インタフェース２０を含むことができることを理解することができるだろう。

バインディングメッセージ・エンティティ２１は、ＨＡ１１のところで送受信するすべてのバインディングメッセージを処理する。１つの好ましい実施の形態の場合には、バインディングメッセージは、一括バインディング更新（ＢＢＵ）又はバインディング確認（ＢＡ）であってもよいが、これに限定されない。バインディングメッセージ・エンティティ２１により、ＨＡ１１は、任意のマルチモード・ノードから受信したＢＢＵメッセージを処理することができる。さらにバインディングメッセージ・エンティティ２１により、ＨＡ１１は、マルチモード・ノードのＢＢＵに応じてＢＡを生成することもできる。信号／データ経路２４により、バインディングメッセージ・エンティティ２１は、適当なネットワーク・インタフェース２０から／へパケットを送受信することができる。関連技術分野で周知の用語を使用して、バインディングメッセージ・エンティティ２１は、モバイルインターネット・プロトコル・バージョン４又は６のようなレイヤ３（ネットワーク層）プロトコルの実施態様を表す。

バインディングメッセージ・エンティティ２１のところで行うバインディングメッセージの処理を容易にするために、バインディングエントリ・リスト２２は、ＨＡ１１と通信している任意のマルチモード・ノードに関連する現在のバインディングを含む。可能である場合には、バインディングエントリ・リスト２２は、バインディングエントリのリストを含む。この場合、各バインディングエントリは、１つ又は複数のマルチモード・ノード・ホーム・アドレス（ＨｏＡ）への１つ又は複数のマルチモード・ノード気付けアドレス（ＣｏＡ）間の関係を指定する。この他に、各バインディングエントリに対して、現在のバインディングＣｏＡへ確実にアドレスできることを示すフラグが存在する。本発明の好ましい実施の形態の場合には、フラグは、関連するエントリ内の２つのビットを検証したＣｏＡの場合には「０１」に設定し、未検証ＣｏＡの場合には「１０」に設定し、又は未検証ＣｏＡの試験の場合（すなわち、未検証ＣｏＡを試験している期間）には「１１」に設定することにより表すことができる。しかし、設定はこれらに限定されない。信号／データ経路２５により、バインディングメッセージ・エンティティ２１は、バインディングエントリ・リスト２２内でエントリを更新し、バインディングエントリ・リスト２２からエントリを抽出することができる。

本発明は、ＨＡ１１が、ＣｏＡのアドレス可能性を試験するために、マルチモード・ノードバインディングエントリから未検証ＣｏＡを選択することができるようにする機構を提供するルート決定機能２３を導入する。この試験の目的は、マルチモード・ノードにより一括登録が行われた場合、ホーム・エージェントにマルチモード・ノードが指定したこれら他のＣｏＡにアドレスすることができることを確実にすることができるようにすることである。信号／データ経路２６により、バインディングメッセージ・エンティティ２１は、未検証ＣｏＡを含むバインディングエントリを、試験への未検証ＣｏＡを選択するためにルート決定機能２３に送ることができる。さらに、信号／データ経路２６により、ルート決定機能２３は、バインディングメッセージ・エンティティ２１にどの未検証ＣｏＡを試験するのかを知らせることができる。

ルート決定機能２３は、本発明を実現するための主要な機能を有している。ルート決定機能２３は、例えば各バインディングエントリに、未検証又は検証中のマークを付け、各アドレスの状態を管理するユニット、未検証のマークが付けられたバインディングエントリ内のアドレスのアドレス可能性を検証するユニット、ＨＡ１１がＭＮ１０からのパケットのソース・アドレスに使用されているアドレスの検証状態を検証済みに変更するユニット、ＭＮ１０へ送信されたパケットがＭＮ１０に到達したことを確実に把握した場合に、そのパケットの宛先アドレスに使用されているアドレスの検証状態を検証済みに変更するユニット、ＭＮ１０の未検証ＣｏＡを選択して、ＭＮ１０へのメッセージに埋め込まれた試験ＣｏＡオプションに選択されたＣｏＡを置くユニットなど、様々なユニットを有している。

一括登録は、マルチモード・ノードが別々に複数の気付けアドレスを登録する場合と比較して、１つのバインディング更新により複数の気付けアドレスをホーム・エージェントに登録するための最適化方法である。本発明の場合、この１つの統合バインディング更新を一括バインディング更新（ＢＢＵ）と呼ぶ。図３は、本発明の好ましい実施の形態による一括バインディング更新のメッセージ・フォーマットである。このメッセージ・フォーマットは、インターネットドラフト「複数のＣｏＡ性能の分析」（Ｍｕｌｔｉｐｌｅ ＣｏＡ Ｐｅｒｆｏｒｍａｎｃｅ Ａｎａｌｙｓｉｓ）［非特許文献３］に記載されているＢＢＵメッセージ・フォーマットに類似している。この実施の形態の場合には、ＢＢＵ３０は、ＩＰｖ６ヘッダ３１と、宛先オプション・ヘッダ３２と、モビリティヘッダ３３と、バインディング更新ヘッダ３４と、モビリティオプション３５とを含む。ＩＰｖ６ヘッダ３１は、パケットの最初の４０オクテット内に位置していて、ソース及び宛先アドレス（それぞれ１２８ビット）ならびにバージョン（４ビットＩＰバージョン）と、トラフィック・クラス（８ビット、パケット優先順位）と、フロー・ラベル（２０ビット、ＱｏＳ管理）と、ペイロード長（１６ビット）と、次のヘッダ（８ビット）と、ホップ制限（８ビット、生存時間）とを含む。ペイロードの大きさは、標準モードで最高６４ｋで、又は「ジャンボ・ペイロード」オプションを含む場合にはもっと大きい。オプションが存在する場合には、次のヘッダ・フィールドは、ＩＰｖ６ヘッダの後に続く余分なオプション・ヘッダの存在を指定する。

宛先オプション・ヘッダ３２は、パケットの宛先ノードによってだけチェックする必要があるオプションとしての情報を運ぶために使用される。この好ましい実施の形態の場合には、宛先オプション・ヘッダ３２は、ホームから遠いモバイルノードが受信者にモバイルノードのホーム・アドレスを知らせることができるようにするために使用するホーム・アドレスを有する。モビリティヘッダ３３は、バインディングの生成及び管理に関連するすべてのメッセージ通信の際に、モバイルノード、通信相手ノード及びホーム・エージェントが使用する拡張ヘッダである。モビリティヘッダ３３は、当該特定のモビリティメッセージを識別するモビリティヘッダ・タイプ（８ビット）を含む。本発明の好ましい実施の形態の場合には、モビリティヘッダ（ＭＨ：Mobility Header）タイプ値は５にセットされ、メッセージがバインディング更新（ＢＵ）メッセージであることを示す。

バインディング更新ヘッダ３４は、モバイルノードが他のノードにそれ自身に対する新しい気付けアドレスを知らせることができるようにするために必要な情報を有する。本発明の好ましい実施の形態の場合には、モビリティオプション３５は、ＢＵを送信するときに、モバイルノードが使用する１つ又は複数のバインディング一意識別子（ＢＵＩ）サブオプション３６を含む。本発明の好ましい実施の形態の場合には、モバイルノードは、１つのＢＵメッセージ内に１つ又は複数のバインディング一意識別子サブオプション３６を指定することができ、それによりモバイルノードは、ＢＵＩサブオプション３６にバインドすべきＣｏＡを挿入することによって一括登録を行うことができる。

ＨＡ１１が、ＭＮ１０から一括バインディング更新（ＢＢＵ）を受信した場合には、バインディングメッセージ・エンティティ２１は、ＢＢＵがＭＮ１０から送信されたことを確認するために認証手順を行う。この好ましい実施の形態の場合には、認証手順は、ＨＡ１１とＭＮ１０の間で前に交渉した予備共有キーの検証であってもよいが、これに限定されない。ＢＢＵを確認した場合には、バインディングメッセージ・エンティティ２１は、ＭＮ１０に対する現在のエントリがバインディングエントリ・リスト２２内に存在するか否かをチェックする。この好ましい実施の形態の場合には、チェック・プロセスは、ＢＢＵのソース・アドレスが、宛先オプション・ヘッダで指定したＨｏＡにすでにバインドしているか否かのチェックを含むことができるが、含むことができるものはこれに限定されない。さらに他の好ましい実施の形態の場合には、チェック・プロセスは、バインディング一意識別子サブオプション内のＣｏＡが、宛先オプション・ヘッダで指定したＨｏＡにすでにバインドしているか否かのチェックであってもよいが、これに限定されない。一実施の形態の場合には、エントリが存在する場合には、バインディングメッセージ・エンティティ２１は、自身が受信した新しいエントリで現在のエントリを更新する。一方、エントリが存在しない場合には、バインディングメッセージ・エンティティ２１は、新しいバインディングに対する新しいエントリを生成し、それをバインディングエントリ・リスト２２に格納する。

更新したか又は生成したエントリにより、バインディングメッセージ・エンティティ２１は、次に、最近のバインディングが、別のＣｏＡ又はＢＢＵのソース・アドレスで指定したＣｏＡに対するものか否かを判定する。一実施の形態の場合、バインディングが別のＣｏＡに対するものであった場合には、バインディングメッセージ・エンティティ２１は、バインディングエントリに未検証フラグを追加する。未検証フラグを追加する目的は、ＨＡ１１に、ＣｏＡがそのアドレス可能性について試験されていないことを知らせることである。この好ましい実施の形態の場合、未検証フラグは、関連するエントリ内の２つのビットを「１０」に設定することにより表すことができるが、表すことができる方法はこれに限定されない。一方、バインディングがＢＢＵのソース・アドレスで指定したＣｏＡに対するものである場合には、バインディングメッセージ・エンティティ２１は、バインディングエントリに検証フラグを追加する。検証済みフラグを追加する目的は、ＨＡ１１に、ＣｏＡがそのアドレス可能性について既に試験されたことを知らせることである。この好ましい実施の形態の場合には、検証済みフラグは、関連するエントリ内の２つのビットを「０１」に設定することにより表すことができるが、表すことができる方法はこれに限定されない。

１つのＣｏＡをバインディングした後で、バインディングメッセージ・エンティティ２１は、バインドすべきＣｏＡがもっとあるか否かを決定するためにＢＢＵをチェックする。この好ましい実施の形態の場合には、ＢＢＵのチェックは、別のバインディング一意識別子サブオプションがＢＢＵ内に存在するか否かの判定を含むことができるが、含むことができるものはこれに限定されない。１つの好ましい実施の形態の場合、処理すべきＢＢＵ内にもっと多くのＣｏＡが存在する場合には、バインディングメッセージ・エンティティ２１は、前の実施の形態のところで説明したステップにより残りのＣｏＡの処理を続行する。一括バインディング更新登録プロセスが終了すると、ＭＮ１０に対するバインディングエントリがバインディングエントリ・リスト２２に格納される。

図４は、本発明の好ましい実施の形態によるホーム・エージェントのところに格納しているマルチモード・ノードに対するバインディングエントリを示す。この好ましい実施の形態の場合には、バインディングエントリ４０は、ＨｏＡカラム４１、ＣｏＡカラム４２及びフラグ・カラム４３を有する。本発明の好ましい実施の形態の場合には、ＨｏＡカラム４１は、ＢＢＵ３０の宛先ヘッダ・オプション３２内に指定されたＭＮ１０のホーム・アドレスを含む。ＨｏＡは、ホーム・ドメインの外に出ている場合でも、ＭＮ１０と接続することができるように、１つ又は複数のＣｏＡとバインドされる。

ＣｏＡカラム４２は、ＭＮ１０が、バインディング更新手順中、そのＨｏＡにバインドするように指定した種々の気付けアドレスを含む。この好ましい実施の形態の場合には、ＣｏＡは、ＢＢＵ３０のソース・アドレス又はＢＵＩ３６内に位置するＣｏＡであってもよいが、これに限定されない。ＣｏＡにより、ＨＡ１１は、ホーム・ドメインと接続していない場合、ＭＮ１０宛のパケットを経路指定することができる。フラグ・カラム４３は、特定のＣｏＡがそのアドレス可能性について検証済みであるか否かを指定する。本発明によれば、ＭＮ１０への有効なルート経路として使用する前に、検証プロセスにより未検証ＣｏＡを検証する必要がある。本発明の好ましい実施の形態の場合には、検証済みＣｏＡの場合には関連エントリ内の２つのビットを「０１」に設定することにより、未検証ＣｏＡの場合には「１０」に設定することにより、又はＣｏＡの検証の場合（すなわち、検証中の場合）には「１１」に設定することにより表すことができるが、これに限定されない。

本発明の好ましい実施の形態によれば、ＢＢＵで指定したすべてのＣｏＡを処理し、バインディングエントリ・リスト２２に格納した場合には、バインディングメッセージ・エンティティ２１は、未検証ＣｏＡに対する検証プロセスを行うべきか否かを決定する。本発明の好ましい実施の形態の場合には、検証プロセスの決定は、ユーザがＢＢＵの受信中すべてのＣｏＡを検証したがっているか否かを決定するために、ＨＡ１１のところに格納しているユーザ・ポリシーからのチェックであってもよいが、これに限定されない。検証プロセスを行うと決定した場合には、バインディングメッセージ・エンティティ２１は、そのアドレス可能性を試験するために未検証ＣｏＡを選択するプロセスを行うためにルート決定機能２３をトリガする。一方、その時点で検証プロセスを行わないことを決定した場合には、バインディングメッセージ・エンティティ２１は、ＭＮ１０のバインディング状態を示すバインディング確認（ＢＡ）をＭＮ１０に送信することによりＢＢＵ登録プロセスを終了する。

ＣｏＡ検証プロセスは、ホーム・エージェントに、マルチモード・ノードが、その要求したＣｏＡ及びそのＨｏＡのところで実際にアドレスすることができるある妥当な確信を提供する。本発明の好ましい実施の形態の場合には、トリガは、ＨＡ１１がＣｏＡ検証プロセスをスタートすることができるようにする。この好ましい実施の形態の場合には、トリガは、ＨＡ１１が検証を直ちに処理することができるようにするＭＮ１０からのＢＢＵの受信である。検証を直ちに行った場合には、ＨＡ１１は、インタフェースを流れるトラフィックが予期せず切断した場合に、ＭＮ１０の検証済みＣｏＡのいずれかにトラフィックを再送信できるようになる。そのような場合には、ＭＮ１０のすべてのＣｏＡがトラフィックの円滑な再送信を行うことができるように確実に検証されるようにするほうがよい。

他の好ましい実施の形態の場合には、トリガは、ＭＮ１０への未検証ＣｏＡ経路を通るトラフィック・フローを送信するというＨＡ１１への要求であり、これによりＨＡ１１は、後の時点で検証を処理することができる。以後、本明細書においては、この検証方法を遅延検証と呼ぶ。この実施の形態の場合には、この要求は、ＭＮ１０がＨＡ１１のところでその種々のトラフィック・フローをフィルタリングする必要性であってもよいが、要求はこれに限定されない。以後、本明細書においては、このフィルタリング方法をフローフィルタリングと呼ぶ。遅延検証では、ＨＡ１１に上記未検証ＣｏＡを使用する前だけ、ＭＮ１０の未検証ＣｏＡを試験する手段を使用することができる。ＨＡ１１が複数のマルチモード・ノードと通信していて、すべてのマルチモード・ノードに対する一定の即時検証がＨＡ１１に過負荷になっている場合には、特にこのことが言えるし、ＨＡ１１の処理効率が低減する。

本発明の好ましい実施の形態の場合には、ＨＡ１１は、ＭＮ１０のＣｏＡの即時又は遅延検証を行うことができる。しかし、当業者であれば、マルチモード・ノードのあるものに対して即時検証を行い、他のマルチモード・ノードに対して遅延検証を行うためにＨＡ１１を使用することができることを理解することができるだろう。

さらに、１つのマルチモード・ノードが複数のＣｏＡを使用する場合には、ＨＡ１１はいくつかのＣｏＡに関して即座に検証を行うとともに、その他のＣｏＡに関しては遅れて検証を行うことができる。これにより、利用可能なＭＮ１０のＣｏＡをデータ・フロー（又は、フィルタ構成）の優先順位に基づいて選択することが可能となり、その結果、安定性及び即時性の両方を満たす検証が実現可能となる。

図５は、本発明の好ましい実施の形態によるマルチモード・ノードとホーム・エージェントの間で気付けアドレス検証プロセスを行うための好適な方法のシーケンス図である。この場合、ＭＮ１０は、３つのインタフェース、すなわちＭＮ．ＩＦ０ １０ａ、ＭＮ．ＩＦ１ １０ｂ、及びＭＮ．ＩＦ２ １０ｃを有し、これらのインタフェースは、それぞれ各１つのＣｏＡ、すなわちＣｏＡ１、ＣｏＡ２及びＣｏＡ３に関連する。ＭＮ１０は、ステップ５０において、ＭＮ．ＩＦ１ １０ｂを通してＨＡ１１に一括バインディング更新（ＢＢＵ）を送信する。ＢＢＵは、ソース・アドレス（ＣｏＡ２）、ホーム・アドレス・オプション（ＨＡＯ）内に位置するホーム・アドレス、及びそれぞれＭＮ．ＩＦ０ １０ａ及びＭＮ．ＩＦ２ １０ｃの別の気付けアドレスＣｏＡ１及びＣｏＡ３（ＡｌｔＣｏＡ１及びＡｌｔＣｏＡ３）を有する。ＨＡ１１がステップ５０からＢＢＵを受信すると、ＨＡ１１は、ＢＢＵがステップ５１においてＭＮ１０から送信されたことを確認する。この好ましい実施の形態の場合には、検証ステップは、認証手順及びＭＮ１０に対するバインディングエントリの更新又は生成からなる。確認プロセスに対する種々の実施ステップについては、前の実施の形態のところですでに説明した。

ＨＡ１１は、ＢＢＵを受信した場合、ＣｏＡ検証プロセスを行うことを決定し、そのため、試験のための未検証ＣｏＡの選択のためのバインディングメッセージ・エンティティ２１によりルート決定機能２３がトリガされる。この好ましい実施の形態の場合には、ルート決定機能２３は、各ＣｏＡの状態と一緒にＭＮ１０のＣｏＡを含むＭＮ１０のバインディングエントリをバインディングメッセージ・エンティティ２１から入手する。この好ましい実施の形態の場合には、各ＣｏＡの状態は、未検証状態であっても検証済み状態であってもよいが、これらに限定されない。ルート決定機能２３は、試験のために２つの未検証ＣｏＡ、すなわちＣｏＡ１及びＣｏＡ３を選択する。本発明の好ましい実施の形態の場合には、ＣｏＡ３を使用して応答を送信するようにとのＭＮ１０への要求を含む確認メッセージが、ＣｏＡ１に送信される。ルート決定機能２３は、トリガをＣｏＡ１及びＣｏＡ３を含むバインディングメッセージ・エンティティ２１に送信する。この好ましい実施の形態の場合には、トリガは、ルート決定機能２３がバインディングメッセージ・エンティティ２１にＣｏＡ１を介してＣｏＡ３を試験するように指示するものであってもよいが、これに限定されない。

バインディングメッセージ・エンティティ２１がトリガを受信すると、このエンティティは、ＣｏＡが試験中であることに気付き、ＭＮ１０のバインディングエントリを更新する。本発明の好ましい実施の形態の場合には、バインディングメッセージ・エンティティ２１は、ＣｏＡ１のフラグを未検証から検証中に変更する。バインディングメッセージ・エンティティ２１は、バインディング確認（ＢＡ）メッセージを生成し、ステップ５２において、それをＭＮ．ＩＦ０ １０ａに送信する。本発明の好ましい実施の形態によれば、ステップ５２で送信されるＢＡは、状態フィールドを有することができるが、有することができるものはこれに限定されない。状態フィールドは、ＭＮ１０がスタートした一括登録がＨＡ１１により受け入れられたか又は拒否されたかを示す。さらに、本発明の好ましい実施の形態の場合には、ステップ５２で送信されるＢＡはさらに試験ＣｏＡオプションを含むことができる。試験ＣｏＡオプションは、ＨＡ１１と通信しているマルチモード・ノードに対しての、ＨＡ１１が選択した上記ＣｏＡを介して応答するようにとの要求である。この例の場合には、ＨＡ１１が選択した上記ＣｏＡはＣｏＡ３である。この例の場合には、ＭＮ１０は、ＢＡメッセージ内の試験ＣｏＡオプションを知っていて、そのため、ＣｏＡ３を介してＨＡ１１に応答するものと仮定する。

この場合、ＭＮ１０は、受信したＢＡメッセージに試験ＣｏＡオプションが含まれているかをチェックする機能ユニット、試験ＣｏＡオプションによって指定されているＣｏＡに関連付けられているインタフェース経由でＨＡ１１へ要求メッセージを送信する機能ユニットを有するように変更される必要がある。

本発明の好ましい実施の形態の場合には、ステップ５２で送信されるＢＡは有効期間オプションを含むことができるが、含むことができるものはこれに限定されない。有効期間オプションは、ＨＡ１１と通信しているマルチモード・ノードに、バインディングが有効な期間を知らせる。本発明の好ましい実施の形態によれば、ＭＮ１０に対する特定のバインディングの有効期間が期限切れになろうとすると、ＭＮ１０は、上記特定のバインディングを更新するためにＨＡ１１にバインディングメッセージを送信する。さらに、ＭＮ１０に対する特定のバインディングの有効期間が期限切れになろうとすると、ＨＡ１１は、上記特定のバインディングを更新するために、それを知らせるＭＮ１０にバインディングリフレッシュ要求を送信する。

また、本発明の別の実施の形態によれば、ＨＡ１１は、ＭＮ１０が試験ＣｏＡオプションを理解する能力を有していない可能性がある。この実施の形態の場合には、ＨＡ１１は、指定の時間内にＭＮ１０からのバインディングメッセージを受信できなかった場合（これに限定されない）に、ＭＮ１０が試験ＣｏＡオプションを理解する能力を有していないことを知ることができる。さらに、この実施の形態の場合には、指定時間の設定は、ＢＡ５２を送信した場合、内部クロックを使用するタイマを設定するバインディングメッセージ・エンティティ２１であってもよいが、これに限定されない。このような好ましい実施の形態の場合には、ＨＡ１１は、一括登録中にＭＮ１０がスタートしたバインディングの有効期限を「Low（短期間）」に設定し、ＭＮ１０にＢＡ（ステップ５２で送信するＢＡ）を再送信する。有効期間を「Low」に設定する目的は、ＣｏＡ検証プロセスのために他のＢＢＵを送信するためにＭＮ１０をトリガすることである。有効期間を使用する利点は、試験ＣｏＡオプションを知るように修正されていないマルチモード・ノードが、同様にすでに説明したように、ＣｏＡ検証プロセスを実行することができるようになることである。このようなＣｏＡ検証方法は、［非特許文献１］にバインディングリフレッシュ要求（ＢＲＲ：Binding Refresh Request）方法と酷似している。

すでに説明したように、ＨＡ１１は、ＣｏＡ検証プロセスのために、試験ＣｏＡオプション又はバインディング確認（ＢＡ）メッセージと一緒に有効期間を使用することができる。しかし、当業者であれば、実施の際にこれら２つを１つにバインドすることができ、そのためＨＡ１１は、ＭＮ１０が新しいオプションを知っているか否かを知る必要がないことを理解することができるだろう。

ＢＡ内で、ホーム・エージェントが、試験ＣｏＡオプションと有効期間を一緒にバインドする目的は、マルチモード・ノードが試験ＣｏＡオプションを知っていてもいなくても、マルチモード・ノードがＢＡを受信するとすぐに、必ずマルチモード・ノードがホーム・エージェントに返答するようにすることである。例えば、本発明の好ましい実施の形態によれば、ＭＮ１０は、ステップ５２でＨＡ１１が送信したＢＡ内の試験ＣｏＡオプションを知らないことがある。この場合、ステップ５２で送信されるＢＡ内の状態フィールドは、バインディングが受け入れられたことを示しているので、ＭＮ１０は、ステップ５０でＨＡ１１が送信したＢＢＵ内のバインディングを受け入れたものと仮定し、試験ＣｏＡオプションで指定されているＣｏＡによりＨＡ１１に応答しない。ＨＡ１１は、ステップ５２におけるＢＡの送信の後で、ＭＮ１０のバインディングメッセージの受信のための指定時間を設定しているので、この時間は期限切れになり、そのためＨＡ１１は、次に、ＭＮ１０がステップ５２で送信されるＢＡ５２内の試験ＣｏＡオプションを理解できないことを知る。検証プロセスを再開するために、ＨＡ１１は、ＭＮ１０にＭＮ１０のバインディングの有効期間が期限切れになろうとしていることを知らせる他のバインディング確認を送信する。検証プロセス中のこの遅延は受け入れることができない。何故なら、未検証ＣｏＡ経路を通してのＭＮ１０へのトラフィック・フローの送信を遅延する恐れがあるからである。さらに、検証機構で起きた遅延は、ＨＡ１１にＭＮ１０宛のパケットを強制的に破棄させる恐れがある。何故なら、ＨＡ１１は、ＭＮ１０宛のこれ以上のパケットをバッファすることができないからである。一例を挙げて説明すると、ＭＮ１０は、通信相手ノード（ＣＮ）からのビデオ・フローが、本発明の好ましい実施の形態によれば未検証のＣｏＡ３を通じて発送されるように指定するフィルタをＨＡ１１に設定する。ＣＮからのビデオ・フローは、送信制御プロトコル（ＴＣＰ）のように信頼性及び順序の保証がないユーザ・データグラム・プロトコル（ＵＤＰ）をトランスポート・プロトコルとして使用して送信される。ＨＡ１１がビデオ・フローを受信した場合、ＨＡ１１はＣｏＡ３が現在検証されていないことを知り、ビデオ・フローをバッファしながら、ＭＮ１０により検証機構を実行する。しかし、ＭＮ１０がステップ５２で送信されるＢＡ内の試験ＣｏＡオプションを知ることができない場合には、これによりＣｏＡ３の検証に遅延が起こり、それによりＨＡ１１のバッファが満杯になる恐れがある。それ故、ＣＮから受信したＭＮ１０宛の入力パケットは、破棄されるパケットになる。何故ならＣｏＡ３が検証される前に、ＨＡ１１用のバッファが満杯になるからである。

ＭＮ１０がＨＡ１１からステップ５２で送信されたＢＡを受信すると、ＭＮ１０はステップ５３においてＢＡを処理する。ＭＮ１０は、試験ＣｏＡオプションから、ＭＮ．ＩＦ２ １０ｃを介してＨＡ１１に応答を送信するようにＨＡ１１がＭＮ１０に要求していることを知る。さらに、ＭＮ１０は、また、その現在のバインディングに対する有効期限が時間切れになりつつあり、ＨＡ１１にもう１つの一括バインディング更新を送信するように要求していることを識別する。ＭＮ１０は、ステップ５４において、ＭＮ．ＩＦ２ １０ｃを通してＨＡ１１に一括バインディング更新（ＢＢＵ）を送信する。この好ましい実施の形態の場合には、ＢＢＵは、ソース・アドレス（ＣｏＡ３）と、ホーム・アドレス・オプション（ＨＡＯ）内に位置するホーム・アドレスと、それぞれＭＮ．ＩＦ０ １０ａ及びＭＮ．ＩＦ１ １０ｂの別の気付けアドレスＣｏＡ１及びＣｏＡ２（ＡｌｔＣｏＡ１及びＡｌｔＣｏＡ２）とを有する。ＨＡ１１がステップ５４からＢＢＵを受信すると、ＨＡ１１は、ＢＢＵがステップ５５においてＭＮ１０から送信されたことを確認する。この好ましい実施の形態の場合には、確認ステップは、認証手順及びＭＮ１０に対するバインディングエントリの更新又は生成からなる。確認プロセスに対する種々の実施ステップについては、前の実施の形態のところですでに説明した。

バインディングメッセージ・エンティティ２１は、ＢＢＵをＣｏＡ３から受信したことに気付き、それ故、バインディングエントリ・リスト２２内のＭＮ１０のバインディングエントリを更新する。ＭＮ１０のバインディングエントリの更新は、バインディングメッセージ・エンティティ２１が、ＣｏＡ３のフラグを未検証から検証済みに変更したことを意味する。さらに、ＭＮ１０バインディングエントリの更新は、また、バインディングメッセージ・エンティティ２１にＣｏＡ１のフラグの検証中から検証済みへの変更を行えるようにしてもよい。何故なら、バインディングメッセージ・エンティティ２１は、ＭＮ１０が試験メッセージへのその要求に応答したこと、すなわち、ＭＮ１０がＣｏＡ１に送信されたＢＡに応答したことを知っているからである。ＭＮ１０バインディングエントリから、バインディングメッセージ・エンティティ２１は、すべてのバインディングが検証され、そのためＣｏＡ検証プロセスが終了したことを検出する。本発明の好ましい実施の形態の場合には、バインディングメッセージ・エンティティ２１は、最後のバインディング確認を生成し、ステップ５６においてそれをＭＮ１０に送信する。この好ましい実施の形態の場合には、ステップ５６で送信されるＢＡ５６は、状態フィールド及び有効期間フィールドを有することができるが、これらに限定されない。本発明の好ましい実施の形態によれば、ＢＡ５６は、ＭＮ１０が記述したように、バインディングの要求した有効期間によりすべてのバインディングの登録が成功したことをＭＮ１０に知らせる。

ＣｏＡ検証プロセスの他の好ましい実施の形態の場合には、ＭＮ１０は、ＨＡ１１を介して送信される試験ＣｏＡメッセージを理解できるように変更されていない。しかし、ＭＮ１０の一括バインディングの有効期間が「Low」に設定されているので、ＭＮ１０は、その前のＢＢＵ内に指定されているそのＣｏＡを登録するために他のＢＢＵをＨＡ１１に送信する。この実施の形態の場合には、ＭＮ１０は、この場合にはＣｏＡ２であるＨＡ１１ですでに検証されたＣｏＡを有するインタフェースを介してＢＢＵを送信すると仮定する。ＨＡ１１はＢＢＵを受信するので、このことは、ＭＮ１０が、ＨＡ１１がＣｏＡ１にすでに送信したＢＡを受信し、そのためＣｏＡ１を検証することができることを意味する。この好ましい実施の形態の場合には、バインディングメッセージ・エンティティ２１は、それに従って、バインディングエントリ・リスト２２のところに格納しているＭＮ１０のバインディングエントリでＣｏＡ１のフラグを検証中から検証済みに変更する。次に、ＨＡ１１は、ＣｏＡ３を、それがこの好ましい実施の形態に記述された最後の残りの未検証エントリとして検証するために、ＣｏＡ検証プロセスを続行する。

さらに別の好ましい実施の形態では、ＨＡ１１におけるＭＮ１０の各ＣｏＡバインディングエントリが、ＨＡ１１のバインディングエントリ・リスト２２内の固有のバインディング識別子として反映される。こうした固有のバインディング識別子は、［非特許文献２］に記載されているバインディング識別子（ＢＩＤ）と同一であってもよい。これにより、ＨＡ１１は、ＨＡ１１のバインディングエントリ・リスト２２内の各ＣｏＡバインディングの状態を示すバインディングメッセージを、ＭＮ１０へ送信することが可能となる。このようなバインディングメッセージは、バインディング応答メッセージ又はバインディングリフレッシュ要求メッセージであってもよいが、これに限定されるものではない。状態を示すために、バインディングメッセージには、バインディング固有識別子（ＢＵＩ）オプションとして各ＢＩＤエントリが反映される。さらに、各ＢＵＩオプションにはフラグが関連付けられており、これによって、ＨＡ１１は、ＨＡ１１のバインディングエントリ・リスト２２内の各ＣｏＡバインディングエントリの状態をＭＮ１０に示すことが可能となる。こうした情報によって、ＭＮ１０は、ＨＡ１１におけるどのＣｏＡエントリが既に検証されているかを把握し、未検証ＣｏＡ経路を通じて、データパケットをＨＡへ送信するよう選択することが可能となる。これにより、ＨＡ１１は、バインディングエントリ・リスト２２内のＭＮ１０のバインディングエントリを更新して、検証済みとなるように反映することが可能となる。

より明確にこの方法を提示するために、以下の例について説明する。図５において、ＨＡ１１は、ＢＢＵ２０をＭＮ１０から受信する（ステップ５０において）。ＢＢＵ３０において、ＭＮ１０は、各ＣｏＡを固有のＢＩＤに関連付ける。例えば、ＣｏＡ１はＢＩＤ１に関連付けられ、ＣｏＡ２はＢＩＤ２に関連付けられ、ＣｏＡはＢＩＤ３に関連付けられる。この実施の形態では、ＨＡ１１は、遅延検証方法を実行している。したがって、ＨＡ１１は、バインディング応答メッセージをＭＮ１０へ送信し、ＭＮ１０の各バインディングの状態を示すフラグを使用する（ステップ５２において）。例えば、ＨＡ１１は、ＢＡにおいて、ＢＩＤ１が検証済みであり、ＢＩＤ２及びＢＩＤ３が未検証であることを示す。好ましい実施の形態では、フラグは、関連するエントリ内の２ビットを、検証済みＣｏＡの場合には‘０１’、未検証ＣｏＡの場合には‘１０’、あるいは、未検証ＣｏＡを試験している場合（すなわち、未検証ＣｏＡを試験している期間）には‘１１’と設定することで表されてもよいが、これに限定されるものではない。ＭＮ１０においてＢＡを受信すると、ＭＮ１０は、ＨＡ１１におけるＣｏＡバインディングのそれぞれの状態を把握する。これにより、ＭＮ１０がＨＡ１１におけるＢＩＤ２の状態を“検証済み”に変更したいならば、ＭＮ１０はＣｏＡ２経由でデータパケットをＨＡ１１へ送信する。このような動作によって、ＨＡ１１は、ＭＮ１０がＣｏＡ２によってアドレス可能であることを検証することが可能となる。

図６は、本発明の好ましい実施の形態のホーム・エージェントのところのＣｏＡバインディングの状態図である。この好ましい実施の形態の場合には、ＨＡ１１は、そのバインディングエントリ・リスト２２内の３つの状態、すなわち未検証状態６０、検証済み状態６１及び検証中状態６２を有する。未検証状態６０は、ＣｏＡエントリがそのアドレス可能性について試験されていないことを示すエントリの状態である。本発明の好ましい実施の形態の場合には、この状態にあるエントリに対して、ＨＡ１１は、その特定のルート経路が検証されるまで、試験していないＣｏＡを通してＭＮ１０に関するいかなるパケットも経路指定しない。バインディングメッセージ・エンティティ２１が未検証ＣｏＡを試験するようにとの指示を受信すると、このエンティティは、前の実施の形態のところで説明したように、ＣｏＡ検証プロセスを続行する。本発明の好ましい実施の形態の場合には、これによりＣｏＡ試験６３信号がトリガされ、ＣｏＡエントリの状態が未検証状態６０から検証中状態６２に変化する。さらに、検証状態６２でＣｏＡエントリに対するＣｏＡ検証プロセスが終了すると、このことによりＣｏＡ試験済み６４信号がトリガされ、ＣｏＡエントリの状態が検証中状態６２から検証済み状態６１へ変化する。

そのアドレス可能性についての試験が終了していないＣｏＡエントリは、未検証状態６０になる。しかし、ＭＮ１０が、そのＣｏＡエントリと同様のソース・アドレスでＢＢＵ又はＢＵを送信する場合には、このことはそのアドレス可能性について特定のＣｏＡの試験が行われたことを意味する。本発明の好ましい実施の形態の場合には、これによりＣｏＡ試験済み６７信号がトリガされ、ＣｏＡエントリの状態は未検証状態６０から検証済み状態６１に変化する。

検証中状態６２は、ＣｏＡがそのアドレス可能性について現在試験中であることを示すエントリの状態である。本発明の好ましい実施の形態の場合には、ＣｏＡエントリに対して、現在、前の実施の形態のところで説明したように、ＣｏＡ検証プロセスのステップが行われている。ＣｏＡエントリが現在検証中状態６２であり、このエントリがそのアドレス可能性を検証するのに失敗した場合には、ＣｏＡは、アドレス不能と見なされる。本発明の好ましい実施の形態の場合には、これによりＣｏＡ試験失敗６５信号がトリガされ、その特定のバインディングのＣｏＡエントリの状態は検証中状態６２から未検証状態６０に変化する。

検証済み状態６１は、ＣｏＡのアドレス信頼性が試験済みであることを示すエントリの状態である。ＢＢＵ又はＢＵのソース・アドレスに含まれているＣｏＡは、そのエントリを自動的に検証済み状態６１にする。検証済み状態６１で指定したＣｏＡエントリを記述しているＢＵＩを含むＢＢＵがＨＡ１１により受信された場合、このことはＭＮ１０が特定のＣｏＡに対して一括登録を行っていることを意味する。これにより、新しいＡｌｔＣｏＡエントリ６６信号がトリガされ、その特定のバインディングのＣｏＡエントリの状態が検証済み状態６１から未検証状態６０に変化する。

ＣｏＡ検証プロセスの他の好ましい実施の形態の場合には、このトリガは、未検証ＣｏＡ経路を通してＭＮ１０にトラフィック・フローを送信するというＨＡ１１への要求である。ＭＮ１０は、ＨＡ１１のところで能動フローフィルタ・パラメータを設定し、これによりＨＡ１１はＭＮ１０が生成したフィルタを介してＭＮ１０宛のトラフィックを経路指定することができる。フィルタは、１つ又は複数のＭＮ１０ＣｏＡへのフローパラメータのバインディングを示す。さらに、フローパラメータは、通信相手ノード・ソース・アドレス又はポート番号であってもよいが、これに限定されない。ＨＡ１１がＭＮ１０宛のフローを受信すると、ＨＡ１１はＭＮ１０に対して定義されたフィルタに対してフローパラメータをチェックする。ＨＡ１１は、ＭＮ１０が未検証ＣｏＡを通してフローを経路指定するように指定したことを識別し、特定のＣｏＡルート経路を通してフローを送信する前に、そのアドレス可能性についてＣｏＡを試験するようにＣｏＡ検証プロセスをトリガする。ＨＡ１１は、前の実施の形態のところで説明した本発明のＣｏＡ検証プロセスを使用することができる。当業者であれば、ＨＡ１１は、上記未検証ＣｏＡのそのアドレス可能性を試験するために、ＭＮ１０の未検証ＣｏＡへのＩＣＭＰエコー要求パケットの送信のような到達性を試験するために他のメッセージを使用することができることを理解することができるだろう。ＨＡ１１が、ＭＮ１０から上記ＣｏＡと一緒にＩＣＭＰエコー応答パケットを受信すると、アドレス可能性についての試験が終了し、ＨＡ１１は上記ＣｏＡ経路を通してフローを経路指定することができる。

さらに、本発明の別の好ましい実施の形態において、ＨＡ１１が実行する検証方法をセルラ・シナリオ（例えば、３ＧＰＰネットワーク）に適用することが可能である。図７は、本発明の別の好ましい実施の形態における別の好ましいシステムを例示する図である。このシステムでは、ＭＮ１０はセルラのオペレータの加入者であり、セルラのオペレータはＭＮ１０にモビリティ・サービスを提供する。したがって、オペレータのセルラ・ネットワーク７０内に位置するＨＡ１１は、ＭＮ１０に関するすべてのモビリティ関連シグナリングの処理を行う。ＭＮ１０は、ＭＮ１０のホーム・ネットワークであるセルラ・ネットワーク７０に経路７２を通じて接続されているセルラ・インタフェース７９ａを有している。セルラ・インタフェース７９ａは、通信にホーム・アドレス（ＨｏＡ）を使用している。同時に、ＭＮ１０は経路７３を通じてＷＬＡＮ７１に接続されているＷＬＡＮインタフェース７９ｂを有している。ＷＬＡＮ７１はオペレータのネットワークの一部ではないので、オペレータにとっては、ＷＬＡＮ７１は外部（ｆｏｒｅｉｇｎ）ネットワークである。ＷＬＡＮインタフェース７９ｂは、通信に気付けアドレス（ＣｏＡ．ＷＬＡＮ）を使用している。ＭＮ１０は、従来の技術に記載されている方法を実行して、通信に両方のインタフェースを使用する。このように、ＨＡ１１はＭＮ１０に関して２つのバインディングエントリを有している。第１のバインディングエントリには、経路７３経由でＭＮ１０のＨｏＡへパケットをルーティングする情報が含まれている。第２のバインディングエントリには、経路７５経由でＭＮ１０のＣｏＡへパケットをルーティングする情報が含まれている。第２のバインディングエントリに関しては、ＨＡ１１は経路７４を通じてＷＡＮ１３へパケットを発送し、その後、パケットはＷＡＮ１３で経路７５を経由してＷＬＡＮ７１へ発送される。

図７において、ＭＮ１０は、一括登録を用い、セルラ・インタフェース７９ａを通じてＨＡ１１へＢＢＵ３０を送信することができる。この実施の形態に関して、ＢＢＵには、ＩＰｖ６ヘッダ３１のソース・アドレスとしてＨｏＡが含まれ、ＢＵＩオプション３６にＣｏＡ．ＷＬＡＮが含まれていてもよいが、これに限定されない。セルラ・ネットワーク７０とＭＮ１０との間に信用関係が構築されているので、ＨＡ１１はＢＢＵ３０の真正性を信用し、ＭＮ１０への検証済みルーティング経路として、ＣｏＡ．ＷＬＡＮをバインドする。この動作によって、悪意のある加入者がこのシステムに再送信攻撃を実行できる可能性がある。このように、オペレータが加入者を誤って信用してしまう可能性があるので、一括登録の使用が、セルラのオペレータにとって望ましい特徴とならないかもしれない。

しかしながら、モバイルノードとホーム・エージェントとの間におけるモビリティ・シグナリングを最適化する場合の一括登録の利点は、加入者に提供されるモビリティ・サービスを拡張するためにセルラのオペレータが求める望ましい特徴である。例えば、ＭＮ１０は、ファスト・モバイルＩＰ（ＦＭＩＰ）などの技術を使用して、ＭＮ１０の移動先の第２のＷＬＡＮからＣｏＡを取得することができる。通常、ＭＮ１０がＨＡ１１にＣｏＡをバインドするためには、ＢＵがＨＡ１１へ送信可能となる前に、まずＷＬＡＮインタフェース７９ｂがきちんと第２のＷＬＡＮに接続する必要がある。接続に要する時間が予想よりも長くなってしまうような場合が起こることもあり、これによって、モビリティ・シグナリング・メッセージ（例えば、ＢＵ）の送出に遅延が生じる場合もあり得る。セルラのオペレータは移動中の加入者が受ける遅延量を低減しようとした場合、一括登録は、その解決策の候補となり得る。上述の例において、ＭＮ１０は以下一括登録を使用してセルラ・インタフェース７９ａを通じてＢＵを送信し、ＦＭＩＰを用いて取得したＣｏＡをバインドすることができる。この処理によって、ＭＮ１０が受けるシグナリング遅延量は低減される。

したがって、加入者とオペレータとの間の信用関係を強め、オペレータの誤信を防ぐために、オペレータは、バインディング前にＢＢＵ内に記載されているアドレスを検証するポリシをホーム・エージェントにおいて実行する。したがって、セルラのオペレータは本発明の方法を使用して、ホーム・エージェントが、モバイルノードへのルート経路をバインドする前に、ＢＢＵ内に記載されているアドレスを検証できるようにすることが可能である。さらに、本発明の別の好ましい実施の形態において、セルラのオペレータが、ＢＢＵ内に記載されているアドレスがセルラのオペレータによって信用されているプレフィックスから構成されていない場合にのみ、本発明の検証方法を行うというポリシをホーム・エージェントにおいて実行することが可能である。

図８には、本発明の好ましい実施の形態において、検証処理が必要かどうかをホーム・エージェントが判断する好ましい方法を示すフローチャートが明示されている。ＨＡ１１がＭＮ１０からバインディング更新（ＢＵ）メッセージを受信した場合に、処理が開始される（ステップＳ８０）。これによって、ＨＡ１１は、ＢＵがＭＮ１０に関する複数のＣｏＡをバインドするためのものかどうか（例えば、ＢＵが一括登録ＢＵかどうか）のチェックを行う（ステップＳ８１）。ＢＵにバインディングのために単一のＣｏＡが含まれているのであれば、ＨＡ１１は、引き続きＭＮ１０に関するバインディングエントリとしてＣｏＡを格納する処理を行い、そのエントリの状態を検証済みとしてマークする（ステップＳ８２）。エントリがマークされた状態で、ＨＡ１１はこの判断処理を終了し（ステップＳ８８）、この処理を再びトリガする別のＢＵを待機する。

しかしながら、ＢＵにバインディングのために複数のＣｏＡが含まれている場合には、ＨＡ１１はそのＣｏＡが検証される必要があるかどうかをチェックする処理を開始する。ＨＡ１１は、ＢＵ内のＣｏＡ群から１つのアドレスを選択し（ステップＳ８３）、選択されたＣｏＡがセルラのオペレータによって信用されているプレフィックスから構成されているかどうかを判断する（ステップＳ８４）。選択されたＣｏＡが信用されているプレフィックスから構成されているのであれば、ＨＡ１１は、引き続きＭＮ１０に関するバインディングエントリとして、選択されたＣｏＡを格納し、そのエントリの状態を検証済みとしてマークする（ステップＳ８５）。このステップ（ステップＳ８５）に関して、下記の例を参照しながら詳細に説明する。

ＭＮ１０が、ＧＰＲＳ（Ｇｅｎｅｒａｌ Ｐａｃｋｅｔ Ｒａｄｉｏ Ｓｗｉｔｃｈ）インタフェースと呼ばれる第３のインタフェースを有していると仮定する。ＧＰＲＳインタフェースは、セルラ・ネットワーク７０のオペレータによって所有されているＧＰＲＳネットワークに接続されている。ＭＮ１０は、セルラのオペレータから報知された信用されているプレフィックスを使用して、ＧＰＲＳインタフェース経由の通信のための気付けアドレス（ＣｏＡ．ＧＰＲＳ）を構成する。ＧＰＲＳインタフェースはアップ・リンクのために有限量の帯域幅を有しているので、ＭＮ１０は、一括登録を使用してセルラ・インタフェース７９ａを通じてＨＡ１１にＣｏＡ．ＧＰＲＳをバインドすることを決める。ＨＡ１１がＭＮ１０からＢＵを受信すると、ＨＡ１１は、ＣｏＡ．ＧＰＲＳがセルラのオペレータの信用されているプレフィックスから構成されていることを特定する。したがって、ＨＡ１１は、上述の実施の形態に基づいた検証方法を実行せずに、ＭＮ１０への検証済みルート経路としてＣｏＡ．ＧＰＲＳをバインドする。

選択されたＣｏＡがセルラのオペレータによって信用されているプレフィックスから構成されていない場合には、ＨＡ１１は、選択されたＣｏＡをＭＮ１０に関するバインディングエントリとして格納する処理を行い、そのエントリの状態を未検証としてマークする（ステップＳ８６）。このステップ（ステップＳ８６）に関して、下記の例を参照しながら詳細に説明する。ＭＮ１０が、一括登録を使用して、セルラ・インタフェースを通じてＨＡ１１にＣｏＡ．ＷＬＡＮをバインドすると仮定する。ＨＡ１１がＭＮ１０からＢＵを受信すると、ＨＡ１１は、ＣｏＡ．ＷＬＡＮがセルラのオペレータによって信用されているプレフィックスから構成されていないことを特定する。したがって、ＨＡ１１はＭＮへの未検証ルート経路としてＣｏＡ．ＷＬＡＮをバインドする。ある実施の形態では、ＣｏＡ．ＷＬＡＮの到達可能性を検証するために使用される方法として、ＨＡ１１が、ＭＮ１０へＣｏＡ．ＷＬＡＮ経由で返答するよう求めるバインディング応答（ＢＡ）をＭＮ１０へ送信する方法が望ましいかもしれない。ＨＡ１１がＣｏＡ．ＷＬＡＮを通じてＭＮ１０からのパケットを受信すると、ＨＡ１１は、そのバインディングエントリにＣｏＡ．ＷＬＡＮルート経路が現在検証されていることをマークする。本発明のさらに別の好ましい実施の形態では、ＣｏＡ．ＷＬＡＮの到達可能性を検証するために使用される方法として、ＨＡ１１がＩＣＭＰ（Ｉｎｔｅｒｎｅｔ Ｃｏｎｔｒｏｌ Ｍｅｓｓａｇｉｎｇ Ｐｒｏｔｏｃｏｌ）エコー要求メッセージをＣｏＡ．ＷＬＡＮへ送信する方法が望ましいかもしれない。これによって、ＭＮ１０は、ＣｏＡ．ＷＬＡＮを通じてＩＣＭＰエコー応答を送信することを強制される。その結果、ＨＡ１１は、ＭＮ１０がＣｏＡ．ＷＬＡＮ経由で到達可能であることを検証でき、そのバインディングエントリにＣｏＡ．ＷＬＡＮルート検証が検証されていることをマークする。

選択されたＣｏＡがＨＡ１１におけるバインディングエントリに格納された場合には、ＨＡ１１における決定処理は、処理すべきＣｏＡがＢＵ内に存在するかどうかをチェックすることによって引き続き行われる。処理すべき別のＣｏＡが残っている場合には、ＨＡ１１はステップＳ８３からの処理を繰り返し行って、ＭＮ１０に関する各ＣｏＡバインディングの状態を決定する。ＢＵに関して処理すべきＣｏＡが存在しなくなったならば、ＨＡ１１はこの決定処理を終了する（ステップＳ８８）。

本発明のさらに別の好ましい実施の形態では、セルラ・ネットワーク７０は、さらに、パケット・データ・ゲートウェイ（ＰＤＧ：ｐａｃｋｅｔ ｄａｔａ ｇａｔｅｗａｙ）有することができる。ＰＤＧの目的は、モバイルノードがＷＬＡＮ７１からセルラ・ネットワーク７０へアクセスできるようにすることにある。したがって、ＰＤＧは、ＭＮ１０がＷＬＡＮ７１を通じてセルラ・ネットワーク７０へアクセスできるようにするためのゲートウェイとして機能する。このように、経路７４は、この実施の形態ではＰＤＧへ接続される。例えば、ＭＮ１０はＷＬＡＮインタフェース７９ｂを使用して、セルラ・ネットワーク７０へのアクセスを得ようとする。したがって、ＷＬＡＮインタフェース１０ｂはＷＡＮ１３経由でＰＤＧと通信し、ＭＮ１０に関する認証データと共にＷＬＡＮ７１で構成されたアドレスを提示する。ＭＮ１０がセルラのオペレータの有効な加入者であるかどうかを認証するため、ＰＤＧは、セルラ・ネットワーク７０に位置するＡＡＡサーバに連絡を取る。認証された場合には、アドレスがＭＮ１０に割り当てられる。そのアドレスはＷＬＡＮインタフェース７９ｂがセルラ・ネットワーク７０で使用するために（ＨｏＡ．ＷＬＡＮ）、セルラ・ネットワーク７０において構成されてもよい。ある実施の形態では、ステートレス自動構成を用いてＨｏＡ．ＷＬＡＮを割り当てることができる。ＭＮ１０にセルラ・ネットワーク・プレフィックスを報知するようＰＤＧに依頼することによって、これを実現することができる。また、別の好ましい実施の形態では、ステートフル構成を用いてＨｏＡ．ＷＬＡＮを割り当てることができる。ＭＮ１０の割り当てられたアドレスをＰＤＧに通知するよう動的ホスト構成プロトコル（ＤＨＣＰ：Ｄｙｎａｍｉｃ Ｈｏｓｔ Ｃｏｎｆｉｇｕｒａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）サーバに依頼することによって、これを実現することができる。ＨＯＡ．ＷＬＡＮを把握することで、ＰＤＧはＨｏＡ．ＷＬＡＮをＣｏＡ．ＷＬＡＮにマッピングする。このマッピングによって、ＰＤＧは、ＭＮ１０に関してセルラ・ネットワーク７０内でアドレス変換を行えるようになる。さらに、ＰＤＧは、ＨＡ１１においてＨｏＡ．ＷＬＡＮをバインドする。これによって、ＰＤＧはＭＮ１０の代わりのプロキシとして動作可能となる。ＨｏＡ．ＷＬＡＮ宛のパケットはＨＡ１１からＰＤＧへ転送され、ＰＤＧは、ＣｏＡ．ＷＬＡＮ経由でＭＮ１０へパケットを転送する。

更なる好ましい実施の形態では、ＭＮ１０は、ＰＤＧ経由でＨｏＡ．ＷＬＡＮがＭＮ１０に割り当てられていたとしても、ＨＡ１１においてＣｏＡ．ＷＬＡＮをバインドしようとしてもよい。この実施の形態では、ＨＡ１１が本発明の検証方法を利用して、ＭＮ１０のＣｏＡ．ＷＬＡＮに関する到達可能性を検証してもよい。

本発明が詳細に説明されているので、当業者は、本発明が［非特許文献４］に記載されている方法とは異なっていることを理解するだろう。［非特許文献４］では、通信相手（例えば、ホーム・エージェント）は、ＣｏＡが検証されるまで、モバイルノード（ＭＮ）のバインディングキャッシュエントリ（ＢＣＥ）を無効化する。ホーム・エージェント（ＨＡ）がＭＮに関するＢＣＥを、複数のＣｏＡにバインドされたホーム・アドレス（ＨｏＡ）を含む単一のエントリとして実装している場合には、ＢＣＥを無効化することによって、ＨＡがＭＮへパケットを発送しようとする場合に問題が生じる。これは、到達可能性の検証が既に行われているＣｏＡも無効化されてしまうことによる。したがって、これは、ＨＡによる検証処理の間は、ＭＮが既に検証済みのＣｏＡでさえもパケットを受信できなくなることを意味している。本発明は、ＨＡが、ＭＮの各エントリを独立したエントリとして取り扱うようにＢＣＥを実装させることによって、この問題を解消する。ＨＡがＭＮの各エントリが個人出場者として扱われる方法でＢＣＥを実行するのを確実にすることによって、現在の発明はこの問題を克服する。このように、各エントリに関する状態は、それぞれ独立して存在する。

さらに、当業者は、本発明におけるＣｏＡの検証が［非特許文献５］に記載されている方法とは異なっていることを認めるであろう。［非特許文献５］において、ＣｏＡの検証方法は、通信相手ノードがＩＣＭＰ（Ｉｎｔｅｒｎｅｔ Ｃｏｎｔｒｏｌ Ｍｅｓｓａｇｉｎｇ Ｐｒｏｔｏｃｏｌ：インターネット制御メッセージングプロトコル）エコー要求をモバイルノード（ＭＮ）のＣｏＡへ送信するものである。ＣＮがＣｏＡ経由でＭＮから返答を受信した場合には、ＣＮは、ＭＮのＣｏＡが到達可能であることを確認する。これは、所定数のＭＮのＣｏＡを検証するために、ＣＮがその数だけＩＣＭＰエコー要求メッセージを送信しなければならないことを意味している。例えば、ＭＮが３つの未検証ＣｏＡを持っている場合には、ＣＮは、ＭＮのＣｏＡをすべて検証するために、３つのＩＣＭＰエコー要求及び応答メッセージを送受信する必要がある。しかしながら、本発明の検証方法では、別の未検証ＣｏＡを経由して返答を行うようＭＮに依頼することによって、メッセージ交換数が低減される。例えば、ＨＡは、未検証ＣｏＡの１つを経由してＭＮへメッセージを送信し、別の未検証ＣｏＡを経由してＭＮへ返答するよう依頼する。この処理によって、ＩＣＭＰメッセージを使用する場合と比較して、メッセージ交換の量は半減される。

さらに、ホーム・セルラ・ネットワーク７０が、インターネット・エンジニアリング・タスク・フォース（ＩＥＴＦ：Ｉｎｔｅｒｎｅｔ Ｅｎｇｉｎｅｅｒｉｎｇ Ｔａｓｋ Ｆｏｒｃｅ）のネットワークベース・ローカル・モビリティ・マネジメント（ＮｅｔＬＭＭ：Ｎｅｔｗｏｒｋ−ｂａｓｅｄ Ｌｏｃａｌ Ｍｏｂｉｌｉｔｙ Ｍａｎａｇｅｍｅｎｔ）ワーキング・グループによって定義されているプロキシ・モバイルＩＰ（ＰＭＩＰ：Ｐｒｏｘｙ Ｍｏｂｉｌｅ ＩＰ）プロトコルを使用するよう実装されていてもよいことは、当業者にとって明らかである。

今まで最も実際的で好ましい実施の形態と考えられるものを通して本発明を図示し、説明してきたが、当業者であれば、本発明の範囲及び領域から逸脱することなしに、設計及びパラメータの詳細について種々に修正することができることを理解することができるだろう。

なお、上記の本発明の実施の形態の説明で用いた各機能ブロックは、典型的には集積回路であるＬＳＩ（Large Scale Integration）として実現される。これらは個別に１チップ化されてもよいし、一部又はすべてを含むように１チップ化されてもよい。なお、ここでは、ＬＳＩとしたが、集積度の違いにより、ＩＣ（Integrated Circuit）、システムＬＳＩ、スーパーＬＳＩ、ウルトラＬＳＩと呼称されることもある。

また、集積回路化の手法はＬＳＩに限るものではなく、専用回路又は汎用プロセッサで実現してもよい。ＬＳＩ製造後に、プログラムすることが可能なＦＰＧＡ（Field Programmable Gate Array）や、ＬＳＩ内部の回路セルの接続や設定を再構成可能なリコンフィギュラブル・プロセッサを利用してもよい。

さらには、半導体技術の進歩又は派生する別技術によりＬＳＩに置き換わる集積回路化の技術が登場すれば、当然、その技術を用いて機能ブロックの集積化を行ってもよい。例えば、バイオ技術の適応などが可能性としてあり得る。

本発明は、移動通信ネットワーク内の電気通信の技術分野に適用可能であり、特に、気付けアドレスを検証するための方法に関する技術に適用可能である。

本発明の好ましい実施の形態による好適なシステムを示す図面 本発明の好ましい実施の形態によるホーム・エージェントの好適な構成要素を示す図面 本発明の好ましい実施の形態による一括バインディング更新の好適なメッセージ・フォーマットを示す図面 本発明の好ましい実施の形態によるホーム・エージェントのところに格納しているマルチモード・ノードに対する好適なバインディングエントリを示す図面 本発明の好ましい実施の形態によるマルチモード・ノードとホーム・エージェントの間の気付けアドレス検証プロセスを行うための好適な方法のシーケンス図を示す図面 本発明の好ましい実施の形態によるホーム・エージェントのところの気付けアドレスバインディングのための状態図を示す図面 本発明の別の好ましい実施の形態による好適なシステムを示す図面 本発明の別の好ましい実施の形態によるホーム・エージェントが検証処理を行う必要があるかどうかを判断する好適な方法を示すフロー図を示す図面

Claims (17)

1. 第１のノードが第２のノードに対応する複数のアドレスを検証する、バインディングアドレスの検証方法であって、
   前記第１のノードが前記複数のアドレスのそれぞれに関する各バインディングエントリを格納するステップと、
   前記第１のノードが各バインディングエントリに未検証のマークを付けるステップと、
   前記第１のノードが未検証のマークが付けられたバインディングエントリ内のアドレスに関するアドレス可能性を検証する検証ステップとを、
   有する検証方法。
2. 前記検証ステップが、
   前記第１のノードが、前記複数のアドレスを通知するバインディングメッセージを前記第２のノードから受信した場合に、前記複数のアドレスに前記バインディングメッセージのソース・アドレスとして使用されているアドレスが含まれているかどうかを確認するステップと、
   前記第１のノードが、前記バインディングメッセージの前記ソース・アドレスとして使用されている前記アドレスを含むバインディングエントリに検証済みのマークを付けるステップとを、
   有する請求項１に記載のバインディングアドレスの検証方法。
3. 前記検証ステップが、
   前記第１のノードが、未検証のマークが付けられているバインディングエントリ内のアドレスへメッセージを送信するステップと、
   前記第１のノードが、前記メッセージが前記第２のノードによって受信されたことを把握する把握ステップとを、
   有する請求項１に記載のバインディングアドレスの検証方法。
4. 前記把握ステップが、前記第１のノードが前記メッセージに応じた応答メッセージを前記第２のノードから受信するステップを有する請求項３に記載のバインディングアドレスの検証方法。
5. 前記検証ステップが、
   前記第１のノードが、未検証のマークが付けられている前記バインディングエントリ内の前記複数のアドレスから２つのアドレスを選択するステップと、
   前記第１のノードが、選択された第１のアドレス経由で送信される応答メッセージを要求するメッセージを、選択された第２のアドレスを送信するステップと、
   前記第１のノードが、前記選択された第１のアドレス経由で送信された前記応答メッセージを受信した場合に、前記選択された第１のアドレスを含むバインディングエントリ、及び、前記選択された第２のアドレスを含むバインディングエントリに検証済みのマークを付けるステップとを、
   有する請求項１に記載のバインディングアドレスの検証方法。
6. 前記検証ステップが、
   前記第１のノードが、未検証のマークが付けられている前記バインディングエントリに、短期間の有効期間を設定するステップと、
   前記第１のノードが、未検証のマークが付けられている前記バインディングエントリ内のアドレスの前記有効期間が期限切れになろうとしていることを通知する通知メッセージを、前記第２のノードへ送信するステップと、
   前記第２のノードが、前記通知メッセージの応答として、未検証のマークが付けられているアドレスに関する前記バインディグエントリを更新するための更新メッセージを、前記第１のノードへ送信するステップと、
   前記第１のノードが、前記通知メッセージの宛先アドレスに使用されているアドレスを含むバインディングエントリ、及び、前記更新メッセージのソース・アドレスに使用されているアドレスを含むバインディングエントリに、検証済みのマークを付けるステップとを、
   有する請求項１に記載のバインディングアドレスの検証方法。
7. 前記検証ステップが、
   前記第１のノードが、未検証のマークが付けられている前記バインディングエントリに、短期間の有効期間を設定するステップと、
   前記第１のノードが、未検証のマークが付けられている前記バインディングエントリ内の前記複数のアドレスから２つのアドレスを選択するステップと、
   前記第１のノードが、選択された第１のアドレス経由で送信される応答メッセージを要求するとともに、未検証のマークが付けられている前記バインディングエントリ内のアドレスの前記有効期間が期限切れになろうとしていることを通知する通知メッセージを、選択された第２のアドレスへ送信するステップと、
   前記第１のノードが、前記選択された第１のアドレス経由で送信された前記応答メッセージを受信した場合に、前記選択された第１のアドレスを含むバインディングエントリ、及び、前記選択された第２のアドレスを含むバインディングエントリに検証済みのマークを付けるステップと、
   前記第１のノードが、前記通知メッセージの応答として、未検証のアドレスのマークが付けられているアドレスに関する前記バインディングエントリを更新するための更新メッセージを前記第２のノードから受信した場合に、前記通知メッセージの宛先アドレスに使用されているアドレスを含むバインディングエントリ、及び、前記更新メッセージのソースアドレスに使用されているアドレスを含むバインディングエントリに、検証済みのマークを付けるステップとを、
   有するバインディングアドレスの検証方法。
8. 第１のノードに実装されており、前記第１のノードが第２のノードに対応する複数のアドレスを検証する、バインディングアドレスの検証装置であって、
   前記複数のアドレスのそれぞれに関する各バインディングエントリを格納する手段と、
   各バインディングエントリに未検証のマークを付ける手段と、
   前記第１のノードが未検証のマークが付けられたバインディングエントリ内のアドレスに関するアドレス可能性を検証する検証手段とを、
   有するバインディングアドレスの検証装置。
9. 前記検証手段が、
   前記複数のアドレスを通知するバインディングメッセージを前記第２のノードから受信した場合に、前記複数のアドレスに前記バインディングメッセージのソース・アドレスとして使用されているアドレスが含まれているかどうかを確認する手段と、
   前記バインディングメッセージの前記ソース・アドレスとして使用されている前記アドレスを含むバインディングエントリに検証済みのマークを付ける手段とを、
   有する請求項８に記載のバインディングアドレスの検証装置。
10. 前記検証手段が、
    未検証のマークが付けられているバインディングエントリ内のアドレスへメッセージを送信する手段と、
    前記メッセージが前記第２のノードによって受信されたことを把握する把握手段とを、
    有する請求項８に記載のバインディングアドレスの検証装置。
11. 前記把握手段が、前記メッセージに応じた応答メッセージを前記第２のノードから受信する手段を有する請求項１０に記載のバインディングアドレスの検証装置。
12. 前記検証手段が、
    未検証のマークが付けられている前記バインディングエントリ内の前記複数のアドレスから２つのアドレスを選択する手段と、
    選択された第１のアドレス経由で送信される応答メッセージを要求するメッセージを、選択された第２のアドレスを送信する手段と、
    前記選択された第１のアドレス経由で送信された前記応答メッセージを受信し、前記選択された第１のアドレスを含むバインディングエントリ、及び、前記選択された第２のアドレスを含むバインディングエントリに検証済みのマークを付ける手段とを、
    有する請求項８に記載のバインディングアドレスの検証装置。
13. 前記検証手段が、
    未検証のマークが付けられている前記バインディングエントリに、短期間の有効期間を設定する手段と、
    未検証のマークが付けられている前記バインディングエントリ内のアドレスの前記有効期間が期限切れになろうとしていることを通知する通知メッセージを、前記第２のノードへ送信する手段と、
    前記通知メッセージの応答として、未検証のアドレスのマークが付けられているアドレスに関する前記バインディングエントリを更新するための更新メッセージを前記第１のノードから受信した場合に、前記通知メッセージの宛先アドレスに使用されているアドレスを含むバインディングエントリ、及び、前記更新メッセージのソースアドレスに使用されているアドレスを含むバインディングエントリに、検証済みのマークを付ける手段とを、
    有する請求項８に記載のバインディングエントリの検証装置。
14. 前記検証手段が、
    未検証のマークが付けられている前記バインディングエントリに、短期間の有効期間を設定する手段と、
    未検証のマークが付けられている前記バインディングエントリ内の前記複数のアドレスから２つのアドレスを選択する手段と、
    選択された第１のアドレス経由で送信される応答メッセージを要求するとともに、未検証のマークが付けられている前記バインディングエントリ内のアドレスの前記有効期間が期限切れになろうとしていることを通知する通知メッセージを、選択された第２のアドレスへ送信する手段と、
    前記選択された第１のアドレス経由で送信された前記応答メッセージを受信した場合に、前記選択された第１のアドレスを含むバインディングエントリ、及び、前記選択された第２のアドレスを含むバインディングエントリに検証済みのマークを付ける手段と、
    前記通知メッセージの応答として、未検証のアドレスのマークが付けられているアドレスに関する前記バインディングエントリを更新するための更新メッセージを前記第２のノードから受信した場合に、前記通知メッセージの宛先アドレスに使用されているアドレスを含むバインディングエントリ、及び、前記更新メッセージのソース・アドレスに使用されているアドレスを含むバインディングエントリに、検証済みのマークを付ける手段とを、
    有する請求項８に記載のバインディングエントリの検証装置。
15. 移動ノードであって、
    前記移動ノード自体に対応している複数のアドレスを管理する手段と、
    前記移動ノードの前記複数のアドレスを、前記アドレス管理装置に登録及び更新する手段と、
    第１のアドレスから、第２のアドレス経由で送信される応答メッセージを要求するメッセージを受信する手段と、
    前記第２のアドレス経由で前記応答メッセージを送信する手段とを、
    有する移動ノード。
16. 前記検証ステップが、
    アドレスに関する前記バインディングエントリには、未検証又は検証済みのマークが付けられており、前記第１のノードが、返答メッセージにおいて、前記第２のノードのバインディングエントリを前記第２のノードへ示すステップと、
    前記第１のノードが前記第２のノードからのデータパケットを、前記未検証のアドレスから受信するステップと、
    前記第１のノードが、前記データパケットを受信すると、前記未検証のアドレスのバインディングエントリに検証済みのマークを付けるステップとを、
    有する請求項１に記載のバインディングアドレスの検証方法。
17. 前記検証手段が、
    バインディングエントリの状態を示すためのメッセージを送信する手段と、
    未検証のマークが付けられているアドレスに関するメッセージを前記第２のノードから受信すると、前記バインディングエントリに検証済みのマークを付ける手段とを、
    有する請求項８に記載のバインディングアドレスの検証装置。