JP2012517165A - ホスト・アイデンティティ・プロトコル・サーバ・アドレス構成 - Google Patents

ホスト・アイデンティティ・プロトコル・サーバ・アドレス構成 Download PDF

Info

Publication number
JP2012517165A
JP2012517165A JP2011548540A JP2011548540A JP2012517165A JP 2012517165 A JP2012517165 A JP 2012517165A JP 2011548540 A JP2011548540 A JP 2011548540A JP 2011548540 A JP2011548540 A JP 2011548540A JP 2012517165 A JP2012517165 A JP 2012517165A
Authority
JP
Japan
Prior art keywords
address
host
identity protocol
host identity
server
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.)
Granted
Application number
JP2011548540A
Other languages
English (en)
Other versions
JP5147995B2 (ja
Inventor
サルメラ，パトリック
メレン，ヤン
ユリタロ，ユッカ
Original Assignee
テレフオンアクチーボラゲット エル エム エリクソン（パブル）
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by テレフオンアクチーボラゲット エル エム エリクソン（パブル） filed Critical テレフオンアクチーボラゲット エル エム エリクソン（パブル）
Publication of JP2012517165A publication Critical patent/JP2012517165A/ja
Application granted granted Critical
Publication of JP5147995B2 publication Critical patent/JP5147995B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W8/00—Network data management
    • H04W8/02—Processing of mobility data, e.g. registration information at HLR [Home Location Register] or VLR [Visitor Location Register]; Transfer of mobility data, e.g. between HLR, VLR or external networks
    • H04W8/08—Mobility data transfer
    • 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/09—Mapping addresses
    • H04L61/10—Mapping addresses of different types
    • H04L61/103—Mapping addresses of different types across network layers, e.g. resolution of network layer into physical layer addresses or address resolution protocol [ARP]
    • 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/45—Network directories; Name-to-address mapping
    • H04L61/4535—Network directories; Name-to-address mapping using an address exchange platform which sets up a session between two nodes, e.g. rendezvous servers, session initiation protocols [SIP] registrars or H.323 gatekeepers
    • 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
    • H04L61/5061—Pools of addresses
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2101/00—Indexing scheme associated with group H04L61/00
    • H04L2101/60—Types of network addresses
    • H04L2101/668—Internet protocol [IP] address subnets
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W80/00—Wireless network protocols or protocol adaptations to wireless operation
    • H04W80/04—Network layer protocols, e.g. mobile IP [Internet Protocol]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W84/00—Network topologies
    • H04W84/005—Moving wireless networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W88/00—Devices specially adapted for wireless communication networks, e.g. terminals, base stations or access point devices
    • H04W88/18—Service support devices; Network management devices
    • H04W88/182—Network node acting on behalf of an other network entity, e.g. proxy

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Databases & Information Systems (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

【課題】移動ネットワークに接続されたホストによるホスト・アイデンティティ・プロトコル・セキュリティ手順へのアクセスを容易にする方法を提供する。
【解決手段】移動ネットワークは付加ホストにローカルＩＰアドレスを割り振る役割を担うホスト・アイデンティティ・プロトコル・サーバを含む。この方法は、ホスト・アイデンティティ・プロトコル・サーバの外部到達可能ＩＰアドレスとともに、前記ローカル・アドレスを割り振る際に前記ホスト・アイデンティティ・プロトコル・サーバによる使用のためにＩＰアドレス・プレフィックスをランデブー・サーバで登録することを含む。登録されたＩＰアドレス・プレフィックスは、受信したＩ１メッセージをホスト・アイデンティティ・プロトコル・サーバに転送するためにランデブー・サーバで使用される。ランデブー・サーバは、ローカルＩＰアドレスの衝突を防止するために、ホスト・アイデンティティ・プロトコル・サーバへのアドレス・プレフィックスの割り振り及び登録を制御する。
【選択図】図６

Description

本発明は、ホストにモビリティ・サービスを供与することに関し、特に、ホスト・アイデンティティ・プロトコル（Host Identity Protocol）を使用してこのようなサービスを供与することに関する。詳細には、本発明は、ホスト・アイデンティティ・プロトコル・サーバ・アドレス構成に関する。
ＩＰアドレスはネットワーク内のノードのトポロジ位置（topological location）を記述するものである。このＩＰアドレスはＩＰパケットをソース・ノードから宛先ノードに経路指定するために使用される。同時に、このＩＰアドレスはノードを識別するためにも使用され、従って、１つのエンティティで２通りの機能を提供する。これは、人の名前と住所が同義語になることに似ている。モビリティについても考慮すると、状況はさらに複雑になる。即ち、ＩＰアドレスはホスト識別子として作用するので、変更してはならないが、ＩＰアドレスはトポロジ位置も記述するので、ホストがネットワーク内でその位置を変えた時は必ず変更しなければならない。明らかに、安定性と動的変更の両方を当時に達成することは不可能である。
いわゆるモバイルＩＰの場合、解決策は、ノードに「ホームＩＰアドレス」を提供する固定ホーム・ロケーションを使用することである。ホームＩＰアドレスは、ノードを識別するとともに、それがホームにある時にそれに関する安定した位置を提供する。現在位置情報は「ケア・オブ・アドレス（care-of address）」の形で使用可能であり、このアドレスはそのノードがホームから離れている時に経路指定のために使用される。あるノードのホーム・ネットワークは、そのノードに（新しい）ケア・オブ・アドレスが割り振られた時に必ず更新され、パケットのホーム・アドレスにアドレス指定されたパケットを登録済みケア・オブ・アドレスに転送するという処理を行う。
モビリティ処理の問題に対するもう１つの解決策は、ホスト・アイデンティティ・プロトコル（ＨＩＰ）の提案（Ｒ．モスコウィッツ、Ｐ．ニカンダー、Ｐ．ジョケラ、「Host Identity Protocol」、インターネット・ドラフト、作業進行中、draft-ietf-hip-base-09.txt、ＩＥＴＦ、２００７年）によって提供されている。ＨＩＰは、新しい名前空間であるホスト・アイデンティティ（ＨＩ）を導入することにより、ＩＰアドレスの位置とアイデンティティの役割を分離する。ＨＩＰでは、ホスト・アイデンティティは、公開鍵と秘密鍵のペア（public-private key-pair）のうちの公開暗号鍵である。公開鍵は、秘密鍵の唯一のコピーを保有する当事者を識別するものである。鍵のペアのうちの秘密鍵を処理するホストは、ネットワーク内でそれを識別するために使用される公開鍵を「所有」していることを直接的に証明することができる。
ＨＩＰホスト・アイデンティティ（ＨＩ）は、公開鍵であり、非常に長くなる可能性がある。従って、ＨＩをハッシュすることによってそのＨＩから生成される長さ１２８ビットのホスト・アイデンティティ・タグ（ＨＩＴ）で表される場合が多い。従って、ＨＩＴはＨＩを識別する。ＨＩＴは長さ１２８ビットであり、ＩＰｖ６アドレスとまったく同じ長さであるので、ＩＰｖ６アプリケーションに直接使用することができる。
アプリケーションは典型的に、（ピア）ノードの位置に関心がないが、ピアのアイデンティティを把握する必要がある。このアイデンティティはＨＩＴによって表される。これは、経路指定が関係する下位層についてのみＩＰアドレスが重要であることを意味する。アプリケーションが使用するＨＩＴは、当然のことながら、任意のパケットがノードを離れる前に対応するＩＰアドレスにマッピングしなければならない。これは、以下に説明するように、新しいホスト・アイデンティティ層で達成される。
添付図面のうちの図１は、標準的なトランスポート層４、ネットワーク層８、及びリンク層１０を含み、プロセス２がその下にあるトランスポート層４と通信している、ＨＩＰベースのプロトコル・アーキテクチャ内の様々な層を示している。新しいホスト・アイデンティティ層６は、トランスポート層４とネットワーク層８との間に配置されている。ホスト・アイデンティティ層の主要な役割は、ＨＩＴとＩＰアドレスとのマッピングを行うことである。上位層から到着する各パケットは、宛先アドレスとしてピア・ノードのＨＩＴを含む。ホスト・アイデンティティ層は宛先ＨＩＴを適切な宛先ＩＰアドレスで置き換え、ソースＨＩＴは適切なソースＩＰアドレスに変換される。
ＨＩＰは、４通りのメッセージを含む基本メッセージ交換、即ち、４ウェイ・ハンドシェークを定義し、これは、ＨＩＰ対応ノード間にセキュリティ・アソシエーション（ＳＡ）を作成するために使用される。メッセージ交換中に、ディフィー・ヘルマン手順を使用して、セッション鍵を作成し、ノード間に１対のＩＰＳｅｃカプセル化セキュリティ・ペイロード（ＥＳＰ）セキュリティ・アソシエーション（ＳＡ）を確立する。添付図面のうちの図２は、４ウェイ・ハンドシェークを示している。交渉している当事者は、接続を開始する「イニシエータ（Initiator）」と、「レスポンダ（Responder）」と呼ばれる。イニシエータは、交渉に関与しているノードのＨＩＴを含むＩ１パケットを送信することによって交渉を開始する。レスポンダは、Ｉ１パケットを受信すると、イニシエータが解くべきパズルを含むＲ１パケットを返送する。このプロトコルは、パズル解答中の計算のほとんどをイニシエータが行わなければならないように設計されている。これは、サービス不能（ＤｏＳ）攻撃に対する何らかの保護になる。Ｒ１は、ディフィー・ヘルマン・パラメータとともにレスポンダの公開鍵を含む、ディフィー・ヘルマン手順も開始する。
Ｒ１パケットが受信されると、イニシエータは、パズルを解き、ＩＰＳｅｃ ＳＰＩ値とその暗号化した公開鍵とともにＩ２パケットに入れて応答クッキーをレスポンダに送信する。レスポンダは、パズルが正しく解かれていることを検証し、イニシエータを認証し、ＩＰＳｅｃ ＥＳＰ ＳＡを作成する。最後のＲ２メッセージはレスポンダのＳＰＩ値を含む。
ピア・ノード間のＳＡは、ＨＩＴによって表されるホスト・アイデンティティに拘束される。しかし、ネットワーク内を移動するパケットは実際のＨＩ（ＨＩＴ）情報を含まず、むしろ、ＥＳＰヘッダ内のセキュリティ・パラメータ・インデックス（ＳＰＩ）値を使用して、到着パケットが識別され、正しいＳＡにマッピングされる。添付図面のうちの図３は、ネットワーク内を移動するパケットの論理的なパケット構造と実際のパケット構造を示している。
出力パケットが上位層からＨＩ層に到着すると、宛先ＨＩＴがＩＰＳｅｃ ＳＡＤＢから検証される。宛先ＨＩＴと一致するＳＡが見つかった場合、そのＳＡに関連するセッション鍵を使用してパケット・ペイロードが暗号化され、ソース及び宛先ＨＩＴに関するパケットＩＰヘッダにソース及び宛先ＩＰアドレスが代入される。受信側ホストでは、ＳＰＩ値を使用して、ＩＰＳｅｃ ＳＡＤＢから正しいＳＡを見つける。ある項目が見つかった場合、ソース及び宛先ＩＰアドレスを対応するＨＩＴに変更することができ、セッション鍵を使用してそのパケットを復号することができる。
ＨＩＰを実装していないレガシー・ノードがＨＩＰの追加のセキュリティ上の恩恵をある程度利用できるようにするために、ＨＩＰプロキシを導入するための提案が行われた。ＨＩＰプロキシの使用については、例えば、ＷＯ０５０８１４６６及びＷＯ０５０１７５３で考慮され、図４に示されているが、同図ではレガシー・ホスト１２は、ＨＩＰプロキシ１６を介してＨＩＰ対応ノード１４と通信するものとして示されている。レガシー・ホスト１２はアクセス・ネットワーク１８によりＨＩＰプロキシ１６にアクセスし、ＨＩＰプロキシ１６はインターネット２０によりＨＩＰノード１４にアクセスする。レガシー・ホスト１２とＨＩＰノード１４との間の接続を部分的に保護するために、ＨＩＰプロキシ１６とＨＩＰノード１４との間のすべての通信は、上述のものと同様の方法でＨＩＰプロキシ１６とＨＩＰノード１４との間にセットアップされたセキュリティ・アソシエーション２２を使用する。ＨＩＰプロキシを要する特定使用のケースは、ＧＰＲＳアクセス・ネットワーク１８を使用するレガシー２Ｇ又は３Ｇワイヤレス・モバイル端末になる可能性がある。ＨＩＰプロキシは、有利なことに、ＧＰＲＳネットワークのＧＧＳＮと同じ場所に位置する。図４に示されているその他のコンポーネントは、ＤＮＳサーバ２４−１及び２４−２とフォワーディング・エージェント（Forwarding Agent）２６である。
ピア・ノードと通信することを希望し、そのピア・ノードのＨＩＴしか把握していないノードは、当然のことながら、そのピアに関するＩＰアドレスを入手しなければならない。ホスト・アイデンティティ層は、いくつかの方法で、例えば、ＤＮＳサーバを使用して、ＨＩＴとＩＰアドレスとのマッピングを入手することができる。ＤＮＳサーバ側に保持されている所与のノードに関する位置情報は、そのノードによっていつでも更新することができる。
ＤＮＳベースのルックアップ手順に関する問題は、インターネットにより新しいデータを更新する時のＤＮＳシステムの待ち時間を含む。ＤＮＳは、数時間又は数日間の間、データをキャッシュすることができるキャッシュ・メカニズムを使用し、従って、ＤＮＳは、非常に頻繁に行われる更新を効率よく処理することができない。ＤＮＳに保管されたアドレスは長く続くものと予想され、従って、ＤＮＳシステムはモビリティを処理するのに適していない。
インターネット技術標準化委員会（ＩＥＴＦ）は、「ランデブー・サーバ（rendezvous server）」（ＲＶＳ）として知られる新しいネットワーク・エンティティを指定した。ＲＶＳはそのクライアントに初期接触点を提供するものである。ＲＶＳのクライアントは、自分のＨＩＴとＩＰアドレスとのマッピングをＲＶＳに登録するためにＨＩＰ登録プロトコルを使用するＨＩＰノードである。登録後、その他のＨＩＰノードは、自分が接触しようと試みているノードの現行ＩＰアドレスの代わりにＲＶＳのＩＰアドレスを使用して、基本交換（Ｉ１メッセージ）を開始することができる。Ｉ１メッセージ内に含まれるものは宛先ノードのＨＩＴである。ＲＶＳは、宛先ＨＩＰノードのＩＰアドレスを決定し、Ｉ１メッセージをそのアドレスに転送する。このようにして、ＲＶＳのクライアントはＲＶＳのＩＰアドレスを介して到達可能になる。
ＲＶＳは、（ＩＰ）アクセス・ネットワークに対する１つ又は複数の接続ポイント（point of attachment）を有する移動ネットワーク（moving network）にＨＩＰノードが接続される移動ネットワーク・トポロジの導入を容易にする。移動ネットワーク内にＨＩＰモバイル・ルータを導入することにより、ＲＶＳはＨＩＰノードの現在位置で連続的に更新することができ、同時に位置更新関連信号通知が最小限になる。従来の手法により、ノードはＲＶＳに登録するためにＨＩＴを備えていなければならないので、ＲＶＳ及びＨＩＰモバイル・ルータを使用しても、それだけで移動ネットワーク内のレガシー・ホストがＨＩＰベースのセキュリティを利用できるようにはならない。
移動ネットワークに接続されたレガシー・ホストがＨＩＰベースのモビリティ及びセキュリティを利用できるようにするための手段を提供することが望ましい。これは、移動ネットワーク内のＨＩＰプロキシとＲＶＳシステムを使用することによって達成することができ、それにより、プロキシはそれが担当するＩＰアドレス・プレフィックス又は一時的ＨＩＴを登録し、レガシー・ホストに関するＩ１パケットがＲＶＳシステムに送信され、そのＲＶＳシステムがそれらを担当のＨＩＰプロキシにリダイレクトする。
ＨＩＰプロキシの移動サブネットワーク用のアドレスを構成する明白な方法は、プライベート・アドレス空間（例えば、１９２．１６８．０．０／１６）を使用し、その空間をＨＩＰプロキシ間で分割することである。これには手動構成が必要であり、ＨＩＰプロキシ管理者には使用することが許可されているプレフィックスが通知される。当然のことながら、これが適切に行われないか又は新しいプロキシがＲＶＳに加わった場合、プレフィックス衝突が発生する可能性があり、例えば、２つのプロキシがそれぞれのサブネットワーク内で１９２．１６８．２．０／２４アドレスを提供しようと決定する可能性がある。そのプレフィックス（例えば、１９２．１６８．２．５）に属すアドレスについて複数の一致が存在する可能性があるので、これはＲＶＳ内で問題を発生することになる。
しかし、ＩＰアドレス衝突の問題はレガシー・ホスト及びＨＩＰプロキシに限定されず、ＨＩＰホストがＨＩＰモバイル・ルータの後に位置する場合、特に、２つ又はそれ以上のネストされたＨＩＰモバイル・ルータの後に位置する場合も発生する可能性がある。
本発明の第１の態様により、移動ネットワークに接続されたホストによるホスト・アイデンティティ・プロトコル・セキュリティ手順へのアクセスを容易にする方法が提供され、移動ネットワークは付加ホスト（attached host）にローカルＩＰアドレスを割り振る役割を担うホスト・アイデンティティ・プロトコル・サーバを含む。この方法は、ホスト・アイデンティティ・プロトコル・サーバの外部到達可能ＩＰアドレス（externally reachable IP address）とともに、前記ローカル・アドレスを割り振る際に前記ホスト・アイデンティティ・プロトコル・サーバによる使用のためにＩＰアドレス・プレフィックスをランデブー・サーバで登録することを含む。登録されたＩＰアドレス・プレフィックスは、受信したＩ１メッセージをホスト・アイデンティティ・プロトコル・サーバに転送するためにランデブー・サーバで使用される。ランデブー・サーバは、ローカルＩＰアドレスの衝突を防止するために、ホスト・アイデンティティ・プロトコル・サーバへのアドレス・プレフィックスの割り振り及び登録を制御する。
この手法は、前記ホスト・アイデンティティ・プロトコル・サーバがホスト・アイデンティティ・プロトコル・プロキシであり、前記ホストがレガシー・ホストである場合に適用可能である。この場合、この方法は、前記ＩＰアドレス・プレフィックス及びＨＩＰプロキシのパブリック・アドレス（複数も可）とともに、前記ホスト・アイデンティティ・プロトコル・サーバのホスト・アイデンティティ又はホスト・アイデンティティ・タグをランデブー・サーバで登録することを含むことができる。
この手法は、前記ホスト・アイデンティティ・プロトコル・サーバがホスト・アイデンティティ・プロトコル・モバイル・ルータであり、前記ホストがＨＩＰホストである場合にも適用可能である。
ランデブー・サーバは、ＩＰアドレス・プレフィックスのプールから割り振られていないＩＰアドレス・プレフィックスを選択し、登録側ホスト・アイデンティティ・プロトコル・サーバについて選択されたプレフィックスを登録し、登録側ホスト・アイデンティティ・プロトコル・サーバに選択され登録されたＩＰアドレス・プレフィックスを通知することにより、ホスト・アイデンティティ・プロトコル・サーバへのアドレス・プレフィックスの割り振り及び登録を制御することができる。
代わって、ランデブー・サーバは、登録側ホスト・アイデンティティ・プロトコル・サーバから提案されたＩＰアドレス・プレフィックスを受信し、すでに登録されたプレフィックスに基づいてその提案を受諾するか又は拒否することにより、ホスト・アイデンティティ・プロトコル・サーバへのアドレス・プレフィックスの割り振り及び登録を制御することができる。ランデブー・サーバによる提案されたＩＰアドレス・プレフィックスの拒否後、この方法は、代替プレフィックスをホスト・アイデンティティ・プロトコル・サーバで選択することと、これをランデブー・サーバに送信することをさらに含む。
ランデブー・サーバは１組の協働ランデブー・サーバのうちの１つにすることができ、これらのランデブー・サーバはランデブー・サーバ間のＩＰアドレス・プレフィックス衝突を防止するために割り振られたＩＰアドレス・プレフィックスを識別するデータを交換する。
本発明の第２の態様により、ホスト間のセッションを確立するためにランデブー・サーバとして動作するように構成された装置が提供される。この装置は、登録データベースと、ホスト・アイデンティティ・プロトコル・サーバから登録要求を受信するための受信機とを含み、サーバは付加ホストにローカルＩＰアドレスを割り振る役割を担う。ホスト・アイデンティティ・プロトコル・サーバの外部到達可能ＩＰアドレスとともに、前記ローカル・アドレスを割り振る際に前記ホスト・アイデンティティ・プロトコル・サーバによる使用のためにＩＰアドレス・プレフィックスを前記登録データベースで登録することにより、登録要求の受信に応答するための登録ユニットが提供される。この装置は、登録されたＩＰアドレス・プレフィックスを使用して受信したＩ１パケットをホスト・アイデンティティ・プロトコル・サーバに転送するためのメッセージ処理ユニットをさらに含む。登録ユニットは、ローカルＩＰアドレスの衝突を防止するために、ホスト・アイデンティティ・プロトコル・サーバへのアドレス・プレフィックスの割り振り及び登録を制御するように構成される。
登録ユニットは、ＩＰアドレス・プレフィックス・プール内から割り振られていないＩＰアドレス・プレフィックスをホスト・アイデンティティ・プロトコル・サーバに割り振ることにより、ホスト・アイデンティティ・プロトコル・サーバへのアドレス・プレフィックスの割り振り及び登録を制御するように構成することができ、この装置は、割り振られたＩＰアドレス・プレフィックスをホスト・アイデンティティ・プロトコル・サーバに送信するための送信ユニットをさらに含む。
登録ユニットは、ホスト・アイデンティティ・プロトコル・サーバによって提案されたＩＰアドレス・プレフィックスを前記登録要求内で識別し、そのプレフィックスが他のホスト・アイデンティティ・プロトコル・サーバについて登録されている場合にそのプレフィックスを拒否することにより、ホスト・アイデンティティ・プロトコル・サーバへのアドレス・プレフィックスの割り振り及び登録を制御するように構成することができる。詳細には、登録ユニットは、提案されたＩＰアドレス・プレフィックスを拒否した時に、代替の使用可能なプレフィックスをホスト・アイデンティティ・プロトコル・サーバに送信するか又はサーバからの代替提案を考慮するようにさらに構成することができる。
登録ユニットは、ランデブー・サーバ間のＩＰアドレス・プレフィックス割り振り衝突を防止するために割り振られたＩＰアドレス・プレフィックスを識別するデータを他の関連ランデブー・サーバと交換するように構成することができる。
ホスト・アイデンティティ・プロトコル・サーバは、ＩＰアドレスをクライアントに提供する役割を担う任意のＨＩＰ対応ノード、例えば、ホスト・アイデンティティ・プロトコル・プロキシ又はホスト・アイデンティティ・プロトコル・モバイル・ルータにすることができる。
本発明の第３の態様により、サブネットワーク内のホスト・アイデンティティ・プロトコル・クライアント及び／又はレガシー・ホストに対応するホスト・アイデンティティ・プロトコル・サーバとして動作するように構成された装置が提供される。この装置は、ホスト・アイデンティティ・プロトコル・サーバの外部到達可能ＩＰアドレスとともに、サブネットワーク内でローカルＩＰアドレスを割り振る際に前記ホスト・アイデンティティ・プロトコル・サーバによる使用のためにＩＰアドレス・プレフィックスをランデブー・サーバで登録するための登録ユニットを含み、登録ユニットは登録されたＩＰアドレス・プレフィックスをランデブー・サーバから受信するように構成される。
前述の通り、ホスト・アイデンティティ・プロトコル内の様々な層を示す図である。 同じく前述の通り、ＨＩＰプロトコル内の４ウェイ・ハンドシェークの動作を示す図である。 同じく前述の通り、ＨＩＰ内の論理的なパケット構造及び実際のパケット構造を示す図である。 同じく前述の通り、ＨＩＰプロキシを介してレガシー・ホストとＨＩＰモードとの間の通信のための一般ネットワーク・セットアップを示す概略図である。 レガシー・ホストがＨＩＰプロキシを含む移動ネットワークに付加されるシナリオを概略的に示す図である。 ＨＩＰプロキシとＲＶＳとの間の登録信号交換を示す図である。 新しいＨＩＰプロキシの登録後のＲＶＳ間の登録データの交換を示す図である。 ＨＩＰプロキシ用の登録プロセスを示す流れ図である。 ＨＩＰプロキシを登録するようになっているランデブー・サーバを概略的に示す図である。 ＨＩＰプロキシを概略的に示す図である。 図５のシナリオに関連するモビリティ関連信号通知の流れを示す図である。
ＩＰネットワークに実質的に連続的に接続される移動ネットワークの供与を容易にするための作業が進行中である。移動ネットワークの一例は、同じ移動車両内又は人の身体上に存在する相互接続デバイスの集合である可能性がある。このような移動ネットワークは固定アクセス・ポイントを介してＩＰネットワークに接続するが、そのアクセス・ネットワークのアイデンティティは典型的に、ネットワークが移動するにつれて変化する。ネットワークが移動した時にネットワーク内のデバイスが到達可能のままでいられるようにするために、位置アドレス（即ち、ＩＰアドレス）に対する変更を信号通知するための何らかのメカニズムを実装しなければならない。移動ネットワークをサポートするための解決策の１つはＩＥＴＦ ＮＥＭＯ提案である。ＮＥＭＯは、ネットワーク・デバイスからネットワーク・モビリティを効果的に隠すモバイル・ルータを移動ネットワークに導入するものである。このモバイル・ルータは、ピア・ノードに位置アドレス更新を送信する役割を担う。
ＮＥＭＯに代わるものとして、ＨＩＰモバイル・ルータを移動ネットワーク（又は「サブネットワーク」）に導入することによりＨＩＰベースの移動ネットワークを実装することが可能である。ＨＩＰモバイル・ルータは、サブネットワーク内のＨＩＰノードに代わってモビリティ関連信号通知を処理する役割を担う。モビリティ関連信号通知権をＨＩＰモバイル・ルータに委任することにより、ＨＩＰノードは、サブネットワークの移動による影響を受けなくなり、それ自体がモビリティ関連信号通知を実行する必要が無くなる。しかし、この手法は、ＨＩＰを利用するために、サブネットワーク内のデバイスがＨＩＰノードであることを要求する。レガシー・ノードはＨＩＰモバイル・ルータを使用することができない。
上述の通り、レガシー・ホストがＨＩＰの追加のセキュリティ上の恩恵を少なくとも限られた範囲で利用できるようにするために、ＨＩＰプロキシを使用することは可能である。安定した到達可能アドレスをノードに提供するために、ＨＩＰプロキシは、（ピア）ＨＩＰノードに関する現行ＩＰアドレスを入手するためにＤＮＳ照会を実行することができる。従って、ＨＩＰプロキシは、移動ネットワークを使用可能にするための代替メカニズムを提供し、その上、ＨＩＰベースのネットワーク・モビリティをレガシー端末に提供する。しかし、さらに良好な手法は、ＨＩＰプロキシの使用とＩＥＴＦによって提案されたＲＶＳメカニズムとを組み合わせることである。これについては以下に説明する。
図５は、レガシー・ノード１００が移動ネットワーク１０１に接続されるシナリオを示している。移動ネットワークは、例えば、ＷＬＡＮネットワークにすることができるであろう。移動ネットワークは、（ＷＬＡＮ）ルータ１０３と同じ場所に位置するＨＩＰプロキシ１０２をさらに含む。ルータ１０３は移動ネットワーク１０１をＩＰネットワーク・アクセス・ポイント１０４に接続する。移動ネットワークが移動すると、それは、あるアクセス・ポイントから他のアクセス・ポイントにハンドオフされる。アクセス・ポイント１０４はＩＰネットワーク１０５へのアクセスを可能にするものであり、そのＩＰネットワークはインターネットであるか又はインターネットを含むことができる。図５は、ＨＩＰプロキシ１０８、ルータ１０９、及びアクセス・ポイント１１０を介して第２の移動ネットワーク１０７に同様に接続されるピア・レガシー・ノード１０６を示している。
ランデブー・サーバ（ＲＶＳ）１１１は、ＩＰネットワーク内に位置し、ＨＩＰについて規定されたＩＥＴＦ ＲＶＳの機能性を実装するものである。即ち、ＲＶＳ１１はＨＩＰノード用の合流点を提供する。しかし、ＲＶＳには、以下に説明するように追加の機能性が提供される。
ＨＩＰプロキシ１０２、１０８は、それぞれのモバイル・ネットワーク内のノードに提供されたＩＰアドレスを認識しているものと想定する。これらはＩＰｖ４及び／又はＩＰｖ６アドレスである可能性がある。詳細には、ＨＩＰプロキシは、そのネットワーク内で使用されるＩＰアドレス・プレフィックス（複数も可）並びに使用可能なアドレス空間から使用中の特定のアドレスを把握している（又は決定することができる）。ＲＶＳは、パブリックで経路指定可能なアドレスである可能性がない（しかし、それにもかかわらず、固有のものである）（ローカルに割り振られた）ＩＰアドレスを使用して、移動ネットワーク内のレガシー・ホストがネットワークの外側から到達可能になるようにするために使用される。
所与のモバイルＨＩＰプロキシによって使用されるアドレス・プレフィックス（複数も可）は、ＨＩＰ ＲＶＳシステムで、特に、ＲＶＳシステムのデータベース１１２内に登録しなければならない。［ＲＶＳシステムは、例えば、何らかの階層ＲＶＳ構造、ＤＨＴベースのＲＶＳシステム、又は単に正規のＲＶＳである可能性がある。］図６の信号通知図（以下に詳述する）に関して説明すると、１対のＨＩＰプロキシ（ＨＩＰプロキシａ及びＨＩＰプロキシｂ）についてステップ１及び２で登録が実行される。ＨＩＰプロキシについてアイデンティティ［ＨＩＴ（ａ）］及び現行ロケータ［ＩＰ（ａ）］のみを登録する代わりに、ＲＶＳはプロキシのサブネットワーク内で使用されるプレフィックス（複数も可）及び／又はサブネットワーク内で使用されるアドレスのリストも登録しなければならないので、これは、現行のＲＶＳ指定に対する拡張部分を表している。ＲＶＳを使用してレガシー・ホストの位置を突き止めようと試みる場合、レガシー・ホストのＩＰアドレスをＲＶＳシステム内の任意の項目のプレフィックスと突き合わせることが必要である。一致が見つかると、対応するＲＶＳ項目は、そのレガシー・ホストに接触するために使用できるＨＩＰプロキシ（ＩＰアドレス及びＨＩＴ／ＨＩ）を識別する。
ＨＩＰプロキシ登録手順についてさらに考慮すると、可能であればＨＩＰプロキシ間のアドレス衝突を回避することが重要である。これは、ＨＩＰプロキシの後ろにあるサブネットワークが「プライベート」アドレス空間を使用する場合でも、ＲＶＳがＩＰアドレス・プレフィックスをＨＩＰプロキシに割り振れるようにすることによって達成することができる。
初めてＲＶＳに登録するＨＩＰプロキシについて考慮する。この場合、そのプロキシによって処理されている既存の接続は存在しないので、ＲＶＳは単に、そのサブネットワーク内で使用しなければならないプレフィックスを登録側ＨＩＰプロキシに通知することができる。これは、ＨＩＰプロキシがそのプレフィックスを選択し、その選択をＲＶＳに通知する代わりに、そのプレフィックスがＲＶＳによって割り振られ、ＨＩＰプロキシに与えられることを意味する。これにより、ＲＶＳは、それに登録されたすべてのＨＩＰプロキシを管理し、プレフィックス衝突を回避することができる。ＨＩＰプロキシは、サブネットワーク内で使用すべきプレフィックスを受信し、それをそのクライアントに宣伝する。これは、まだアクティブ接続が存在しない間であってＨＩＰプロキシが初めてＲＶＳに登録する時だけ行われるので、サブネットワーク内のクライアントは本質的に影響を受けない。
図６は、ＨＩＰプロキシとＲＶＳとの間の登録信号交換を示している。この交換は、ＩＥＴＦ ＲＦＣ５２０３に定義された登録交換を使用することができる。
ＲＶＳがリング構造又は階層構造に編成された場合、オーバラップを回避するためにＲＶＳ間でＩＰアドレス・プレフィックスを割り当てなければならない。次にＲＶＳは、割り振られたプレフィックスをそれに接続されたＨＩＰプロキシにさらに分割することができる。代替手法は、各ＲＶＳが、それがＨＩＰプロキシにプレフィックスを割り振る時にその他の接続されたＲＶＳに通知することである。この手法では、ＲＶＳは共通プールからプレフィックスを割り振る。これについては図７に示されている。
図８は、登録及びメッセージ処理手順をさらに示す流れ図である。このプロセスはステップ１００から始まり、ステップ１０１でＨＩＰプロキシが登録要求をＲＶＳに送信する。ステップ１０２でこのメッセージがＲＶＳによって受信される。ステップ１０３では、ＲＶＳは、プレフィックスの使用可能なプールから、ＨＩＰプロキシのために、割り振られていないＩＰアドレス・プレフィックスを選択する。ステップ１０４では、ＲＶＳは、ＨＩＰプロキシのＩＰアドレス（及びＨＩ／ＨＩＴ）（及び上述のその他のデータ）とともに、割り振られたプレフィックスをそのデータベースに登録する。ステップ１０５で、選択されたプレフィックスもＨＩＰプロキシに送信される。その後、ステップ１０６では、そのプレフィックスを含むＩＰアドレス向けのＩ１メッセージをＲＶＳが受信すると、ＲＶＳはＨＩＰプロキシ用の接触アドレス（及びＨＩ／ＨＩＴ）を識別することができ、そのアドレスにメッセージを転送することができる。このプロセスはステップ１０７で終了する。
プレフィックス衝突の問題に対する代替の解決策は、他のＨＩＰプロキシによって（全体的に又は部分的に）すでに登録されたプレフィックスをＨＩＰプロキシが登録しようと試みた時にＲＶＳがそのＨＩＰプロキシに通知できるようにすることである。このような試みが検出された場合、ＨＩＰプロキシは新しいプレフィックスを選択し、代わりにこの新しいプレフィックスを登録しようと試みなければならない。［当然のことながら、この結果として、攻撃者がＲＶＳノードになりすまし、すべてのプレフィックスが予約されているとＨＩＰプロキシに通知するというサービス不能（ＤｏＳ）タイプの攻撃が行われる可能性がある。］代替プレフィックスを提案することをＨＩＰプロキシに要求するのではなく、衝突が発生した場合に、ＲＶＳは、ＲＶＳによって保持された他のＨＩＰプロキシの登録情報に基づいて、新しい（空いている）プレフィックスをＨＩＰプロキシに示唆することができる。
図９は、上述のようにＨＩＰプロキシの登録を処理するように構成されたランデブー・サーバ（ＲＶＳ）１を概略的に示している。ＲＶＳ１は、ＨＩＰプロキシから登録要求を受信するための受信機２を含む。要求は、登録ユニット３に渡され、それによって処理される。特に、一実施形態では、登録ユニット３は、（プレフィックスのプールから）ＩＰアドレス・プレフィックスを登録側ＨＩＰプロキシに割り振り、ＨＩＰプロキシの外部アクセス可能ＩＰアドレス及びＨＩ／ＨＩＴとともに、これをデータベース４に登録する。登録ユニット３は送信ユニット５を使用して、選択されたＩＰアドレス・プレフィックスをＨＩＰプロキシに通知する。ＨＩＰプロキシの後ろにあるレガシー端末向けのその後のＩ１メッセージはメッセージ処理ユニット６によって処理される。このユニットは、データベース４内の宛先端末のＩＰアドレス・プレフィックスをルックアップし、ＨＩＰプロキシの識別されたＩＰアドレスにそのメッセージを転送する。図１０は、その割り振られたＩＰアドレス・プレフィックス及び接触ＩＰアドレス（及びＨＩ／ＨＩＴ）をＲＶＳに登録するための登録ユニット１１を有するＨＩＰプロキシ１０を示している。
次に、ＨＩＰプロキシ（ａ）の後ろにあるレガシー・ホスト（ｘ）が他のＨＩＰプロキシ（ｂ）の後ろにあるピア・レガシー・ホスト（ｙ）に接続したいと希望するケースについて考慮する。ホスト（ｘ）はまずピア・ホストのロケータを把握する必要がある。この情報をどのように入手するかについてはここでは詳細に考慮しないが、既存のＤＮＳシステムを使用することが可能であると思われる。図１１に示されている信号通知についてさらに考慮すると、レガシー・ホスト（ｘ）は、正規パケット（例えば、ＴＣＰ ＳＹＮ）をピアに送信することによって（ＩＰ（ｘ）−＞ＩＰ（ｙ））、ピア・ホスト（ｙ）とのセッションを開始する。そのパケット内に含まれるソース及び宛先ＩＰアドレスは、プライベート又はパブリックのＩＰアドレスにすることができる。ＨＩＰプロキシ（ａ）は、そのパケットをインターセプトし、そのＩＰアドレス対についてすでにＨＩＰ関連付けが存在するかどうかをチェックする。存在する場合、パケットはその関連付けによって送出される。２つのプロキシ間にすでにＨＩＰ関連付けが存在するが、レガシー・ホストが異なる場合、そのプロキシ間で完全なＩＰパケットがトンネリングされるので、そのＨＩＰ関連付けは依然として新しい接続に使用することができる。そうではない場合、プロキシは、宛先アドレスＩＰ（ｙ）が属すプレフィックスをどのプロキシが持っているかをすでに把握しているかどうかを確認するためのチェックを行う。この情報が見つかった場合［ＩＰ（ｂ），ＨＩＴ（ｂ）］、図２の４ウェイ・ハンドシェークにより、２つのプロキシ間でＨＩＰ関連付けを確立するためにそれを直接使用することができる。しかし、使用可能な関連付けがまだ存在せず、ＨＩＰプロキシ（ａ）がピア・プロキシに関する情報を持っていない場合、それは、以下に説明するように、ＲＶＳシステムを利用して新しいＨＩＰ関連付けを確立する。
ＨＩＰプロキシ（ａ）は、ＲＶＳシステムに日和見モード（opportunistic mode）でＩ１パケットを送出し、即ち、宛先ＨＩＴフィールド（即ち、知られていればＨＩＴ（ｂ）が存在する場所）は空のままになる（ステップ４）。ＩＰパケット・ヘッダ内の宛先アドレスはＲＶＳのアドレスであるが、宛先レガシー・ホストＩＰ（ｙ）のＩＰアドレスはＩ１パケット・ペイロードに含まれ、そのため、この情報はＲＶＳ内の正しいピアＨＩＰプロキシ項目を突き止めるためにＲＶＳが使用することができる。Ｉ１パケットを受信すると、ＲＶＳは、ＩＰ（ｙ）のプレフィックスと一致するプレフィックスを含む項目を識別し、その項目から、ＨＩＰプロキシ（ｂ）のＨＩＴ及びそのＩＰアドレスＩＰ（ｂ）を識別する。次に、ＲＶＳはＨＩＴ（ｂ）をＩ１パケットに挿入し、そのパケットが転送される前に、そのパケットの宛先がＩＰ（ｂ）に変更される（ステップ５）。
ピアＨＩＰプロキシは、Ｉ１パケットを受信すると、通常通り、Ｒ１パケットで応答する。しかし、それは、それがサブネットワーク内で対応しているＩＰアドレス・プレフィックスをパケット内に含める。Ｒ１パケットは発信側ＨＩＰプロキシに直接送信され、次にそのＨＩＰプロキシは、ピア・プロキシのＨＩＴ及びＩＰアドレスと、そのピア・プロキシが対応しているプレフィックスも学習する（ステップ６）。［この学習したプレフィックスは、例えば、異なる１対のレガシー・ホストについて、２つのサブネットワーク間で新しい接続を確立する必要がある時に、後で使用することができる。］次に発信側ＨＩＰプロキシがＩ２パケットで応答する場合、それはそのプロキシが対応しているサブネットワークのプレフィックスを含み、そのため、両方のプロキシが完全な情報を所有することになる（ステップ７）。ＨＩＰ基本交換は、２つのプロキシ間でＨＩＰ関連付けを確立するために、通常通り、続行する（ステップ８）。この時点でＨＩＰトンネルはセットアップされており、データ・パケットはＨＩＰトンネルを通ってレガシー・ホスト間を流れることができる（ステップ９〜１１）。完全なＩＰパケットはＨＩＰプロキシ間のＩＰ−ｉｎ−ＩＰトンネル内をトンネリングされ、宛先プロキシで受信されると、元のＩＰパケットがアンパックされ、元のＩＰアドレスで宛先サブネットワーク内に送信される［ＩＰ（ｘ）−＞ＩＰ（ｙ）］。
次に、移動ネットワーク内にあってＨＩＰプロキシの後ろにあるレガシー・ホストとのＨＩＰ保護セッションをＨＩＰホストが確立しようと努めるケースについて考慮すると、この手順は上述のものと同様である。ＨＩＰホストはＩ１パケットを日和見モードでＲＶＳに送信する。ＨＩＰホストは、レガシー・ホストのＩＰアドレスをＩ１メッセージに含めなければならない（これは変更されたＩ１パケットを必要とする）。ＲＶＳは、レガシー・ホストのＩＰアドレスを使用して担当のＨＩＰプロキシを決定し、ＨＩＰプロキシにＩ１を転送する。開始側ＨＩＰホストはＨＩＰプロキシからＲ１応答を受信し、それによりプロキシのＩＰアドレス及びＨＩＴ並びにそのプロキシが担当するＩＰアドレス・プレフィックスを学習する。当然のことながら、ＨＩＰホストはプレフィックスを担当せず、従って、それ自体のＩＰアドレスのみをＩ２に含める。その後、交換は通常通り完了する。
その後、データ・パケットを送信する時に、ＨＩＰホストはＩＰ−ｉｎ−ＩＰトンネル内にパケットをカプセル化する（また、受信する時にカプセル化解除する）必要がある。ＨＩＰホストは、それ自体のアドレスとレガシー・ホストのアドレスに対応するソース及び宛先ＩＰアドレスでプレーン・データ・パケットを作成する。このパケットは、出力ＨＩＰパケット用のペイロードとして使用され、（正規ＨＩＰのように）まずＩＰヘッダ内にＨＩＴを有し、次にＨＩＰホスト及びＨＩＰプロキシのＩＰアドレスに変換される。
ＨＩＰホストへの接続を開始するのがレガシー・ホストである場合、レガシー・ホストからレガシー・ホストへの接続に使用されたものと同じ手順が使用される。即ち、プロキシから送信されるＩ１パケット（プロキシのＨＩＴを含む）はＲＶＳシステムを経由し、ＨＩＰホストに転送される。ＨＩＰホストは、Ｒ１パケット内の「プレフィックス」としてそれ自体のアドレスを含む。手順は、上述の通り、完了する。
ＲＶＳ側でサブネットワーク・プレフィックスを登録するための代替手法は、ＨＩＰプロキシがサブネットワーク内のレガシー・ホストについて一時的アイデンティティを作成できるようにすることである。その場合、ＨＩＰプロキシは、これらのアイデンティティをＲＶＳ内のその登録項目に追加し、その項目がサブネットワーク内のレガシー・ホストについてＨＩＴ（ａ）、ＩＰ（ａ）、及び１組のＩＰアドレス／（一時的）ＨＩＴ対を含むようにする。
この代替手法のためのＨＩＰ基本交換は前のシナリオと同様のものであるが、Ｉ１パケット内のソースＨＩＴはレガシー・ホスト（ａ）に割り当てられた一時的ＨＩＴであり、ＲＶＳシステムでは、ピア・レガシー・ホスト（ｂ）に割り当てられた一時的ＨＩＴが宛先ＨＩＴフィールドに挿入される（どちらのピアもＨＩＰプロキシの後ろにあるレガシー・ホストであると想定する）。しかし、ＲＶＳシステムから依然としてＩ１パケットがピアＨＩＰプロキシのＩＰアドレスに送信される。ピアＨＩＰプロキシがＲ１パケットで応答する場合、それは（前のケースのようにサブネットワークのプレフィックスの代わりに）ピア・レガシー・ホストのＩＰアドレス（ＩＰ（ｂ））を含む。発信側ＨＩＰプロキシは、それがないと、入力Ｒ１パケット（及び含まれるＨＩＴ）を送出されるＩ１パケットにマッピングできないので、ＩＰ（ｂ）を必要とする（Ｉ１は空の宛先ＨＩＴフィールドとともに日和見モードで送信されることに注意されたい）。発信側ＨＩＰプロキシは、宛先プロキシがレガシー・ホストのＩＰアドレス対を学習するように、Ｉ２パケット内にレガシー・ホスト（ａ）のＩＰアドレスを含める。基本交換は、レガシー・ホストの一時的ＨＩＴ間でＨＩＰ関連付けを確立するために、通常通り、続行する。
この手法によれば、プレーンＩＰパケットはＨＩＰプロキシ間でトンネリングされない。むしろ、プロキシは、ＩＰヘッダのＩＰアドレスを、レガシー・ホストに割り当てられたＨＩＴで置き換え、その後、パケットには正規ＨＩＰ処理が行われ、その結果、外側のＩＰヘッダのソース及び宛先アドレスが２つのプロキシのアドレスになるＥＳＰ保護パケットが得られる。ＥＳＰ保護パケットが受信機側のＨＩＰプロキシで受信されると、そのパケットのＩＰアドレスは（正規ＨＩＰのように）まずＨＩＴで置き換えられる。次に、プロキシは、レガシー・ホストの実際のＩＰアドレスと一時的ＨＩＴとの保管マッピングを使用して、ＩＰヘッダ内のＨＩＴをレガシー・ホストの実際のＩＰアドレスに変換する。
この手法と上述のプレフィックスベースの手法との重大な違いは、前者では、新しいパケット（例えば、ＴＣＰ ＳＹＮ）が関連する２つのレガシー・ホストが、古い関連付けが関連するものと同じではない場合に、送信側プロキシが古いＨＩＰ関連付けを再使用できないことである。この場合、ＨＩＰプロキシは依然としてＲＶＳを介してＩ１パケットを送信しなければならない。古いＨＩＰ関連付けが同じレガシー・ホストに関連するものである場合のみ、古い関連付けを再使用し、ＨＩＰ基本交換を省略することができる。
ＨＩＰプロキシがそのサブネットワーク内のレガシー・ホストについて一時的アイデンティティを作成する場合、ＨＩＰホストは、それが正規ＨＩＰホストである場合と同じようにレガシー・ホストの１つに接続することができる。ＨＩＰホストがレガシー・ホストの一時的アイデンティティ及びプロキシのロケータを把握している場合、それは、一時的ＨＩＴに設定された宛先アイデンティティによりプロキシのロケータにＩ１パケットを送信することができる。ＨＩＰホストは、Ｉ１パケット内にレガシー・ホストのＩＰアドレスを含め、Ｉ２パケット内にそれ自体のＩＰアドレスを含める必要がある。
ＨＩＰホストへの接続を開始するのがレガシー・ホストである場合、その手順も正規ＨＩＰ基本交換と同様のものであるが、当然のことながら、レガシー・ホストからの最初の「プレーン」データ・パケットはＨＩＰホストとのＨＩＰ基本交換を実行するようにプロキシをトリガするものである。レガシー・ホストはＨＩＰホストのＩＰアドレスにデータ・パケットを送信し、プロキシはＨＩＰホストのＩＰアドレスでＲＶＳシステムに日和見Ｉ１を送信する。ＲＶＳシステムは、ＨＩＰホストのＲＶＳ項目（プレフィックス情報を含む場合もあれば、含まない場合もある）を見つけ、パケット内のＨＩＰホストのＨＩＴとともにＨＩＰホストにＩ１パケットを転送する。ＨＩＰホストは、Ｒ１パケットで応答し、そのＩＰアドレスをパケット内に含める。基本交換は上述の通り続行する。［ＨＩＰホストのＩＰアドレスはＨＩＰサーバの後ろにあるプライベートＩＰアドレスにすることができることに注意されたい。］
モビリティの主題に戻ると、ＨＩＰプロキシはそれが対応しているプレフィックス又はアドレスをＲＶＳシステム内に登録するので、プロキシ及びそのサブネットワーク内のレガシー・ホストもＲＶＳを介して必ず見つけられることが認識されるであろう。プロキシを含むサブネットワーク全体が移動すると、プロキシはその現在位置でＲＶＳシステムを更新することになる。また、プロキシは、そのレガシー・ホストに代わってピア（レガシー及びＨＩＰホスト）で位置更新を実行することになる。ＨＩＰプロキシによって確立されたＨＩＰ接続は、（それがＨＩＰであるので）デフォルトではレガシー・ホストとＨＩＰ／レガシー・ホストとのエンドツーエンド接続を切断せずに新しいロケータから始めるように変更される。
当業者であれば、本発明の範囲を逸脱せずに上述の諸実施形態に対して様々な変更が可能であることを認識するであろう。例えば、ＨＩＰプロキシをＲＶＳに登録するための手法（図６）は、例えば、ＨＩＰモバイル・ルータを含む他のＨＩＰサーバに適用することができる。このようなＨＩＰモバイル・ルータは（レガシー・ホストではなく、又はレガシー・ホストとともに）ＨＩＰホストに対応することができる。このようなシナリオでは、上記で識別されたものと同様の問題が発生する可能性があり、即ち、特にネストされたモバイル・ルータの場合、異なるサブネットワーク間でローカルＩＰアドレスの衝突が発生する可能性がある。

Claims (16)

  1. 移動ネットワークに接続されたホストによるホスト・アイデンティティ・プロトコル・セキュリティ手順へのアクセスを容易にする方法であって、前記移動ネットワークが付加ホストにローカルＩＰアドレスを割り振る役割を担うホスト・アイデンティティ・プロトコル・サーバを含み、前記方法が、前記ホスト・アイデンティティ・プロトコル・サーバが前記ローカル・アドレスを割り振る際に使用するＩＰアドレス・プレフィックスを、前記ホスト・アイデンティティ・プロトコル・サーバの外部到達可能ＩＰアドレスとともにランデブー・サーバで登録することと、受信したＩ１メッセージを前記ホスト・アイデンティティ・プロトコル・サーバに転送するために前記登録されたＩＰアドレス・プレフィックスを前記ランデブー・サーバで使用することを含み、前記ランデブー・サーバが、ローカルＩＰアドレスの衝突を防止するために、ホスト・アイデンティティ・プロトコル・サーバへのアドレス・プレフィックスの割り振り及び登録を制御する、方法。
  2. 前記ホスト・アイデンティティ・プロトコル・サーバがホスト・アイデンティティ・プロトコル・プロキシであり、前記ホストがレガシー・ホストである、請求項１記載の方法。
  3. 前記ＩＰアドレス・プレフィックスとともに、前記ホスト・アイデンティティ・プロトコル・サーバのホスト・アイデンティティ又はホスト・アイデンティティ・タグを前記ランデブー・サーバで登録することを含む、請求項２記載の方法。
  4. 前記ホスト・アイデンティティ・プロトコル・サーバがホスト・アイデンティティ・プロトコル・モバイル・ルータであり、前記ホストがＨＩＰホストである、請求項１記載の方法。
  5. 前記ランデブー・サーバが、ＩＰアドレス・プレフィックスのプールから割り振られていないＩＰアドレス・プレフィックスを選択し、前記登録側ホスト・アイデンティティ・プロトコル・サーバについて前記選択されたプレフィックスを登録し、前記登録側ホスト・アイデンティティ・プロトコル・サーバに前記選択され登録されたＩＰアドレス・プレフィックスを通知することにより、ホスト・アイデンティティ・プロトコル・サーバへのアドレス・プレフィックスの割り振り及び登録を制御する、請求項１乃至４のいずれか１項記載の方法。
  6. 前記ランデブー・サーバが、前記登録側ホスト・アイデンティティ・プロトコル・サーバから提案されたＩＰアドレス・プレフィックスを受信し、すでに登録されたプレフィックスに基づいて前記提案を受諾するか又は拒否することにより、ホスト・アイデンティティ・プロトコル・サーバへのアドレス・プレフィックスの割り振り及び登録を制御する、請求項１乃至４のいずれか１項記載の方法。
  7. 前記ランデブー・サーバによる提案されたＩＰアドレス・プレフィックスの拒否後、代替プレフィックスを前記ホスト・アイデンティティ・プロトコル・サーバで選択することと、これを前記ランデブー・サーバに送信することを含む、請求項６記載の方法。
  8. 前記ランデブー・サーバによる提案されたＩＰアドレス・プレフィックスの拒否後、代替かつ割り振られていないプレフィックスをランデブー・サーバで選択することと、これを前記ホスト・アイデンティティ・プロトコル・サーバに送信することを含む、請求項６記載の方法。
  9. 前記ランデブー・サーバが１組の協働ランデブー・サーバのうちの１つであり、前記ランデブー・サーバがランデブー・サーバ間のＩＰアドレス・プレフィックス衝突を防止するために割り振られたＩＰアドレス・プレフィックスを識別するデータを交換する、請求項１乃至８のいずれか１項記載の方法。
  10. ホスト間のセッションを確立するためにランデブー・サーバとして動作するように構成された装置であって、
    登録データベースと、
    ホスト・アイデンティティ・プロトコル・サーバから登録要求を受信するための受信機であって、前記ホスト・アイデンティティ・プロトコル・サーバが付加ホストにローカルＩＰアドレスを割り振る役割を担う、受信機と、
    前記ホスト・アイデンティティ・プロトコル・サーバが前記ローカル・アドレスを割り振る際に使用するＩＰアドレス・プレフィックスを、前記ホスト・アイデンティティ・プロトコル・サーバの外部到達可能ＩＰアドレスとともに前記登録データベースに登録することにより、登録要求の受信に応答する登録ユニットと、
    前記登録されたＩＰアドレス・プレフィックスを使用して受信したＩ１メッセージを前記ホスト・アイデンティティ・プロトコル・サーバに転送するメッセージ処理ユニットとを含み、
    前記登録ユニットが、ローカルＩＰアドレスの衝突を防止するために、ホスト・アイデンティティ・プロトコル・サーバへのアドレス・プレフィックスの割り振り及び登録を制御するように構成される、装置。
  11. 前記登録ユニットが、ＩＰアドレス・プレフィックス・プール内から割り振られていないＩＰアドレス・プレフィックスを前記ホスト・アイデンティティ・プロトコル・サーバに割り振ることにより、ホスト・アイデンティティ・プロトコル・サーバへのアドレス・プレフィックスの割り振り及び登録を制御するように構成され、前記装置が、前記割り振られたＩＰアドレス・プレフィックスを前記ホスト・アイデンティティ・プロトコル・サーバに送信するための送信ユニットをさらに含む、請求項１０記載の装置。
  12. 前記登録ユニットが、前記ホスト・アイデンティティ・プロトコル・サーバによって提案されたＩＰアドレス・プレフィックスを前記登録要求内で識別し、前記プレフィックスが他のホスト・アイデンティティ・プロトコル・サーバについて登録されている場合に前記プレフィックスを拒否することにより、ホスト・アイデンティティ・プロトコル・サーバへのアドレス・プレフィックスの割り振り及び登録を制御するように構成される、請求項１０記載の装置。
  13. 前記登録ユニットが、提案されたＩＰアドレス・プレフィックスを拒否した時に、代替の使用可能なプレフィックスを前記ホスト・アイデンティティ・プロトコル・サーバに送信するか又は前記サーバからの代替提案を考慮するようにさらに構成される、請求項１２記載の装置。
  14. 前記登録ユニットが、ランデブー・サーバ間のＩＰアドレス・プレフィックス割り振り衝突を防止するために割り振られたＩＰアドレス・プレフィックスを識別するデータを他の関連ランデブー・サーバと交換するように構成される、請求項１０乃至１３のいずれか１項記載の装置。
  15. 前記ホスト・アイデンティティ・プロトコル・サーバが、ホスト・アイデンティティ・プロトコル・プロキシ及びホスト・アイデンティティ・プロトコル・モバイル・ルータのうちの１つである、請求項１０乃至１４のいずれか１項記載の装置。
  16. サブネットワーク内のホスト・アイデンティティ・プロトコル・クライアント及び／又はレガシー・ホストに対応するホスト・アイデンティティ・プロトコル・サーバとして動作するように構成された装置であって、
    前記ホスト・アイデンティティ・プロトコル・サーバが前記サブネットワーク内で前記ローカル・アドレスを割り振る際に使用するＩＰアドレス・プレフィックスを、前記ホスト・アイデンティティ・プロトコル・サーバの外部到達可能ＩＰアドレス及びホスト・アイデンティティ又はホスト・アイデンティティ・タグとともにランデブー・サーバで登録するための登録ユニットであって、前記登録されたＩＰアドレス・プレフィックスを前記ランデブー・サーバから受信するように構成される登録ユニット
    を含む、装置。
JP2011548540A 2009-02-05 2009-02-05 ホスト・アイデンティティ・プロトコル・サーバ・アドレス構成 Expired - Fee Related JP5147995B2 (ja)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/EP2009/051338 WO2010088957A1 (en) 2009-02-05 2009-02-05 Host identity protocol server address configuration

Publications (2)

Publication Number Publication Date
JP2012517165A true JP2012517165A (ja) 2012-07-26
JP5147995B2 JP5147995B2 (ja) 2013-02-20

Family

ID=41100461

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2011548540A Expired - Fee Related JP5147995B2 (ja) 2009-02-05 2009-02-05 ホスト・アイデンティティ・プロトコル・サーバ・アドレス構成

Country Status (4)

Country Link
US (1) US20110296027A1 (ja)
EP (1) EP2394418A1 (ja)
JP (1) JP5147995B2 (ja)
WO (1) WO2010088957A1 (ja)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR101405248B1 (ko) 2012-12-27 2014-06-17 경북대학교 산학협력단 호스트 식별 프로토콜 네트워크 환경의 통신 시스템 및 방법
KR20190134365A (ko) * 2018-05-25 2019-12-04 국방과학연구소 Hip 네트워크의 통신 방법 및 시스템

Families Citing this family (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102143242B (zh) * 2010-10-21 2014-07-09 华为技术有限公司 Ip网络中地址分配方法、设备及系统
US8683019B1 (en) * 2011-01-25 2014-03-25 Sprint Communications Company L.P. Enabling external access to a private-network host
US10251105B2 (en) * 2013-06-07 2019-04-02 Universidade De Aveiro Dynamic mobility management system
US9641512B2 (en) * 2014-04-10 2017-05-02 EMC IP Holding Company LLC Identity protocol translation gateway
CN108136963B (zh) * 2015-10-22 2021-04-27 金泰克斯公司 集成车辆通信系统和方法
WO2017218946A1 (en) * 2016-06-17 2017-12-21 Gentex Corporation Systems and methods for universal toll module
CN111404893B (zh) * 2020-03-06 2021-12-21 深信服科技股份有限公司 一种主机分类方法、装置、设备及计算机存储介质

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2007522744A (ja) * 2004-02-13 2007-08-09 テレフオンアクチーボラゲット エル エム エリクソン（パブル） レガシーノードとｈｉｐノード間のホストアイデンティティプロトコル（ｈｉｐ）接続を確立するためのアドレス指定方法及び装置
JP2008543140A (ja) * 2005-05-27 2008-11-27 テレフオンアクチーボラゲット エル エム エリクソン（パブル） ホストアイデンティティプトコルを使用する方法及び装置

Family Cites Families (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5835725A (en) * 1996-10-21 1998-11-10 Cisco Technology, Inc. Dynamic address assignment and resolution technique
AU2001232894A1 (en) * 2000-01-20 2001-07-31 Mci Worldcom, Inc. Intelligent network and method for providing voice telephony over atm and closeduser groups
AU2001250888A1 (en) * 2000-03-20 2001-10-03 At And T Corp. Service selection in a shared access network using policy routing
US7339903B2 (en) * 2001-06-14 2008-03-04 Qualcomm Incorporated Enabling foreign network multicasting for a roaming mobile node, in a foreign network, using a persistent address
US7454519B2 (en) * 2002-03-22 2008-11-18 Motorola, Inc. Method for automatically allocating address prefixes
US7324499B1 (en) * 2003-06-30 2008-01-29 Utstarcom, Inc. Method and system for automatic call monitoring in a wireless network
US20050066035A1 (en) * 2003-09-19 2005-03-24 Williams Aidan Michael Method and apparatus for connecting privately addressed networks
US7165722B2 (en) * 2004-03-10 2007-01-23 Microsoft Corporation Method and system for communicating with identification tags
CN1939000B (zh) * 2004-04-15 2011-01-12 艾利森电话股份有限公司 建立遗留与主机标识协议节点之间的主机标识协议连接的标识方法及设备
JP4438510B2 (ja) * 2004-05-25 2010-03-24 株式会社日立製作所 通信システム及び通信制御装置
US7447188B1 (en) * 2004-06-22 2008-11-04 Cisco Technology, Inc. Methods and apparatus for supporting mobile IP proxy registration in a system implementing mulitple VLANs
US7568092B1 (en) * 2005-02-09 2009-07-28 Sun Microsystems, Inc. Security policy enforcing DHCP server appliance
CN101401392A (zh) * 2006-03-10 2009-04-01 松下电器产业株式会社 用于前缀控制的设备和用于前缀选择的设备
GB2442044B8 (en) * 2006-05-11 2011-02-23 Ericsson Telefon Ab L M Addressing and routing mechanism for web server clusters.
JP5031026B2 (ja) * 2006-08-24 2012-09-19 パナソニック株式会社 通信管理装置及び位置管理装置
GB2449118A (en) * 2007-05-11 2008-11-12 Ericsson Telefon Ab L M Host Identity Protocol Rendezvous Servers which store information about nodes connected to other servers and forward address requests
WO2009049663A1 (en) * 2007-10-15 2009-04-23 Telefonaktiebolaget Lm Ericsson (Publ) Provisioning mobility services to legacy terminals

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2007522744A (ja) * 2004-02-13 2007-08-09 テレフオンアクチーボラゲット エル エム エリクソン（パブル） レガシーノードとｈｉｐノード間のホストアイデンティティプロトコル（ｈｉｐ）接続を確立するためのアドレス指定方法及び装置
JP2008543140A (ja) * 2005-05-27 2008-11-27 テレフオンアクチーボラゲット エル エム エリクソン（パブル） ホストアイデンティティプトコルを使用する方法及び装置

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR101405248B1 (ko) 2012-12-27 2014-06-17 경북대학교 산학협력단 호스트 식별 프로토콜 네트워크 환경의 통신 시스템 및 방법
KR20190134365A (ko) * 2018-05-25 2019-12-04 국방과학연구소 Hip 네트워크의 통신 방법 및 시스템
KR102109840B1 (ko) * 2018-05-25 2020-05-13 국방과학연구소 Hip 네트워크의 통신 방법 및 시스템

Also Published As

Publication number Publication date
EP2394418A1 (en) 2011-12-14
WO2010088957A1 (en) 2010-08-12
JP5147995B2 (ja) 2013-02-20
US20110296027A1 (en) 2011-12-01

Similar Documents

Publication Publication Date Title
JP5147995B2 (ja) ホスト・アイデンティティ・プロトコル・サーバ・アドレス構成
JP4579934B2 (ja) レガシーノードとｈｉｐノード間のホストアイデンティティプロトコル（ｈｉｐ）接続を確立するためのアドレス指定方法及び装置
EP1735990B1 (en) Mobile ipv6 authentication and authorization
EP2201742B1 (en) Provisioning mobility services to legacy terminals
US20020080752A1 (en) Route optimization technique for mobile IP
JP5804439B2 (ja) Ｉｄ／ロケータ分離ベースのネットワークにおいてネームレジストリ，ネットワークアクセスおよびデータ通信を安全に行う方法
JP2009516435A (ja) 複数鍵暗号化生成アドレスを使ったモバイルネットワークのためのセキュアな経路最適化
US7849195B2 (en) Host identity protocol method and apparatus
US20040090941A1 (en) Dynamic re-routing of mobile node support in home servers
US20130188651A1 (en) Mobility in ip without mobile ip
WO2007109963A1 (fr) Passerelle de réseau privé virtuel et système de réseau ipv6 et système de réalisation de réseau privé virtuel mobile dans un réseau hybride et procédé correspondant
WO2003030488A1 (en) Method and system for ensuring secure forwarding of messages
KR100737140B1 (ko) 이동통신에서의 인터넷 프로토콜 가상 사설망 서비스처리장치 및 방법
Pierrel et al. A policy system for simultaneous multiaccess with host identity protocol
Camarillo et al. Hip bone: host identity protocol (hip) based overlay networking environment (bone)
Makela et al. Home agent-assisted route optimization between mobile IPv4 networks
Kavitha et al. A secure route optimization protocol in mobile IPv6
Sadio et al. Improving security and mobility for remote access: a wireless sensor network case
Johnson et al. RFC 6275: Mobility Support in IPv6
Johnston et al. Internet Engineering Task Force (IETF) G. Camarillo Request for Comments: 6079 P. Nikander Category: Experimental J. Hautakorpi
Arkko IETF Mobile IP Working Group D. Johnson Internet-Draft Rice University Expires: August 27, 2003 C. Perkins Nokia Research Center
Arkko IETF Mobile IP Working Group David B. Johnson INTERNET-DRAFT Rice University Charles E. Perkins Nokia Research Center
Henry et al. Mobile Devices on IP Internetworks
Arkko IETF Mobile IP Working Group D. Johnson Internet-Draft Rice University Expires: October 30, 2003 C. Perkins Nokia Research Center
Makela et al. RFC 6521: Home Agent-Assisted Route Optimization between Mobile IPv4 Networks

Legal Events

Date Code Title Description
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: 20121030

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20121127

R150 Certificate of patent or registration of utility model

Free format text: JAPANESE INTERMEDIATE CODE: R150

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20151207

Year of fee payment: 3

LAPS Cancellation because of no payment of annual fees