(57)【要約】  ホストアイデンティティプロトコルであるＨＩＰを使用して、第２ホスト（３２）と、第１ホスト（３０）上のアプリケーションソケット（４２）間の接続を確立する方法が提供される。前記第１ホストと前記第２ホスト（３０、３２）間の既存のＨＩＰセキュリティアソシエーション（４６）を選択する、あるいは新規に確立し、前記アプリケーションソケット（４２）と前記セキュリティアソシエーション（４６）間における、チューブ識別子によって識別される、既存のチューブアソシエーション（４４）を選択する、あるいは新規に生成し、前記アプリケーションソケット（４２）と、前記セキュリティアソシエーション（４６）と、前記チューブアソシエーション（４４）間の前記接続に対するアソシエーション（４３、４５）を形成し、これによって、前記セキュリティアソシエーション（４６）と前記チューブアソシエーション（４４）を通じて、前記第２ホスト（３２）と前記第１ホスト上の前記アプリケーションソケット（４２）間の接続を確立する。【選択図】  なし
2008543140.tif 000002
【特許請求の範囲】
【請求項１】
ホストアイデンティティプロトコルであるＨＩＰを使用して、第２ホストと、第１ホスト上のアプリケーションソケット間の接続を確立する方法であって、
前記第１ホストと前記第２ホスト間の既存のＨＩＰセキュリティアソシエーションを選択する、あるいは新規に確立し、
前記アプリケーションソケットと前記セキュリティアソシエーション間における、チューブ識別子によって識別される、既存のチューブアソシエーションを選択する、あるいは新規に生成するし、
前記アプリケーションソケットと、前記セキュリティアソシエーションと、前記チューブアソシエーション間の前記接続に対するアソシエーションを形成し、
これによって、前記セキュリティアソシエーションと前記チューブアソシエーションを通じて、前記第２ホストと前記第１ホスト上の前記アプリケーションソケット間の接続を確立する
ことを特徴とする方法。
【請求項２】
前記アプリケーションソケットは、ポートを備える
ことを特徴とする請求項１に記載の方法。
【請求項３】
前記アプリケーションソケットは、ＨＩＴあるいはＬＳＩを備える
ことを特徴とする請求項１または２に記載の方法。
【請求項４】
前記アプリケーションソケットは、ＩＰアドレスを備える
ことを特徴とする請求項１乃至３のいずれか１項に記載の方法。
【請求項５】
更に、前記接続に対するアソシエーションに関連する接続アソシエーション情報を前記第２ホストへ通信する
ことを特徴とする請求項１乃至４のいずれか１項に記載の方法。
【請求項６】
前記接続アソシエーション情報は、ＨＩＰ  ＵＰＤＡＴＥメッセージで通信される
ことを特徴とする請求項５に記載の方法。
【請求項７】
前記接続アソシエーション情報は、新規のセキュリティアソシエーションを確立するために、前記第１ホストと前記第２ホスト間のＨＩＰネゴシエーション中に通信される
ことを特徴とする請求項５または６に記載の方法。
【請求項８】
前記接続アソシエーション情報は、前記チューブ識別子と前記ソケット間の前記アソシエーションあるいはマッピングに関連する第１情報を含む
ことを特徴とする請求項５乃至７のいずれか１項に記載の方法。
【請求項９】
前記接続アソシエーション情報は、前記チューブ識別子とＳＰＩ間の前記アソシエーションに関連する第２情報を含む
ことを特徴とする請求項５乃至８のいずれか１項に記載の方法。
【請求項１０】
前記第１情報及び前記第２情報は、別々のＨＩＰパラメータとして送信される
ことを特徴とする請求項９に記載の方法。
【請求項１１】
前記第１情報及び前記第２情報に関連する前記ＨＩＰパラメータはそれぞれ、ＴＵＰＯ＿ＩＮＦＯパラメータ及びＳＡＴＵ＿ＩＮＦＯパラメータである
ことを特徴とする請求項１０に記載の方法。
【請求項１２】
アクティブな接続のポリシーの変更に応じて、前記接続アソシエーション情報を送信する
ことを特徴とする請求項５乃至１１のいずれか１項に記載の方法。
【請求項１３】
上位レイヤのポリシー管理のポリシーの変更に応じて、前記接続アソシエーション情報を送信する
ことを特徴とする請求項５乃至１２のいずれか１項に記載の方法。
【請求項１４】
前記第１ホストは、マルチホーム化され、前記第２ホストに向けて確立することができるセキュリティアソシエーションを介する、いくつかのネットワークインタフェースを備える
ことを特徴とする請求項１乃至１２のいずれか１項に記載の方法。
【請求項１５】
前記第２ホストは、マルチホーム化されている
ことを特徴とする請求項１４に記載の方法。
【請求項１６】
既存のチューブアソシエーションは、既存のセキュリティアソシエーションが選択される場合に選択される
ことを特徴とする請求項１乃至１５のいずれか１項に記載の方法。
【請求項１７】
既存のチューブアソシエーションを選択し、かつ複製することによって、新規のチューブアソシエーションを生成する
ことを特徴とする請求項１乃至１６のいずれか１項に記載の方法。
【請求項１８】
前記第２ホストで確立されるポリシーと互換性のある前記チューブアソシエーションに対するポリシーを確立する
ことを特徴とする請求項１乃至１７のいずれか１項に記載の方法。
【請求項１９】
チューブアソシエーションの複製を生成する
ことを特徴とする請求項１乃至１８のいずれか１項に記載の方法。
【請求項２０】
前記チューブアソシエーションの複製は、着信トラフィック及び発信トラフィックそれぞれに対するものである
ことを特徴とする請求項１９に記載の方法。
【請求項２１】
１つのセキュリティアソシエーションが、前記チューブアソシエーションに関連付けられている
ことを特徴とする請求項１乃至２０のいずれか１項に記載の方法。
【請求項２２】
複数のセキュリティアソシエーションが、前記チューブアソシエーションに関連付けられている
ことを特徴とする請求項１乃至２０のいずれか１項に記載の方法。
【請求項２３】
複数のセキュリティアソシエーションと複数のチューブアソシエーションが前もって生成され、前記セキュリティアソシエーションと前記チューブアソシエーションは、これらから選択される
ことを特徴とする請求項１乃至２２のいずれか１項に記載の方法。
【請求項２４】
前記チューブアソシエーションに関連する情報の少なくともいくつかは、前記第１ホストで管理される
ことを特徴とする請求項１乃至２３のいずれか１項に記載の方法。
【請求項２５】
ホストアイデンティティプロトコルであるＨＩＰを使用して、リモートホストと、当該装置上のアプリケーションソケット間の接続を確立する装置であって、
当該装置と前記リモートホスト間の既存のＨＩＰセキュリティアソシエーションを選択する、あるいは新規に確立する手段と、
前記アプリケーションソケットと前記セキュリティアソシエーション間における、チューブ識別子によって識別される、既存のチューブアソシエーションを選択する、あるいは新規に生成する手段と、
前記アプリケーションソケットと、前記セキュリティアソシエーションと、前記チューブアソシエーション間の前記接続に対するアソシエーションを形成する手段とを備え、
これによって、前記セキュリティアソシエーションと前記チューブアソシエーションを通じて、前記リモートホストと当該装置上の前記アプリケーションソケット間の接続を確立する
ことを特徴とする装置。
【請求項２６】
装置にロードされる場合に、請求項２５に記載の装置として機能するように前記装置を制御するための動作プログラム。
【請求項２７】
装置上で実行する場合に、請求項１乃至２４のいずれか１項に記載の方法を実行するように、前記装置を制御するための動作プログラム。
【請求項２８】
搬送媒体上で実行される
ことを特徴とする請求項２６または２７に記載の動作プログラム。
【請求項２９】
前記搬送媒体は、送信媒体である
ことを特徴とする請求項２８に記載の動作プログラム。
【請求項３０】
前記搬送媒体は、記憶媒体である
ことを特徴とする請求項２８に記載の動作プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
１．発明の分野
本発明は、ホストアイデンティティプロトコルを使用する方法及び装置に関するものである。
【０００２】
２．従来技術の説明
インターネットが本来考案された時分には、ホストの位置は固定されていて、また、実際のセキュリティあるいはホスト識別プロトコルの欠如があるにも関わらず、ユーザ間では暗黙の信頼が存在していた、そして、この状況は、技術が広く普及し使用されるようになっても継続していた。コンピュータは相対的に大規模でかつ固定されているものであったので、ホストモビリティ（host mobility：ホスト移動性）を扱う技術を考慮する必要性は小さかった。
【０００３】
１９９０年代の電気通信及びコンピュータ産業の改革に伴い、より小型の通信機器及びコンピュータで、ワールドワイドウェブの発明と、それによってもたらされるあらゆるサービスをより広範囲で利用可能なり、結果として、一般的な人達にインターネットを魅力あるものにしている。ネットワークと移動電気通信が組み合わされて使用することが増えるにつれて、インターネットにおけるセキュアなモビリティ管理が必要となっている。
【０００４】
介在するパーティの増加と、あるサービスについては必要とされる金融取引も、アプリケーションレベルでのセキュリティを付加する必要性が生まれている。現在のところ、最も広く使用されている暗号化プロトコル、例えば、ＳＳＬ／ＴＬＳは、例えば、ＴＣＰにおける上位のネットワークレイヤで動作している。
【０００５】
上述のモビリティ管理及びセキュリティの問題を考慮して、移動体（モバイル）ＩＰ規格（シー．ペルキンス、「ＩＰｖ４用ＩＰモビリティサポート」、２００２年のＩＥＴＦのＲＦＣ３２２０）とモバイルＩＰｖ６規格（ディー．ジョンソン、シー．ペルキンス、ジェイ．アルコ、「ＩＰｖ６におけるモビリティサポート」、２００４年のＩＥＴＦ、ＲＦＣ３７７５）が導入されている。これらの仕様は、次世代インターネット用のモビリティサポートを提供するために設計されている。セキュリティ機能は、ＩＰレイヤにおけるセキュリティを提供することを目的として、ＩＰｓｅｃと、それに関連するアクティビティ、例えば、様々なキー交換プロトコルの形式で発展している。しかしながら、現在の規格を使用して、セキュリティとモビリティを組み合わせることはかなり困難であることが示されている。
【０００６】
ＩＰアドレスは、ネットワーク内のトポロジー的な位置を記述するものである。このＩＰアドレスは、ソースノードから宛先へパケットを転送（ルート：route）するために使用される。同時に、このＩＰアドレスは、ノードを識別するために使用され、これによって、１つのエンティティで２つの異なる機能を提供する。このことは、人が、問い合わせがある場合に、それがだれなのかを自身の住所で応答することに等しい。モビリティも考慮される場合、この状況は、より複雑となる。これは、ＩＰアドレスは、このスキームにおけるホストアイデンティティとして動作し、これらは、変更されないからである。しかしながら、ＩＰアドレスは、トポロジー的な位置を記述するので、ホストがネットワーク内の自身の位置を変更する場合には、これらは変更される必要がある。明らかなことは、静的な変更と動的な変更を同時に達成することは不可能であることである。
【０００７】
モバイルＩＰの場合、このソリューションは、ノードに対する「ホームアドレス」を提供する固定のホーム位置を使用することである。ホームアドレスは、ノードを識別し、かつノードがホームに存在する場合にそのノードに対して固定の位置を提供する。現在の位置情報は、気付けアドレス（care-of-address）の形式で利用可能であり、これは、ノードがホームから離れる場合のルーティング目的のために使用される。
【０００８】
この問題についての別のソリューションは、識別機能と位置機能を互いに分離することであり、これは、ホストアイデンティティプロトコル（ＨＩＰ）で採用されている方法（アール．モスコビッツ、ピー．ニカンダー、ピー．ヨケラ、「ホストアイデンティティプロトコル」、２００６年、ＩＥＴＦ、策定中のインターネット草稿、draft-ietf-base-05）である。ＨＩＰは、新規の名前空間であるホストアイデンティティ（ＨＩ）を導入することによってＩＰアドレスの位置の役割及びアイデンティティの役割を分離している。ＨＩＰでは、ホストアイデンティティは、基本的には、パブリック（公開）−プライベート（秘密）キーペアの公開暗号化キーであり、プライベートキー（秘密鍵）から生成され、かつそのプライベートキーにリンクしている。パブリックキー（公開鍵）は、プライベートキーのコピーだけを保有するパーティを識別する。このキーペアのプライベートキーを処理するホストは、ネットワーク内でホストを識別するために使用されるパブリックキーをホストが「所有」していることを直接証明することができる。また、この分離は、セキュア（安全）な方法で、モビリティとマルチホーミングを処理するための手段を提供する。
【０００９】
位置とアイデンティティの分離の概念に基づく提案だけでなく、ＨＩＰについては以下で詳細に説明する。ＦＡＲＡ（ディー．クラーク、アール．ブラデン、エイ．ファルク、ビイ．ピンガリ、「ＦＡＲＡ：アドレッシングアーキテクチャの再編成」、ＡＣＭ  ＳＩＧＣＯＭＭ  ２００３  ワークショップ、２００３年８月２５日＆２７日）は、実際のアーキテクチャから導出することができるフレームワークを提供する、汎用化モデルの概念である。ＦＡＲＡは、ノード識別が検証される場合にＨＩＰを使用することができ、その結果、ＨＩＰは、特定のＦＡＲＡインスタンス化の一部とすることができる。ＰｅｅｒＮｅｔ（ピアネット）の提案（ジェイ．エリクソン、エム．ファラウトス、エス．クリシュナムルシー、「ピアネット：ピアツーピアのスタックへのプッシュ（Pushing Peer-to-Peer Down the Stack）」、ＩＰＴＰＳ’０３、２００３年２月２０日−２１日）も、位置及びアイデンティティの分離を議論している。インターネットインダイレクションインフラストラクチャ（Internet Indirection Infrastructure）、Ｉ3（アイ．ストイカ等、「インターネットインダイレクションインフラストラクチャ」、ＡＣＭ  ＳＩＧＣＯＭＭ’０２、２００２年８月１９−２３）も、アイデンティティ情報とルーティング情報の分離を定義している。
【００１０】
ホストアイデンティティプロトコルは、ＩＰレイヤでの位置情報とアイデンティティ情報の分離を導入している。この分離に加えて、ＨＩＰを実現可能なノード間でのセキュリティアソシエーション（ＳＡ）をネゴシエートするためのプロトコルが定義されている。
【００１１】
ＨＩＰを用いると、各ホストは１つ以上のアイデンティティを有していて、これは、長期間あるいは短期間とすることができ、これは、ネットワークでホストを識別するために使用することができる。ＨＩＰを用いると、識別子は、パブリック−プライベートキーペアのパブリックキーとなる。ホストがプライベートキーを処理する場合、ホストは、パブリックキーが表現するアイデンティティを実際に自身が「所有」していることを証明することができ、これは、ＩＤカードを示すことに等しい。
【００１２】
各ホストは、短期間に対してのみ使用される短期間キーを生成することができる。これらのキーは、後に同一のアイデンティティで識別されるべきノードに対して必要とされない場合に有用である。例えば、書店から書籍を購入することは、長期間の関係とすることができる一方で、ユーザプロファイルを収集するために１回だけサーバに接続することは、短期間の動作として見なすことができる。後者の場合、短期間アイデンティティを、長期間アイデンティティがより広範囲に普及することを防止するために生成することができる。
【００１３】
パブリックキーとなるＨＩＰホストアイデンティティ（ＨＩ）は、かなり長いものにすることができるので、あらゆる状況で実用的であるとはいえない。ＨＩＰでは、ＨＩは、１２８ビット長のホストアイデンティティタグ（ＨＩＴ）で表現され、これは、それをハッシュにかけることによって生成される。つまり、ＨＩＴは、ＨＩを識別する。ＨＩＴは１２８ビット長なので、ＩＰｖ６アドレスと確実に同一長となるように直接ＩＰｖ６アプリケーションに対して使用することができる。
【００１４】
ホストアイデンティティの別の表現は、ローカルスコープ識別子（ＬＳＩ）であり、これは、ホストアイデンティティに対する３２ビット表現である。ＬＳＩの目的は、既存のプロトコルとＡＰＩでホストアイデンティティを使用することを容易にすることである。例えば、ＬＳＩはＩＰｖ４アドレスと同一長であるので、ＩＰｖ４アプリケーションに対して直接使用することができる。本明細書の以下の記載の大半は、より長期のＨＩＴを使用することを基礎にしており、同一あるいは同様の考慮を別のＬＳＩ表現に適用することは明らかであろう。
【００１５】
ＨＩＰが使用される場合、アプリケーションを含む上位レイヤはこれ以上ＩＰアドレスを見ることがない。代わりに、これらは、ＨＩＴを宛先ホストの「アドレス」として見なす。位置情報は、後述するように、新規のレイヤでは隠蔽されている。ＩＰアドレスは、これ以上ノードを識別しない、これらは、ネットワーク内でパケットをルーティングするためだけに使用される。
【００１６】
アプリケーションは、典型的には、位置情報に関心はないが、自身のピア（同位：peer）のアイデンティティを把握することを必要とする。このアイデンティティは、ＨＩＴで表現される。これは、ＩＰアドレスは、ルーティングが関与する下位レイヤにおいてのみ重要であることを意味する。アプリケーションが使用するＨＩＴは、任意のパケットがホストから離れる前に、対応するＩＰアドレスへマッピングされなければならない。これは、後述する新規のホストアイデンティティレイヤで達成される。
【００１７】
図１は、ＨＩＰにおける様々なレイヤを示していて、これは、標準のトランスポートレイヤ４、ネットワークレイヤ８及びリンクレイヤ１０を含み、また、プロセス２は、配下のトランスポートレイヤ４と通信する。ＨＩＰを用いると、新規のホストアイデンティティレイヤ６が、トランスポートレイヤ４とネットワークレイヤ８の間に配置される。
【００１８】
局所的には、各ＨＩとそれに関係するＨＩＴはノードのＩＰアドレスにマッピングされる。パケットがホストを離れる場合、正しいルートが選択され（なんらかの手段によって）かつ対応するＩＰアドレスは、ソースアドレスと宛先アドレスとしてパケットに組み込まれる。上位レイヤから到来する各パケットは、宛先アドレスとピア（同位）のＨＩＴを含んでいる。ＨＩＴと位置情報間のマッピングは、ＨＩレイヤ６で検出することができる。ここで、宛先アドレスは、マッピングされているＩＰアドレスに変換され、ソースＨＩＴはソースＩＰアドレスに変換される。
【００１９】
同位（ピア）のＨＩＴとＩＰアドレス間のマッピングはいくつかの方法で取得することができ、その内の１つは、ＤＮＳサーバからのものがある。位置情報は、いつでもピアノードによって更新することができる。更新処理は、以下でより詳細に説明する。
【００２０】
ＨＩＰは、４つのメッセージを含む基本メッセージ交換である、フォーウェイハンドシェイクを定義していて、また、これは、ＨＩＰを実現可能なホスト間でセキュリティアソシエーション（ＳＡ）を生成するために使用される。メッセージ交換中に、セッションキーを生成するために、また、ノード間のＩＰｓｅｃカプセル化セキュリティペイロード（ＥＳＰ）セキュリティアソシエーション（ＳＡ）のペアを成立させるために、デフィ−ヘルマン処理が使用される。
【００２１】
図２はフォーウェイハンドシェイクの動作を示している。ネゴシエートするパーティ群には、接続を開始するイニシエータ（Initiator）と、それに対するレスポンダー（Responder）と呼ばれるものがある。イニシエータは、ネゴシエーションに関係するノードのＨＩＴを含むＩ１パケットを送信することによって、そのネゴシエーションを開始する。イニシエータによってレスポンダのＨＩＴが不明である場合は、宛先ＨＩＴはゼロであっても良い。
【００２２】
レスポンダがＩ１パケットを取得すると、レスポンダは、イニシエータによって解読されるべきパズル（puzzle）を含むＲ１パケットを返信する。イニシエータがそのパズルを解読中に計算のほとんどを実行しなければならいようにプロトコルは設計されている。これは、ＤｏＳ攻撃に対していくつかの保護を与える。Ｒ１は、デフィ−ヘルマンパラメータとともに、レスポンダのパブリックキーを含む、デフィ−ヘルマン処理も開始する。
【００２３】
Ｒ１パケットが一旦受信されると、イニシエータはパズルを解読し、ＩＰｓｅｃＳＰＩ値と自身の暗号化パブリックキーとともに、Ｉ２パケットで応答クッキーをレスポンダへ送信する。レスポンダは、パズルが解読されていることを検証すると、イニシエータを認証し、ＩＰｓｅｃ  ＥＳＰ  ＳＡを生成する。最終のＲ２メッセージは、レスポンダのＳＰＩ値を含んでいる。
【００２４】
ホスト間のＳＡは、ＨＩＴによって表現されるホストアイデンティティにバインドされている。しかしながら、ネットワークを通過するパケットは、実際のＨＩ情報を含んいない。但し、到来パケットは識別され、かつＩＰｓｅｃヘッダのセキュリティパラメータインデックス（ＳＰＩ）を使用して、正しいＳＡへマッピングされる。図３は、論理的なパケット構造と、パケットがネットワークを通過する場合の実際のパケット構造を示している。
【００２５】
上述のことから、パケット内の位置情報の変更はＩＰｓｅｃ処理に対する問題を興さないことは明らかである。このパケットは、依然として、ＳＰＩを使用して正しく識別される。いくつかの理由で、パケットが誤った宛先へ転送される場合、受信側は、正しいキーを持っていないのでそのパケットを開くことはできない。
【００２６】
発信パケットが上位レイヤからＨＩレイヤへ到達すると、宛先ＨＩＴがＩＰｓｅｃ  ＳＡＤＢから検証される。宛先ＨＩＴとマッチングするＳＡが検出される場合、このパケットは、ＳＡに関連付けられているセッションキーを使用して暗号化される。
【００２７】
ＨＩＴはパケットを転送するために使用することはできない。つまり、宛先（及びソース）アドレスは、ノードのＩＰアドレスをマッチングするために変更されなければならない。上述のように、これらのマッピングはＨＩレイヤに記憶される。アドレスが変更された後、パケットは、ＩＰアドレス情報を使用してそのパケットが宛先へ転送されるネットワークへ送信され得る。
【００２８】
受信側のホストで、ＳＰＩ値は、ＩＰｓｅｃＳＡＤＢから正しいＳＡを検出するために使用される。エントリが検出される場合、ＩＰアドレスは、対応するＨＩＴに変更することができ、また、パケットは、セッションキーを使用して暗号化することができる。
【００２９】
モビリティ（移動性：mobility）とは、自身の通信状況をアクティブに維持しながらホストが移動する状況であることに対して定義されているものであり、換言すれば、ホストが、既存の接続をすべてアクティブに維持しながら、ＩＰアドレスによって記述される自身のトポロジー的な位置を変更することである。ホスト上で動作するプロセスは、経験しているサービスの品質が変更される場合の可能性以外は、モビリティを見ていない。
【００３０】
モバイル（移動）ホストは、異なるアクセス技術の間で、あるいは異なるＩＰアドレス範囲の間、例えば、ＩＰｖ４とＩＰｖ６の間でさえも、アクセスネットワーク内の位置を変更することができる。ＨＩＰでは、アプリケーションは、ＩＰアドレスバージョンの変更を通知しない。ＨＩレイヤは、上位レイヤからこの変更を完全に隠蔽している。もちろん、ピアノードは、いくつかの互換性のあるアドレスを使用して転送可能でなければならないＩＰバージョンとパケットを変更する位置更新を処理することが可能でなければならない。ノードがＩＰｖ４とＩＰｖ６との両方についての接続性を有していない場合、アドレスバージョン変換を実行し、そのノードに変わって接続性を提供するプロキシを使用することができる。
【００３１】
マルチホーミングとは、エンドポイントが、並行して使用することができるいくつかの通信経路を有している状況を指すものである。通常、マルチホーミングは、いくつかのネットワークインタフェースを有するホストとなる（エンドホストマルチホーミング）、あるいはホスト間のネットワークと、そのネットワークとは別の冗長経路を有するネットワークによるものがある（サイトマルチホーミング）。
【００３２】
ＨＩＰを用いると、位置情報とアイデンティティ情報間の分離は、パケット識別とルーティングとをきれいに互いに分離できることを明らかにする。パケットを受信するホストは、正しいキーをまず取得して、パケットを解読することによって送信者を識別する。つまり、パケット内に存在するＩＰアドレスは無関係である。
【００３３】
ネットワーク内を移動するＨＩＰモバイルノード（ＨＭＮ）は、インターネットの接続ポイントを定期的に変更することができる。接続ポイントが変更されると、ＩＰアドレスも変更される。この変更された位置情報はピアノード、即ち、ＨＩＰ対応ノード（ＨＣＮ）へ送信されなければならず、これについては図４で示されている。同一のアドレスを、ＨＭＮの転送エージェント（ＦＡ）へ送信することができ、そうすることで、より多くの適切なポイントを介してＨＭＮに到達することができる。位置情報を定期的に変更するために、ＤＮＳシステムを使用することは遅すぎる。それゆえ、ＨＭＮに接続するために使用することができるより適切なアドレスがなければならない。このアドレスは、ＦＡによって提供されるアドレスである。
【００３４】
ＨＩＰモビリティとマルチホーミングプロトコル（ピー．ニカンデル、ジェイ．アルコ、ピー．ヨケラ、「ホストアイデンティティプロトコルを用いる、エンドホストモビリティとマルチホーミング」、２００６年、ＩＥＴＦ、策定中のインターネット草稿、draft-ietf-hip-mm-03）は、更新（ＵＰＤＡＴＥ）パケットを定義し、これは、ＨＭＮの現在のＩＰアドレスを含む「ロケータパラメータ」（早期のインターネット草稿の回送（ＲＥＡ）パラメータとして知られる）を搬送する。ＨＭＮが位置及びＩＰアドレスを変更する場合、これは、ＵＰＤＡＴＥパケットを生成し、使用されるＨＩにマッチするプライベートキーを用いてパケットを署名し、そして、そのパケットをピアノードとＦＡへ送信する。
【００３５】
ピアノードがＵＰＤＡＴＥパケットを受信すると、そのＵＰＤＡＴＥパケットに含まれるＩＰアドレスに対するアドレス検証プロセスを開始しなければならない。このアドレス検証は、ＨＭＮからの誤った更新を受け付けることを回避するために必要である。これは、更新応答確認（ＵＰＤＡＴＥ−ＡＣＫ）パケットをＵＰＤＡＴＥパケットに存在していたアドレスへ送信する。ＨＭＮが先に送信されているＵＰＤＡＴＥとマッチするＵＰＤＡＴＥ−ＡＣＫを受信すると、データをＨＣＮへ送信するための新規のＩＰアドレスの使用を開始することができる。ピアノードが新規のＩＰアドレスから最初のデータパケットを受信すると、アドレス検証は完了し、そのＩＰアドレスをＨＭＮの位置情報として追加することができる。
【００３６】
ＨＭＮは異なるＩＰアドレスバージョンを使用してネットワーク間を移動することができるので、ＨＣＮによって受信されるアドレスも、従前のアドレスとは異なるアドレスファミリーから得ることができる。
【００３７】
ＨＣＮは、１つのＩＰアドレスバージョンのみをサポートすることができる。この場合、ＨＣＮは、他のＩＰアドレスバージョンのネットワークを介してパケットを転送するために使用することができるいくつかの他のプロキシノードを使用しなければならない。
【００３８】
マルチホーム化ＨＩＰホストは、異なるアクセスネットワークに接続されている異なるインタフェースで構成される複数のＩＰアドレスを有していて、また、ピアノードに向けたトラフィックを処理するための、より多くの可能性を有している。これは、ネットワーク内での自身の現在位置を示す複数のＩＰアドレスを有しているので、これらのアドレスのすべてを自身のピアノードへ通知したい場合がある。そうするためには、マルチホーム化ＨＩＰノードはＵＰＤＡＴＥパケットを生成する。これは、特定のノードに向けて使用することができるアドレスのすべてを含んでいる。このアドレスのセットは、それが持てるアドレスのすべて、あるいはこれらのアドレスのサブセットを含んでいていても良い。ピアノードが複数のアドレスを有するＵＰＤＡＴＥパケットを受信すると、可能性のある誤った更新を回避するために、これらのアドレスのそれぞれに対してアドレス検証を行わなければならない。
【００３９】
ＵＰＤＡＴＥパケット内には、誤っている、あるいは転送可能なアドレスが発生する場合がある。これは、ＨＭＮが悪意のあるノードであり、それがスタック実装内に誤りを持たせているからである。あるいは、インターネット内で転送不可能となるプライベートアドレスを使用するネットワーク内にＨＭＮが存在する場合があるからである。
【００４０】
マルチホーム化ＨＩＰノードは、利用可能な接続のすべてを使用することができるが、接続を効率的に使用するためには、配下のアクセスネットワークの知識を有していて、かつそれらの使用を制御することができるポリシーシステムを必要とする。このようなポリシーシステムは、様々な種類の情報を使用することができる。これには、ユーザプリファレンス、オペレータプリファレンス、ネットワーク接続からの入力、例えば、ＱｏＳ等がある。
【００４１】
モバイルノードとのＨＩＰ交換を開始するためには、イニシエータノードは、そのモバイルノードへどのようにして到達するかについてを知っている必要がある。動的ＤＮＳは、頻繁に移動するノードに対してその機能を使用することができるが、この形式で使用するＤＮＳに代るものとしては、上述のスタティックインフラストラクチャの一部である、転送エージェント（ＨＩＰランデブーサーバとも呼ばれる）を使用することである。自身の現在の動的アドレスをＤＮＳサーバへ登録する代わりに、モバイルノードは、自身の転送エージェント（群）のアドレス（群）を登録する。モバイルノードは、自身の現在のＩＰアドレス（群）で継続的に更新される転送エージェント（群）を保持する。転送エージェントは、単に、イニシャルＨＩＰパケットを自身の位置で、イニシエータからモバイルノードへ転送する。続くパケットのすべてが、イニシエータとモバイルノード間で流れる。転送エージェントにおけるアクティビティは典型的にはかなりわずかであり、それは、主に、アドレス更新とイニシャルＨＩＰパケットの転送である。つまり、１つの転送エージェントは、大量数の潜在的な移動ノードをサポートすることができる。モバイルノードは、自身のＨＩＴとＩＰアドレスとのマッピングを適切に維持するために転送エージェントを信頼しなければならない。転送エージェントは、位置が固定されているノードについてさえ使用することができる。これは、固定されているノードは、自身のＩＰアドレスを頻繁に変更し得ること、例えば、そのノードに対するサービスプロバイダによってインターネット接続がセットアップされる毎にＩＰアドレスが割当られることがよくあるからである。
【００４２】
２つのノードの両方が移動体で、かつ同時に移動する場合にも転送エージェントとは必要とされる。この場合、ＨＩＰ回送パケットは、ネットワーク内を交錯して、ピアノードに到達することはない。この状況を解消するために、ノードは、転送エージェントアドレスを覚えておいて、リプライを受信しない場合にはＨＩＰ回送パケットを転送エージェントへ再送するべきである。
【００４３】
モバイルノードは、転送エージェントとＨＩＰアソシエーションをセットアップし、それに回送パケットを含めたＨＩＰ更新パケットを送信することによって、転送エージェント上の現在の自身のアドレスを保持する。転送エージェントは２つのモバイルシステムに、追加のインフラストラクチャ（加えて、転送エージェント自身）なしで、また、ＤＮＳクエリー以外で互いのＨＩ及びＨＩＴを取得する方法を有している場合にはそのＤＮＳなしで、ＨＩＰを使用することを許容する。
【００４４】
レガシー機器の場合、ホストはＨＩＰを実現可能でない場合があり、また、唯一のオプションは、ＩＰアドレスを使用して、ホスト間の接続を識別することである。これは、セキュアではない。この状況は、ＨＩＰを実現可能なホストと、ＨＩＰを使用することができないホスト間にＨＩＰプロキシを配置することによって改善することができる。典型的な状況は、クライアント端末がＨＩＰを実現可能でない、小企業のＬＡＮがある。トラフィックは、ＨＩＰプロキシを介して、共同するホスト（ＨＩＰを実現可能な）間で転送される。
【００４５】
この構成は図５で示される。図５では、レガシーホスト１２は、ＨＩＰプロキシ１６を介して、ＨＩＰを実現可能なノード１４（ドメイン名「hip.foo.com」）と通信していること示している。レガシーホスト１２は、アクセスネットワーク１８を介してＨＩＰプロキシ１６へアクセスし、一方、ＨＩＰプロキシ１６は、インターネット２０を介してＨＩＰノード１４へアクセスする。レガシーホスト１２とＨＩＰノード１４間の接続を部分的にセキュアにするために、ＨＩＰプロキシ１６とＨＩＰノード１４間の通信のすべてが、図３を参照して説明される方法と同様の方法で、ＨＩＰプロキシ１６とＨＩＰノード間でセットアップされるセキュリティアソシエーションを介在する。
【００４６】
しかしながら、図５に示されるセキュリティアソシエーション２２がセットアップされて、レガシーホスト１２とＨＩＰノード１４間での通信が可能となる前でも、ＨＩＰノード１４が上述のように転送エージェント２６の後に配置されている場合、クエリーをＤＮＳサーバ２４−１（及びＤＮＳサーバ２４−２へと）へ送信することによってＨＩＰノード１４のＩＰアドレスを解決することをレガシーホスト１２が試行する場合には問題が生じる。ＤＮＳサーバ２４−１は、転送エージェント２６のＩＰアドレスとともにＨＩＰノード１４のＨＩＴを返信することになる。レガシーホスト１２はＨＩＰを実現可能でないので、そのＨＩＴは無視された上で、転送エージェント２６へのメッセージの送信が開始することになる。ＨＩＴなしでは、転送エージェント２６は、これらのメッセージの宛先アドレスを解決できることはない。これは、いくつかのＨＩＰノードは、同一の転送エージェント２６を使用することがほとんどであるからである。同様に、レガシーホスト１２は、ＨＩＴを破棄し、接続を開始する場合にはＨＩＰノード１４のＩＰアドレスだけを使用するので、ＨＩＰプロキシ１６は、自身とＨＩＰノード１４間のＨＩＰネゴシエーションを開始することができない。これは、ＨＩＰプロキシ１６は、ＨＩＰノード１４のＨＩＴを知らないからである。この問題は、本出願人のＰＣＴ出願であるＥＰ０４／０５０１２９号で取り組まれている。
【００４７】
他の技術的な検討事項は、３Ｇ環境のユーザ機器（ＵＥ）のすべてがＨＩＰを実現可能ではない、第３世代（３Ｇ）移動体電気通信ネットワークでＨＩＰを実現する場合に生じる。この状況では、ユニバーサル移動体電気通信システム（ＵＭＴＳ）は、移動通信用グローバルシステム（ＧＳＭ）に対する第３世代に代るものである。ＵＭＴＳへ向かうＧＳＭの最も重要な革新的な進歩は、汎用パケット無線サービス（ＧＰＲＳ）である。ＧＰＲＳは、ＧＳＭコアネットワークへパケット交換を導入し、また、パケットデータネットワーク（ＰＤＮ）への直接アクセスを可能にしている。これは、ＧＳＭコアネットワークを介して、ＩＳＤＮの６４ｋｂｐｓの制限を十分に越える高データレートのパケット交換送信を可能にする。これは、２ＭｂｐｓまでのＵＭＴＳデータ送信レートに対して必要となる。ＧＰＲＳは、ＵＭＴＳの導入における必須条件である。ＧＰＲＳに向けられている原理と同様の原理が、ＵＭＴＳについても等価に適用可能である。ＧＰＲＳは、コネクションレスパケットデータサービスを提供するという目標を伴って、既存のＧＳＭネットワークインフラストラクチャの拡張として設計されている。ＧＰＲＳは、ＩＰベースのパケットデータのエンドツーエンドトランスポートをサポートするＧＳＭを介していくつかの新規の機能要素を導入している。
【００４８】
今までのところ、フローベースのモビリティティの使用の妨げになる技術的な問題が存在しているので、これらの技術的な問題の少なくともいくつかを解消することが要望されている。
【００４９】
本発明の第１の構成に従えば、ホストアイデンティティプロトコルであるＨＩＰを使用して、第２ホストと、第１ホスト上のアプリケーションソケット間の接続を確立する方法が提供される。この方法は、前記第１ホストと前記第２ホスト間の既存のＨＩＰセキュリティアソシエーションを選択する、あるいは新規に確立し、前記アプリケーションソケットと前記セキュリティアソシエーション間における、チューブ識別子によって識別される、既存のチューブアソシエーションを選択する、あるいは新規に生成し、前記アプリケーションソケットと、前記セキュリティアソシエーションと、前記チューブアソシエーション間の前記接続に対するアソシエーションを形成し、これによって、前記セキュリティアソシエーションと前記チューブアソシエーションを通じて、前記第２ホストと前記第１ホスト上の前記アプリケーションソケット間の接続を確立する。
【００５０】
前記アプリケーションソケットは、ポートを備えていても良い。
【００５１】
前記アプリケーションソケットは、ＨＩＴあるいはＬＳＩを備えていても良い。
【００５２】
前記アプリケーションソケットは、ＩＰアドレスを備えていても良い。
【００５３】
前記方法は、更に、前記接続に対するアソシエーションに関連する接続アソシエーション情報を前記第２ホストへ通信することを備えていても良い。
【００５４】
前記接続アソシエーション情報は、ＨＩＰ  ＵＰＤＡＴＥメッセージで通信されても良い。
【００５５】
前記接続アソシエーション情報は、新規のセキュリティアソシエーションを確立するために、前記第１ホストと前記第２ホスト間のＨＩＰネゴシエーション中に通信されても良い。
【００５６】
前記接続アソシエーション情報は、前記チューブ識別子と前記ソケット間の前記アソシエーションあるいはマッピングに関連する第１情報を含んでいても良い。
【００５７】
前記接続アソシエーション情報は、前記チューブ識別子とＳＰＩ間の前記アソシエーションに関連する第２情報を含んでいても良い。
【００５８】
前記第１情報及び前記第２情報は、別々のＨＩＰパラメータとして送信されても良い。
【００５９】
前記第１情報及び前記第２情報に関連する前記ＨＩＰパラメータはそれぞれ、ＴＵＰＯ＿ＩＮＦＯパラメータ及びＳＡＴＵ＿ＩＮＦＯパラメータであっても良い。
【００６０】
前記方法は、アクティブな接続のポリシーの変更に応じて、前記接続アソシエーション情報を送信することを含んでいても良い。
【００６１】
前記方法は、上位レイヤのポリシー管理のポリシーの変更に応じて、前記接続アソシエーション情報を送信することを含んでいても良い。
【００６２】
前記第１ホストは、マルチホーム化されていても良く、前記第２ホストに向けて確立することができるセキュリティアソシエーションを介する、いくつかのネットワークインタフェースを備える。
【００６３】
前記第２ホストは、マルチホーム化されていても良い。
【００６４】
既存のチューブアソシエーションは、既存のセキュリティアソシエーションが選択される場合に選択されても良い。
【００６５】
前記方法は、既存のチューブアソシエーションを選択し、かつ複製することによって、新規のチューブアソシエーションを生成することを含んでいても良い。
【００６６】
前記方法は、前記第２ホストで確立されるポリシーと互換性のある前記チューブアソシエーションに対するポリシーを確立することを含んでいても良い。
【００６７】
前記方法は、チューブアソシエーションの複製を生成することを含んでいても良い。
【００６８】
前記チューブアソシエーションの複製は、着信トラフィック及び発信トラフィックそれぞれに対するものであっても良い。
【００６９】
１つのセキュリティアソシエーションが、前記チューブアソシエーションに関連付けられていても良い。
【００７０】
複数のセキュリティアソシエーションが、前記チューブアソシエーションに関連付けられていても良い。
【００７１】
複数のセキュリティアソシエーションと複数のチューブアソシエーションが前もって生成されても良く、前記セキュリティアソシエーションと前記チューブアソシエーションは、これらから選択されても良い。
【００７２】
前記チューブアソシエーションに関連する情報の少なくともいくつかは、前記第１ホストで管理されても良い。
【００７３】
本発明の第２の構成に従えば、ホストアイデンティティプロトコルであるＨＩＰを使用して、リモートホストと、当該装置上のアプリケーションソケット間の接続を確立する装置が提供される。当該装置と前記リモートホスト間の既存のＨＩＰセキュリティアソシエーションを選択する、あるいは新規に確立する手段と、前記アプリケーションソケットと前記セキュリティアソシエーション間における、チューブ識別子によって識別される、既存のチューブアソシエーションを選択する、あるいは新規に生成する手段と、前記アプリケーションソケットと、前記セキュリティアソシエーションと、前記チューブアソシエーション間の前記接続に対するアソシエーションを形成する手段とを備え、これによって、前記セキュリティアソシエーションと前記チューブアソシエーションを通じて、前記リモートホストと当該装置上の前記アプリケーションソケット間の接続を確立する。
【００７４】
本発明の第３の構成に従えば、装置にロードされる場合に、本発明の第２の構成に従う装置として機能するように前記装置を制御するための動作プログラムが提供される。
【００７５】
本発明の第４の構成に従えば、装置上で実行する場合に、本発明の第１の構成に従う方法を実行するように、前記装置を制御するための動作プログラムが提供される。
【００７６】
前記動作プログラムは、搬送媒体上で実行されても良い。前記搬送媒体は、送信媒体であっても良い。前記搬送媒体は、記憶媒体であっても良い。
【００７７】
本発明の詳細説明
上述のように、ＨＩＰにおけるモビリティサポートは、ＵＰＤＡＴＥ（更新）メッセージに基づいていて、ここで、モバイルホストは、位置情報更新をピアノードへ送信する。この更新は、新規のＨＩＴとＩＰのアドレスマッピングを含んでいて、ピアホストは、このＨＩＴを使用するホストとの更なる通信のためにこのマッピングを使用する。
【００７８】
本発明の実施形態は、このプロトコルの拡張を提案し、かつチューブ（Tube）の概念をエンドホストに、そのチューブにマッピングされる各ポートとともに導入する。特定のチューブは、また、特定の接続経路、即ち、両端のあるインタフェースを介してホスト間で生成されるあるＥＳＰセキュリティアソシエーションペアへのマッピングを行う（ここでは、ＨＩＰホストが１つのインタフェースを切断していて、かつすべての接続を他のインタフェースへ変更している場合に、古いＥＳＰ  ＳＡのペアが削除されて、新規のものがその新規のインタフェースを介して生成される）。
【００７９】
本発明の実施形態では、ＩＰアドレス情報を従前に搬送しているＵＰＤＡＴＥパケットが、あるチューブＩＤに関連付けられているポート番号を搬送するためのパラメータで拡張されている。
【００８０】
図６は、第１ホスト３０と第２ホスト３２を備える、ネットワーク内の２つのホストの位置の一例を示している。第１ホスト３０はマルチホーム化ＭＮであり、第２ホスト３２はＨＩＰ  ＣＮである。マルチホーム化ＭＮ３０は、異なるアクセスネットワーク１８−１と１８−２を介して、ＨＩＰ  ＣＮ３２へ向かうインターネット２０への異なる２つの接続を有している。このＳＩＭＡドメインについては、以下で説明する。
【００８１】
基本的なＨＩＰ実装は、ノード３０とノード３２間のＥＳＰ  ＳＡネゴシエーションと、セッションキー生成を処理して、ノード３０とノード３２間でＳＡを生成する。ＨＩＰデーモン（ＨＩＰＤ）は、関連ＩＰｓｅｃデータベースにＥＳＰ  ＳＡを生成する。
【００８２】
図７は、第１ホスト３０と第２ホスト３２を備える、ネットワーク内の２つのホストの位置の別の例を示している。第１ホスト３０はマルチホーム化ＭＮであり、第２ホストがＨＩＰ  ＣＮである図６に対して、第２ホスト３２もマルチホーム化ＭＮである。第１マルチホーム化ＭＮ３０は、異なるアクセスネットワーク１８−１と１８−２（第１マルチホーム化ＭＮ  ３０のアクセスレンジを定義する）を介して、インターネット２０への２つの異なる接続を有していて、第２マルチホーム化ＭＮ３２は、異なるアクセスネットワーク１８−３と１８−４（第２マルチホーム化ＭＮ  ３２のアクセスレンジを定義する）を介して、インターネット２０への２つの異なる接続を有している。
【００８３】
図７の状況では、ホスト３０とホスト３２は、ネットワークの使用についての自身のプリファレンスを定義することができる（即ち、チューブＩＤを定義し、かつＵＰＤＡＴＥメッセージを送信すること）。このことは図６以上のものが関係している。なぜなら、ポート４２をチューブ４４へ接続すること（例えば、同一のチューブ４４を使用するために、例えば、３つのアプリケーション４０をグルーピングすること）は、他のホスト３２に対して受け入れられない可能性があるからであり、これは、いくつかのアプリケーションが自身の末端で異なる経路を使用することを必要とする可能性があり、これは、それらがＭＮ３０によって提案される方法でグループ化することができない場合である。１つのソリューションは、ホストに、チューブ接続の切断をネゴシエートすることを可能にして、あるホストに２つの同様のチューブ４４を生成して、かつそれらに別々にアプリケーション４０を接続することを可能にして、そうすることで、ピア３２（同位）の要件にマッチさせることである。ネゴシエーションによって、ポートを配置すること−一方向におけるチューブＩＤ４３と、それに応じた新規のポートのセットを配置すること−、チューブＩＤ４３をチューブ４４の必要とされる複製とともに配置することが可能となる。より関係のあるソリューションでは、１つのチューブ４４は、配下のＥＳＰ  ＳＡ３２について複数の接続を有することができる。
【００８４】
上述のように、本発明の実施形態では、新規の抽象レベルである、チューブが導入される。これは、図８を参照してより詳細に説明され、これは、マルチホーム化ＭＮ３０がＣＮ（ピアホスト）３２と通信する図６に対応するものであるが、図７の状況についても等価的に適用可能である。
【００８５】
図８は、ＣＮ（ピアホスト）３２群と通信するマルチホーム化ＭＮ３０を示している。ＭＮ３０は複数のアプリケーション４０を備えていて、また、ＭＮ３０はマルチホーム化されているので、インターネット（不図示）とＣＮ３２群とに対して複数のネットワークインタフェース４８を備えている。図８は、アプリケーション４０に関連付けられているポート群（あるいはソケット群）、チューブ４４群及びＥＳＰ  ＳＡ群４６間の関係も示している。
【００８６】
チューブ４４は、ＥＳＰ  ＳＡ４６とアプリケーションポートあるいはソケット４２間に配置されている。チューブ４４とＥＳＰ  ＳＡ４６間のリンクのように、ポートあるいはソケット４２とチューブ４４間のリンクは動的である。各チューブ４４は、チューブＩＤが割当られている。
【００８７】
エンドノード３０と３２の両方は、所与の接続のセットに対して同一のチューブＩＤを共有していて、ここでは、このチューブＩＤは、イニシエータによって生成され、かつピアノードへ送信される。チューブ４４のイニシエータは、ＨＩＰという意味では、接続のイニシエータは必要でない。ＨＩＰレスポンダは、複数の接続を有することができ、ここでは、ＨＩＰレスポンダは、ポート−チューブ−ＳＡ接続４３、４５のセットをＲ２メッセージ、あるいは後述のＵＰＤＡＴＥメッセージで送信することができる場合である。チューブアソシエーションは、一般的には、ホスト専用、あるいはノード間の１つのＨＩＰアソシエーション４６に関係するホスト間専用であり、これは、通常は、エンドホストだけに記憶されることになる。チューブＩＤは、通常は、ホストペア間で固有となる。有効なチューブＩＤのドメインは、図６及び図７で示されるように、「ＳＩＭＡドメイン」と呼ばれる（ＳＩＭＡ、同時マルチアクセス（Simultaneous Multiaccess））。
【００８８】
チューブの概念の導入は、より簡単なポリシーを使用することを可能にする。これは、ポートあるいはソケット４２のそれぞれ（接続）が、自身が所有するポリシーを持つ必要がないからである。
【００８９】
ポリシーは、接続のグループに適用されるネットワークの使用のプリファレンスを定義するルールのセットである。これらのポリシーは、システムの様々な観点に依存して様々な態様を有することができる。ポリシーエンジンの役割は、これを統一することである。アプリケーションの観点からは、アプリケーションは、特定のソケットに適用されるポリシーを生成することである。このポリシーは、以下のプリファレンスのリストとソケットをバインドする。
【００９０】
＊既知インタフェースのリスト
＊ＣＮ位置
＊ネットワークプロパティ
＊技術（ＧＰＲＳ、ＷＬＡＮ．．．）
＊帯域？
＊オペレータ？
＊ＩＰバージョン？
ポリシーが「使用」される場合、例えば、ネットワーク環境に変更があり、かつ新規のセットアップがポリシーを用いてテストされる場合、その結果としては、その時点から後に発信するデータに対して使用されることになるインタフェースが得られる。
【００９１】
固定的なポリシーと一時的なポリシーとが区別される。一時的なポリシーは、グループの接続が適用される限り存在するポリシーである。つまり、そのポリシーを使用する接続が切断されるとそれは破棄される。典型的には、これは、特定のソケットに対して、アプリケーションによって生成されるポリシーに対するものがある。一方、固定的なポリシーは、それを使用するアクティブな接続がない場合でさえも、ポリシーデータベースに存在し続ける。デフォルトのポリシーは、特定のポリシーが接続に対して生成されない場合に使用される固定的なポリシーのセットである。固定的なポリシーが通常は広範囲に渡るという事実により、接続は、いくつかのポリシーにマッチする可能性があり、これは、潜在的なポリシーの衝突を招くことになる。そのため、ポリシー間で優先付けを行う必要がある。これは、固定的なポリシーを無効にすることを許可するあるいはしないことであっても良い。
【００９２】
図８では、ポートあるいはソケット４２とチューブ４４間のアソシエーション４３と、チューブ４４とＥＳＰ  ＳＡ４６間のアソシエーション４５が示されている。各ポートあるいはソケット４２は、１つのチューブ４４に関連付けられていて、各チューブ４４は、１つのＥＳＰ  ＳＡ４６に関連付けられている。チューブ４４のそれぞれは、自身が所有するポリシーを有していて、このポリシーは、様々な状況で使用するインタフェースを定義している。つまり、アプリケーションレベルで、チューブのポリシーが知られている場合があり、アプリケーション４０は、アプリケーションの必要に応じて適切なポリシーとチューブ４４とを関連付けることができる。
【００９３】
新規のホスト３２との接続のセットアップにおいて、ＨＩＰアソシエーション４６がまだ存在していないものに対しては、新規のＨＩＰアソシエーション４６がまず通常のＨＩＰベースの交換を用いて生成される。ＥＳＰ  ＳＡ４６が生成された後、新規のチューブ４４も生成される。アプリケーション４０に対して開放されたポートあるいはソケット４２は、ここでは、この新規のチューブ４４に接続される。
【００９４】
異なるインタフェース４４を介して複数のＥＳＰ  ＳＡ４６をネゴシエートして、信頼のあるチューブ４４を前もって生成することできる。
【００９５】
ポート−チューブ４３と、チューブ−ＳＡ４５の情報は、基本的な交換中あるいはその後に、ＵＰＤＡＴＥ  ＨＩＰメッセージ（ＳＡＴＵ＿ＩＮＦＯ、ＴＵＰＯ＿ＩＮＦＯ）を使用して、新規のＨＩＰパラメータでピアノードへ通信される。
【００９６】
ＨＩＰアソシエーション４６が既に存在しているホスト３２との接続セットアップに対しては、ポリシーシステムは、このタイプの接続に対して使用される好適なチューブ４４を識別して、選択する。新規に開放されるポート４２は、チューブ４４に接続される。更新されているポート−チューブ情報４３は、新規のＨＩＰパラメータ（ＴＵＰＯ＿ＩＮＦＯ）を使用して、ピア３２へ通信される。
【００９７】
ダブルのマルチホーミングの場合、つまり、ホスト３０とホスト３２の両方がマルチホーム化されている場合、１つのホスト３０によって提案されるポート−チューブセット４３が、ピアホスト３２に対して適切でないことが発生し得る（例えば、ピアホスト３２は、これらのアプリケーションに対して異なるインタフェースを必要とする場合がある）。第１のフェーズでは、第１ホスト３０はチューブ４４の複製を生成し、チューブ４４の両方に対して同一のポリシーをコピーして、この方法で、ピアホスト３２との互換性を作成するように処理することができる。チューブ４４は複数のＥＳＰ  ＳＡ４６と同時に接続できることが可能であり（マルチ−チューブあるいはＭｕＴｕと呼ばれる）、これは、正しい宛先ＩＰアドレスがどのようにして判定されるかについてを取り扱うための、パケットマッピングポリシーが必要となる。
【００９８】
非対称リンク（異なるインタフェースを介する送受信）も、同様に、複製のチューブ４４を使用して処理することができる。ここでの違いは、ローカルポート４２が２つのチューブ４４に接続されていることであり、１つは発信トラフィックに対するものであり、もう１つは着信トラフィックに対するものである。ピア３２に対しては、着信用のチューブだけが−ポートペア４３が通信に必要とされ（ここで、ピア３２は、データを送信する）、もう一方のペア４５は、ピア３２では必要とされない。ピア３２へのパケットは、様々なソースアドレスから到来するが、ＨＩＰでは、これは問題ない。それは、パケット識別がＨＩＴに基づいているからである。
【００９９】
新規のＨＩＰパラメータに関する情報の詳細について説明する。
【０１００】
ＨＩＰ  ＵＰＤＡＴＥパケットは、交換されるＩＰアドレス情報をピアノード３２へ転送するために定義され、そうすることで、ホストは、モバイルホスト３０に対する新規のＨＩＴ−ＩＰアドレスマッピングを生成することができる。本実施形態では、ＵＰＤＡＴＥメッセージに対して、２つの極めて類似するパラメータを使用する。１つ目のパラメータは、あるチューブＩＤにローカルポート番号を結び付けることに使用され、２つ目のパラメータは、あるＳＰＩにチューブＩＤを結び付けることに使用される。
【０１０１】
このチューブ情報を新規のパラメータに含める方法には少なくとも２つ存在する。
【０１０２】
１つ目は、パラメータは、マルチホーム化ホスト３０から「有効な」ポリシー情報だけを含めることができる。これは、その情報は１つの識別子に対して複数の選択肢を含んでおらず、アクティブなものだけを含んでいることが意味している。この情報は、ＩＰｓｅｃポリシー管理に直接構成することができる。これは、おそらく、実装することはより単純となることが、潜在的な問題として、ポリシー情報が、アクティブな接続のポリシーに変更がある毎に、そのパラメータで送信されなければならないことがある。
【０１０３】
２つ目は、このパラメータは、ポリシーの基本的なセットを含むことができ、これには、各接続識別子に対する宛先インタフェースとして複数の選択肢を含んでいる。このソリューションを用いると、ポリシー情報は、上位レイヤでのポリシー管理において実際にポリシーの変更がある場合にのみ送信される必要がある。潜在的な問題としては、ＣＮ３２が切断されたインタフェースについての知識をどうにかして、即ち、受信したＩＣＭＰパケットを使用して、取得しなければならないことである。加えて、マルチホーム化ホスト３０は、ピアノード３２へ更新された情報を依然として送信しなければならない。そうでなければ、誤ったチューブ−ＥＳＰ  ＳＡのバインディング４５の情報が、依然としてピア３２に存在する可能性がある（この場合、切断された接続は再度現れることは決してない）。
【０１０４】
本実施形態では、ＴＵＰＯ＿ＩＮＦＯパラメータが、ポート−チューブマッピング４３をピアホスト３２へ送信するために使用される。各ポート４２は、チューブ４４へ接続することができ、また、１つのチューブ４４は、複数のポート４２へ接続することができる。きめの細かい接続の分離をサポートするために、ポート番号とプロトコル番号の両方が、パラメータに含められることになる。ＴＵＰＯ＿ＩＮＦＯパラメータの例が図９に示される。
【０１０５】
本実施形態では、ＳＡＴＵ＿ＩＮＦＯパラメータが、ＥＳＰセキュリティアソシエーションとチューブアソシエーション４５を送信するために使用される。チューブ４４のそれぞれは、本例では、ＳＰＩ値によって識別される、１つのＥＳＰ  ＳＡ４６に接続することができる。１つのＥＳＰ  ＳＡ４６は、それに接続される複数のチューブ４４を有することができる。ＳＡＴＵ＿ＩＮＦＯパラメータの例が図１０に示される。
【０１０６】
本発明を実現するマルチホーミングシステムは、ＵＰＤＡＴＥメッセージを用いて基本ＨＩＰシステムを利用し、複数のインタフェースの使用を、アイデンティティ／ロケータ分離アーキテクチャに結び付ける。本発明の実施形態は、ホストアイデンティティプロトコルを使用する、洗練され、かつ相対的に簡単な方法で、フローベースのモビリティ管理を提供する。ポート、プロトコル及びチューブ（新規の抽象物）についての情報をＨＩＰ  ＵＰＤＡＴＥメッセージに追加することによって、適切なフローベースのデータのルーティングに対して使用することができる、情報のセットを生成することができる。
【０１０７】
上述の構成要素の１つ以上の動作は、デバイスあるいは装置で動作するプログラムによって制御できることは明らかであろう。このような動作プログラムは、コンピュータ可読媒体に記憶することができる、あるいは例えば、インターネットウェブサイトから提供されるダウンロード可能なデータ信号のような信号に組み込むことができる。添付の請求項は、それ自身によって動作プログラム、搬送波上のレコード、信号、あるいは任意の他の形態を含むように解釈されるべきである。
【０１０８】
当業者には、本発明の実施形態が、例えば、トランスポートレイヤあるいはネットワークレイヤのような各レイヤに対して、任意の特定のプロトコルあるいはアドレッシングスキームに制限される必要はなく、また、フレームワークに関して使用されるアドレッシングあるいはトランスポートプロトコルがどんなものでも、ＨＩＰフレームワーク内で機能することを理解するであろう。
【図面の簡単な説明】
【０１０９】
【図１】ホストアイデンティティプロトコルにおける様々なレイヤを示す図である。
【図２】ＨＩＰプロトコルにおけるフォーウェイハンドシェイクの動作を示す図である。
【図３】ＨＩＰにおける論理的なパケット構造と、実際のパケット構造を示す図である。
【図４】ＩＰｖ６とＩＰｖ４間のハンドオーバを示す図である。
【図５】ＨＩＰプロキシを介して、レガシーホストとＨＩＰノード間の通信に対する一般的なネットワークセットアップを示す図である。
【図６】本発明の実施形態を説明するために使用する、ネットワークにおける２つのホストの位置の一例を示す図である。
【図７】本発明の実施形態を説明するために使用する、ネットワークにおける２つのホスト位置の別例を示す図である。
【図８】本発明の実施形態を示す図である。
【図９】本発明の実施形態のＵＰＤＡＴＥメッセージで使用される追加のパラメータを示す図である。
【図１０】本発明の実施形態のＵＰＤＡＴＥメッセージで使用される追加のパラメータを示す図である。
【図１】
2008543140.tif 000003
【図２】
2008543140.tif 000004
【図３】
2008543140.tif 000005
【図４】
2008543140.tif 000006
【図５】
2008543140.tif 000007
【図６】
2008543140.tif 000008
【図７】
2008543140.tif 000009
【図８】
2008543140.tif 000010
【図９】
2008543140.tif 000011
【図１０】
2008543140.tif 000012
【国際調査報告】
2008543140.tif 000013