JP3575369B2 - アクセスルーティング方法及びアクセス提供システム - Google Patents
アクセスルーティング方法及びアクセス提供システム Download PDFInfo
- Publication number
- JP3575369B2 JP3575369B2 JP2000021419A JP2000021419A JP3575369B2 JP 3575369 B2 JP3575369 B2 JP 3575369B2 JP 2000021419 A JP2000021419 A JP 2000021419A JP 2000021419 A JP2000021419 A JP 2000021419A JP 3575369 B2 JP3575369 B2 JP 3575369B2
- Authority
- JP
- Japan
- Prior art keywords
- arp
- station
- address
- destination
- guest
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Landscapes
- Data Exchanges In Wide-Area Networks (AREA)
- Small-Scale Networks (AREA)
- Mobile Radio Communication Systems (AREA)
Description
【発明の属する技術分野】
本発明はインテリジェントルータに係り、特に、ローカルネットワーク上の外部すなわちゲストステーションにインターネットアクセスを提供するのに用いられるルータに関する。本発明は、特に、ルーティング装置として作用するコンピュータシステム、ルーティングの方法、未知のIPコンフィグレーションを有するコンピュータからのIPパケットをインターセプト(横取り)する方法、インターセプトされたIPトラフィックをローカルネットワークコンフィグレーションに適応させる方法、悪意のあるゲストコンピュータからローカルネットワークを保護する方法、ネットワークインタフェース、及び、ゲストステーションにIPネットワークアクセスを提供するのに適したコンピュータプログラム製品に関する。
【0002】
【従来の技術】
説明を明確にするため、ここで、いくつかの背景情報を提供する。まず、デジタルコンピュータについて説明した後、コンピュータシステム及びコンピュータプログラム製品について説明し、さらにその後、コンピュータ通信及びネットワークについて説明する。
【0003】
これら基礎情報を提供した後で、ネットワーキング及びポータブルデバイスに関する課題について説明する。関連技術の説明を終わると、この課題に対する従来の解決法について説明する。
【0004】
[デジタルコンピュータ]
デジタルコンピュータは、科学、工業、及び商業の分野における多くの変化を可能にしている。今日では、多くのビジネスは、実際に使える情報システムの助けなしには機能し得ない。多くの専用(特殊目的)及び汎用のコンピュータが知られている。
【0005】
単純な汎用デジタルコンピュータのブロック図を図1に示すが、この図は、提供される機能に応じて、専用デジタルコンピュータにも等しく関係する。参照符号10は、汎用デジタルコンピュータを示す。このようなコンピュータは、中央処理装置(CPU)100を有する。メインメモリ110はRAMであるとしてよい。この単純化された図におけるコンピュータは、ただ1つのI/Oプロセッサ120を有する。I/Oプロセッサ120は、I/Oデバイス130を制御する。I/Oデバイス130には、ディスプレイ、キーボード、プリンタ、ディスクドライブ、マウス、及び、イーサネットカードなどのようなネットワークアダプタ140がある。なお、この図は単なる説明のためだけのものであり、本発明を限定することは全く意図していないことは理解されるであろう。
【0006】
CPU100は、制御ユニット、ALU、及びレジスタを有する。制御ユニットは、メインメモリ110から命令をフェッチし、そのタイプを判定する。ALUは、その命令を実行するのに必要な加算や論理ANDのような演算を実行する。CPU100のレジスタは、一時的な結果及びいくつかの制御情報を格納するために使用される小さい高速のメモリである。レジスタにはそれぞれ、ある特定の機能が指定されることも可能であり、あるいは、汎用レジスタであることも可能である。レジスタの1つにプログラムカウンタPCがある。プログラムカウンタPCは、実行される次の命令を指す。また、命令レジスタIRがあり、これは現在実行されている命令を保持する。
【0007】
CPU100、メインメモリ110、及びI/Oプロセッサ120がバスによって相互接続されていることは理解されるであろう。これらの相異なるユニット間の通信はバスを通じて行われる。もちろん、ネットワークアダプタ140やその他の任意のI/Oデバイス130は、I/Oプロセッサなしで機能するように設計され、代わりに、その他のメインモジュールによって同じバスに接続されるように設計されてもよい。さらに、複数のディスプレイ、複数のネットワークアダプタ140などを有することも可能である。
【0008】
このように、デジタルコンピュータは、デジタルモジュールを相互接続したものと見ることができる。CPU100内にいくつかのモジュールがあり、また、CPU、メインメモリ110、及びI/Oプロセッサ120自体もモジュールと見なすことができる。さらに大きいスケールでは、これらのコンポーネントがすべての同じコンテナに含まれるとき、このコンテナを1つのモジュールと考えることが可能であり、さまざまなI/Oデバイス(ディスプレイやキーボードなど)自体はモジュールであると見ることができる。
【0009】
[コンピュータシステム及びコンピュータプログラム製品]
本明細書では、「コンピュータシステム」という用語は、少なくともメモリ及びプロセッサを含むものと考える。一般に、メモリは、いろいろなときに、実行可能プログラムコードの少なくとも一部を格納し、プロセッサは、その実行可能プログラムコードに含まれる1つまたは複数の命令を実行する。理解されるだろうが、「実行可能プログラムコード」という用語及び「ソフトウェア」という用語は、この説明の目的ではほぼ同じものを意味する。この説明では、メモリとプロセッサは必ずしも物理的に同じ場所に位置する必要はない。すなわち、プロセッサとメモリは、異なる物理的装置にあることが可能であり、地理的に異なる場所にあることさえ可能である。
【0010】
次に、「コンピュータプログラム製品」という用語について説明する。実際的なレベルでは、コンピュータシステムが所望のオペレーションを実行することを可能にするソフトウェアは、さまざまな媒体(メディア)で供給可能である。さらに、コンピュータオペレーションの現実の実装は実際にはプログラミング言語で書かれた文(ステートメント)であることも可能である。このようなプログラミング言語ステートメントは、コンピュータによって実行されると、コンピュータを、そのステートメントの個々の内容に従って作用させる。さらに、コンピュータシステムが所定の方式で作用することを可能にするソフトウェアは、オリジナルソースコード、アセンブリコード、オブジェクトコード、機械語、これらのものを圧縮または暗号化したバージョン、及び以上のものの均等物を含むさまざまな形式で提供可能であり、また、これらには限定されない。
【0011】
当業者には認識されるだろうが、本明細書で用いられる「媒体」、あるいは「コンピュータ読取り可能媒体」には、ディスケット、テープ、コンパクトディスク、集積回路、ROM、CD、カートリッジ、通信回線を通じてのリモート伝送、あるいは、コンピュータによって使用可能なその他の同様の媒体が含まれる。例えば、コンピュータシステムが所定の方式で動作することを可能にするソフトウェアを供給するために、供給者は、ディスケットを提供することも可能であり、あるいは、衛星伝送を通じて、直接の電話リンクを通じて、またはインターネットを通じて、何らかの形式でそのソフトウェアを送信することも可能である。このように、「コンピュータ読取り可能媒体」という用語は、上記のものすべて、及び、ソフトウェアがコンピュータに提供されることが可能なその他の任意の媒体を含むことを意図している。
【0012】
コンピュータシステムが所定の方式で動作することを可能にするソフトウェアは、ディスケットに「書き込まれ」、集積回路に「格納され」、あるいは通信回線を「伝送され」ることが可能であるが、認識されるように、本発明の目的には、コンピュータが使用可能な媒体は、ソフトウェアを「有する」ということにする。このように、「有する」という用語は、ソフトウェアがコンピュータ使用可能媒体と関連づけられる上記及びすべての均等な方法を含むことを意図している。従って、簡単のため、「プログラム製品」という用語は、コンピュータシステムが所定の方式で動作することを可能にするソフトウェアを任意の形式で有する、上記で定義したようなコンピュータ使用可能媒体を指すために使用される。
【0013】
[ユーザインタフェース]
ユーザインタフェースは、実行中のプログラムによって呼び出し可能である。ユーザインタフェースは、ユーザがコンピュータシステムと相互作用することを可能にする任意のハードウェア、ソフトウェア、またはハードウェアとソフトウェアの組合せを意味するものとする。ほとんどのプログラムは、例えば、ユーザに対するグラフィカルインタフェース、コマンドラインインタフェース、制御インタフェース(CORBA、JAVA−RMI、DCEあるいはその他のプロトコルに基づく)などの、さまざまなタイプの多くのインタフェースを有する。ここで、認識されるように、「ユーザインタフェース」という用語は、これらをすべてまとめたものを意味する。
【0014】
この説明の目的では、ユーザインタフェースは、1個以上のユーザインタフェースオブジェクトを含むものと考える。ユーザインタフェースオブジェクトには、表示領域、ユーザ活性化可能領域などがある。
【0015】
よく知られているように、表示領域は、ユーザに対して情報を表示するユーザインタフェースの領域である。ユーザ活性化可能領域は、ボタンやメニューのように、ユーザがユーザインタフェースに関して何らかのアクションを起こすことを可能にするユーザインタフェースの領域である。
【0016】
ユーザインタフェースは、アプリケーションプログラムによって呼び出されることが可能である。アプリケーションプログラムがユーザインタフェースを呼び出すときは、一般に、ユーザと相互作用するためである。しかし、本発明の目的では、必ずしも現実のユーザが常にユーザインタフェースと相互作用する必要はない。また、本発明の目的では、ユーザインタフェースとの相互作用は、必ずしも現実のユーザによって実行される必要はない。すなわち、予想されるように、ユーザインタフェースは、ユーザインタフェースに関するユーザのアクションをシミュレートするマクロプログラミング言語ステートメントを用いて作成されたプログラムのような別のプログラムとの相互作用を有することも可能である。
【0017】
[コンピュータネットワーキング]
図2に、図1に示すタイプのいくつかのコンピュータがネットワークで互いに接続されたものを示す。具体的には、コンピュータ210、220、230、及び240が第1のネットワーク200に参加している(第2のネットワークについては後述する)。図2に示す構成において、第1のネットワーク200に接続されたコンピュータ210〜240はすべて互いに通信することができる。コンピュータ210〜240は、ネットワーク200に参加するステーションともいう。さらに、コンピュータ210〜240は通常、第1のネットワーク200に参加しており、ネットワーク200の「レギュラーステーション」あるいは「レギュラーマシン」ということもある。
【0018】
図3に、第1のネットワーク200及び第2のネットワーク300を示す。第2のネットワーク300は、いくつかのレギュラーステーション310、320、330、及び340を有する。図3に示すステーション310〜340はそれぞれ、図1に示したようなデジタルコンピュータ10とすることが可能である。ステーション310〜340はすべて、第2のネットワーク300により互いに通信することができるが、図3に示す構成では、第1のネットワーク200のステーション210〜240のいずれとも通信することはできない。この理由は、ネットワーク200とネットワーク300の間に相互接続がないためである。
【0019】
ステーション210〜240及び310〜340のすべてを単一の大きいネットワーク上に置くことも可能ではあるが、これが常に好ましいとも可能であるとも限らない。ネットワーク間の通信を行う一般的な解決法は、それらのネットワークを別々に保ちながら、互いに通信が可能であるような何らかの接続をそれらのネットワークの間に設けることである。
【0020】
図4に、第1のネットワーク200及び第2のネットワーク300を、より概念的に示す。具体的には、特定のトポロジー(図2及び図3に示すような)ではなくインターネットワーキングの概念に注目するのを助けるように、ネットワーク200及び300は、図4では破線のかたまりで表されている。第3のネットワーク400及びそのレギュラーステーション410、420、430、及び440も示されている。
【0021】
図5は、図4と似ているが、3個のネットワーク200、300、400はネットワーク500に接続され、ネットワーク500は、ネットワーク200〜400を相互接続するネットワークと見なすことができる。特に、ネットワーク500は、インターネットワークと呼ぶことができる。第1のネットワーク200は、アクセスステーション502を通じてインターネットワーク500に接続される。第2のネットワーク300は、アクセスステーション503を通じてインターネットワーク500に接続される。第3のネットワーク400は、アクセスステーション504を通じてインターネットワーク500に接続される。インターネットワーク500は、任意のサイズのネットワークとすることが可能であり、スイッチングノードを含むことも可能である。実際、インターネットワーク500は、インターネットの場合のように、多くの中間ネットワークを含むことも可能である。
【0022】
次に、ネットワーク200〜400とインターネットワーク500がどのように動作するかについての簡単な説明をする。
【0023】
[コンピュータ通信]
最も単純な形式では、コンピュータの間の通信は、何らかの形式のポイントツーポイント伝送媒体によって直接に接続された2つのデバイス間で行うことが可能である。しかし、多くの場合、2つのデバイスが直接にポイントツーポイント接続されることは実際的でない。デバイスどうしが遠く離れていて2つのデバイス間に専用リンクを設定することが高価すぎる場合、あるいは、デバイスのセットがあり、各デバイスがさまざまなときに他の多くへのリンクを必要とする場合、コンピュータネットワーキングが解決法となる。
【0024】
個々のステーション210〜240、310〜340、及び410〜440は、ユーザ、あるいはマシンともいう(他の用語も同様に使用可能である)。ステーションは、通信する任意のタイプのデジタルコンピュータであり、すべて、アクセスノードと通信する。
【0025】
通信ネットワークでは、データは、ソースからデスティネーションへ、一連の中間ノードを通って転送される。これらのノードは、データの内容には関知しないが、データがデスティネーションに到達するまでノードからノードへデータを移動させる転送ファシリティを提供するために存在する。ネットワークの1つの種類に、回線交換ネットワークがある。回線交換ネットワークでは、ネットワークのノードを通じて2つのステーション間に専用の通信路が確立される。中間ノードの間の各リンク上で、論理チャネルがそのコネクションに占有される。
【0026】
もう1つの種類のネットワークは、蓄積交換ネットワークである。これは、本明細書では、パケットネットワークともいう。パケットネットワークでは、ネットワークを通るパスに沿った伝送容量を占有する必要はない。その代わりに、データは、パケットという小断片の列として送出される。各パケットは、ネットワークを通ってノードからノードへ渡される。関与するノードは、まず、パケットを受け取り、それをメモリに格納し、出力ネットワークインタフェースを決定するために自己のフォワーディングテーブルを参照し、そのインタフェースを通じて次のホップへパケットを送る。フォワーディングテーブルは、RIPやOSPFのようなルーティングプロトコルによって定期的に計算される。パケットネットワークは一般にコンピュータ間通信に使用される。
【0027】
ソースコンピュータ(ソース(送信元)ステーション)からネットワークを通りデスティネーションコンピュータ(デスティネーション(宛先)ステーション)までの通信を行うためには、コンピュータシステム間の非常に高度な協力が要求される。このような協力動作のためのコンピュータ間の情報交換も、コンピュータ通信と考えられる。同様に、複数のコンピュータが通信ネットワークを通じて相互接続されているとき、コンピュータステーションのセットは一般にコンピュータネットワークと呼ぶことができる。
【0028】
プロトコルは、コンピュータ間でのデータの交換を支配する規則のセットを指すと見なすことができる。2つのコンピュータが互いに通信しているときには、同時に多くの異なるプロトコルが動作していることもある。実際、コンピュータ間のさまざまな通信をすべて実現する構造化されたプロトコルのセットは、コンピュータ通信アーキテクチャと呼ばれる。周知のコンピュータ通信アーキテクチャの一例は、開放型システム間相互接続(OSI)モデルである。もう1つの例はSNA(Systems Network Architecture)である。さらにもう1つの例はTCP/IPであり、インターネットに関係する。
【0029】
パケット(すなわち蓄積交換)ネットワークでは、アドレシング及びルーティングが重要な問題である。パケットネットワークの主要な機能は、その最低レベルでは、ソースステーションからパケットを受け取り、そのパケットをデスティネーションステーションへ配送することであると考えられる。ソースからデスティネーションまでの複数の経路が一般に可能であるため、ルーティング機能が実行されなければならない。ある特定のノードにおいてパケットの経路を選択することがルーティングの機能であると考えられる。ルーティングソフトウェアと、そのルーティングソフトウェアによって計算された経路に従ってネットワーク間でパケットを転送するハードウェアとを備えた装置をルータという。注意すべき点であるが、小規模のルータの場合、経路を手動で設定して、ルーティングソフトウェアが無効化されることもある。
【0030】
図6に、第1のネットワーク200と第2のネットワーク300の間に接続されたルータ600を示す。ルータは以下のように動作する。ステーション210が、ステーション310を宛先とするパケットを送信すると仮定する。ソースステーション210は、例えば図1に示すようなデジタルコンピュータ10であり、ネットワークアダプタ140を通じてネットワーク200へパケットを送信する。ルータ600には、2個のネットワークアダプタ140が設定される。第1のネットワークアダプタは第1のネットワーク200に参加し、第2のネットワークアダプタは第2のネットワーク300に参加する。ルータ600は、ステーション210が送信したパケットを受信する。ルータは、そのデスティネーションのアドレスがステーション310であることを認識する。ルータ600はメモリ内にいくつかのテーブルを保持しており、これらのテーブルは、デスティネーションステーション310が第1ネットワーク200に参加しているレギュラーステーションではないことを示す情報を含む(これらのテーブルは、フォワーディングテーブル、あるいは、ルーティングテーブルと呼ばれるが、手動で設定されるか、または、RIPやOSPFのようなルーティングプロトコルによりルーティングソフトウェアによって自動的に計算される)。受信したパケットが、第1のネットワーク200に参加していないステーション宛のものであると判定すると、ルータ600は、その第2のネットワークアダプタ140を通じて第2のネットワーク300へパケットを送信する。パケットは、デスティネーションステーション310によって、そのネットワークアダプタ140を通じて受信される。
【0031】
同じパケットがソースステーション210によって送信されたがステーション220がデスティネーションステーションとして指定された場合、ルータは、そのフォワーディングテーブルから、ステーション220は第1のネットワーク200のレギュラーステーションであると判定し、そのパケットのコピーを第2のネットワーク300には送信しない。
【0032】
理解されるだろうが、パケットネットワークの一例は、(一般のネットワークのネットワークとしての)インターネット(an internet)である。このインターネット(internet)の特別の例が(世界規模のネットワークとしての)インターネット(the Internet)である。本明細書では一般に、これらの2つは交換可能であり、区別なしに「インターネット」という。以下の説明は、(世界規模のネットワークとしての)インターネット(the Internet)に限定することを意図していないが、(世界規模のネットワークとしての)インターネット(the Internet)がほとんどの例で用いられる。また、「データパケット」あるいは「データのパケット」という用語は、「データグラム」と入れ替えて使用可能である。
【0033】
図5に戻って、認識されるように、アクセスノード502、503、及び504は、ルータ600として動作するように装備されたデジタルコンピュータ10とすることが可能である。また、ルータは、複数のネットワークに所定の方式で参加することが可能なデジタルコンピュータ10であることは理解されるであろう。ルータ600は、そのコンピュータ命令に従って所定のルーティング動作を実行するように設定されたコンピュータシステムである。
【0034】
インターネットパケットは、デスティネーションのロケーションに配送されるために、デスティネーションアドレスを有していなければならない。これに関して、名前とアドレスを区別しなければならない。名前は、アドレスが関係するエンティティを示す。すなわち、アドレスは、名前を有することが可能なエンティティのロケーションを示す。IP(Internet protocol)は、主にアドレスを扱うプロトコルである。
【0035】
上記のOSIモデルには、7つの層(レイヤ)、すなわち、物理層、データリンク層、ネットワーク層、トランスポート層、セッション層、プレゼンテーション層、及びアプリケーション層がある。トランスポート層は、エンドポイント間での信頼性の高い透過的(トランスペアレント)なデータの転送を提供する。また、エンドツーエンドで誤り回復及びフロー制御も提供する。インターネットに一般に関連する2つの異なるトランスポートレベルのプロトコルがある。これらの2つのプロトコルは、コネクション型のトランスミッションコントロールプロトコルTCP(transmission control protocol)と、コネクションレス型のユーザデータグラムプロトコルUDP(user datagram protocol)である。TCPは、インターネットの主要なトランスポートプロトコルである。
【0036】
インターネットワーク500(以下、インターネット(the Internet)のみに限定されないという理解のもとに、これをインターネットという)は、ネットワーク層でIPを使用し、その上に、TCP、UDP及びICMPのような他の上位層プロトコルを実装する。IPを使用するネットワークをIPネットワークという。従って、インターネット500はIPネットワークである。また、ネットワーク200、300、及び400もIPを使用すると仮定する。
【0037】
TCPは、OSIモデルのトランスポート層にほぼ対応し、IPはネットワーク層にほぼ対応すると考えられる。IPは、ソースからデスティネーションへパケットをルーティングすることに関与し、コネクションレス型であるが、TCPはコネクション型である。
【0038】
理解すべきもう1つのプロトコルはICMP(Internet control message protocol)である。ICMPは、IPとともに動作し、同じくネットワーク層に関連する。IPはコネクションレス型であるため、発信側にメッセージやエラーを中継する方法がない。ICMPは、IPのためにこのような機能を実行する。ICMPは、ステータスメッセージ及びエラーメッセージを送信側ステーションに送る。ICMPメッセージはIPを用いて運ばれる。IPネットワークにおいて重要なさらにもう1つのプロトコルはアドレス解決プロトコルARP(address resolution protocol)である。IP及びICMPとは異なり、ARPはリンク層にある。ARPは、IPアドレスを、ネットワークインタフェースのハードウェアアドレスにマッピングする。具体的には、ARPは、ローカルリンク上でIP/ハードウェアアドレスの対応に関して動的に通知及び問合せを行うために使用される。TCP/IPはレイヤ3以上で動作するため、それより低いレベルのエンティティであるボードとインタフェースする機構を必要とする。ネットワークインタフェースの一意的なレイヤ3アドレス(すなわちIPアドレス)は、それ自体では、物理的なネットワークインタフェースカードを識別しない。IPアドレスとデータリンク(すなわちハードウェア)アドレスを関連づける機構が要求される。ARPはこれを行う。ARPについては後でさらに詳細に説明する。
【0039】
TCP及びUDPについては既に言及した。TCP及びUDPのアドレス可能なエンドポイントをポートという。TCP及びUDPは、ウェルノウン(周知の)ポートに割り当てられたアプリケーションと、動的に割り当てられるポートを使用するアプリケーションを有する。これらのポートはエンドポイントであり、論理コネクションを作成するためにアドレス可能なエンティティである。これらをサービス契約ポートという。これらは、特定のサービスのリクエスタ(要求者)にサービスを提供することが可能であるからである。ポート番号は一般に変化しない。通信エンドポイントアドレスは、IPアドレスと、IPアドレスの終わりに付加されたポート番号との組合せである。
【0040】
IPネットワークに参加する各ステーションは、32ビットのIPアドレスで識別される。IPアドレスは、32ビットの固定長である。1つのアドレスは、ネットワーク番号で始まり、その後にローカルホストアドレスが続く。インターネットアドレスのいくつかのクラスが定義されている。IPネットワークの可能な異なるサイズを考慮するために、IPアドレスのいくつかのクラスが提供されている。インターネット(すなわち全世界ネットワーク)は、アドレシングに関して、内部インターネット(例えば企業内ネットワーク)とは異なる考慮点を有する。
【0041】
図7に、IPパケットヘッダを示す。IPパケットは周知であるが、以下、いくつかのフィールドについて簡単に説明する。送信元アドレスフィールドは、パケットの発信者を示し、長さは32ビットである。あて先アドレスは、パケットのターゲットである。送信元アドレスと同様に、その長さは32ビットである。「ttl」で示されるフィールドは、time−to−live(生存時間)フィールドである。このフィールドは、パケットがインターネットシステムにとどまることが許される最大時間を示す。この値が0に等しくなると、パケットは破壊または廃棄される。時間は秒単位で測定され、また、パケットを処理する各エンティティは、たとえその処理時間が1秒未満であっても、その値を1だけ減らさなければならない。プロトコルフィールドは、受信機側でIPパケットのワークロードに含まれるデータを処理すべき上位レベルプロトコルエンティティを決定する。このような上位レベルプロトコルの例は、TCP及びUDPである。チェックサムフィールドは、ヘッダのみのチェックサムを提供するように計算されるフィールドである。
【0042】
次に、ドメインネームサービス(DNS)について説明する。DNSの目的は、人間が読取り可能なコンピュータ名(例えば、castor.nec.com)を、IPプロトコルによって使用されることが可能な対応するIPアドレス(例えば、140.20.20.4)に変換することである。
【0043】
DNSは、木の形の階層構造である。木の頂点にはルートサーバがあり、これは、自分及びその直下のトップレベルドメインに関する情報を含む。一般的なトップレベルドメインには、.gov、.edu、.com、及び.orgがある。
【0044】
DNSのもとでは、ドメイン名は、最後にトップレベルドメインを有する名前の列である。ドメイン名の各部分をラベルという。例えば、dept.company.comは、dept、company、及びcomという3つのラベルを有する。ネームサーバは、ホスト、ステーションあるいはノード上で動作する、名前をIPアドレスに変換するプログラムである。ネームサーバは、ドメイン名をIPアドレスにマッピングすることによってこれを行う。ネームサーバは、ネームサーバソフトウェアを実行する専用プロセッサであることも、そうでないことも可能である。ネームリゾルバは、ネームサーバとの相互作用に関してはクライアントとして機能するソフトウェアである。ネームキャッシュは、頻繁に使用される名前情報を格納するためにネームリゾルバによって使用される記憶領域である。
【0045】
ドメインシステムは、すべてのデータが、そのドメインシステムを使用するホストを通じて散布されるマスタファイルを起源とすると仮定する。これらのマスタファイルは、ローカルシステム管理者によって更新される。マスタファイルは、ローカルネームサーバによって読み取られるテキストファイルであり、従って、ネームサーバを通じてDNSのユーザに利用可能となる。ユーザプログラムは、リゾルバを通じてネームサーバにアクセスする。一般に、ユーザプログラムは、ローカルリゾルバを通じてDNSにアクセスする。リゾルバの視点から見ると、DNSは未知の個数のネームサーバを含む。各ネームサーバは、全体のドメインツリーの一部である。リゾルバは、これらのDNSサーバのそれぞれと、ほぼ静的な対応するデータベースとを見る。ネームサーバの視点から見ると、DNSは、ゾーンと呼ばれるローカル情報のいくつかのセットからなる。ネームサーバは、いくつかのゾーンのローカルコピーと、他のDNSサーバ(他のゾーンを受け持つ)への参照とを有する。DNSサーバは、与えられた名前をローカルに保持するデータベースから解決することができない場合、その名前が属するゾーンを受け持つDNSサーバに問合せを転送する。
【0046】
[レギュラーステーション、レギュラーネットワーク]
次に、ステーション210のようなレギュラーステーションが自己のレギュラーネットワーク(すなわち、第1のネットワーク200)に接続されるときに起こることについて考える。まず、ステーション210は、次ホップのルータまたはゲートウェイと、ホームネットワークセグメントに属する他のマシンのハードウェアアドレスを見つけなければならない。これを行うため、ステーション210は、ARP要求を送出する。
【0047】
このレギュラー(通常)構成のもとでの動作の例について、図17を参照して説明する。簡単のため、ソースステーション(送信側ステーション)は、図5に示すようにネットワーク200に接続されたステーション210であり、ステーション210は、図1に示すようにただ1つのネットワークアダプタ140(例えば、1個のイーサネットカード)を有すると仮定する。
【0048】
ステーション210は、手動で、自己のIPアドレス(例えば、138.15.103.21)、ネットマスク(例えば、255.255.255.0)、及び、ルータ502に関連するゲートウェイIPアドレス(例えば、138.15.103.52)が設定されている。これらの設定は、マシンが使用されるネットワーキング環境に特有である。これらのアドレスは、ローカルシステム管理者によって割り当てられ、ステーション210〜240に入力される。これらは通常、ステーションがレギュラーネットワークに接続されている間は変更されない。
【0049】
ステーション210は、ステーション220(そのアドレスは138.15.103.22)にパケットを送信しなければならないと仮定する。
【0050】
まず、ステーション210は、デスティネーションステーションと同じセグメントに直接に接続されているかどうかを判定する。ステーション210は、ネットマスクを考慮に入れて、自己のIPアドレスを受信側のIPアドレスと比較する(ステップ1710)。
【0051】
送信側ステーション210は、IPアドレス及びネットマスクを32ビット値として解釈し、2つのIPアドレスのうち、ネットマスクの対応するビットが1であるビットのみを比較する(この例では、これは、IPアドレスの最初の24ビットを比較し、最後の8ビットは無視することを意味する)。いずれの場合でも、最初の24ビットは138.15.103である。
【0052】
ステップ1720で、マスクされたアドレスが等しいか等しくないかを判断する。等しい場合、処理はステップ1725に進む。等しくない場合、処理はステップ1730に進む。この比較結果では、マスクされたアドレスは等しいと判断されるため、処理はこの例ではステップ1725に進む。
【0053】
ステップ1720での判断により、ソースステーション210とデスティネーションステーション220は同じセグメントに接続されていると推論される。従って、このパケットの次ホップは、デスティネーションステーション220のIPアドレスを有するステーションとなる。
【0054】
IPパケットを次ホップ(これはこの例ではデスティネーションステーション220である)に配送するために、IPホストは、次ホップのハードウェアアドレス(HWアドレス)を判定しなければならない。これは、物理伝送媒体に対してパケットをどこへ配送すべきかについて正しく指示するために、行わなければならないことである。IPホストは、次ホップのIPアドレス(すなわち、ステーション220のIPアドレス)を知っているが、次ホップのHWアドレスはまだ知らない。このために、IPホストは、ネットワーク200上のあらゆるステーションにブロードキャスト形式で、次ホップのマシンのHWアドレスを問い合わせるARPメッセージを送出する(ステップ1720)。このARPメッセージは、デスティネーションステーション220を宛先の受信機として識別する。
【0055】
次ホップは、ローカルネットワーク200に参加しているステーションであるため、このARP要求を受信した後、自己のHWアドレスを応答することにより、次ホップステーションのHWアドレスが送信側ステーション210に提供される。ステップ1740で、ステーション210は、ARP応答が受信されたかどうかをチェックする。受信されていない場合、ウェイト期間に入る(ステップ1750)。ウェイトの後、ステップ1760で、タイムアウト期間が経過したかどうかを判定する。タイムアウトが経過していない場合、処理は、ステップ1740に進み、ARP応答をもう一度チェックする。タイムアウトが経過した場合、エラーが発生したと判定する。
【0056】
ARP応答が検出されると仮定すると、処理はステップ1770に進む。ARP応答が検査され、次ホップステーションのHWアドレスが判定される。
【0057】
ステップ1780で、パケットは次ホップに送られる(この例ではステーション220)。このパケットのデスティネーションIPアドレスは138.15.103.22である。ステーション220は、パケットの送り先のHWアドレスと一致するHWアドレスを有するため、このパケットを受信する。ステーション220は、このパケットが、デスティネーションアドレスとして、ステーション220のIPアドレスを有することを確認する。これにより、ステーション220はそのパケットを受け入れる。
【0058】
次に、ステーション210がIPパケットを、別のネットワーク上のステーションであるステーション310に送る場合の例について説明する。ステーション310のIPアドレスは、例として、141.20.20.31である。
【0059】
まず、ステーション210は、デスティネーションステーション310と同じセグメントに直接に接続されているかどうかを判定する。ステーション210は、ネットマスクを考慮に入れて、自己のIPアドレスを受信側のIPアドレスと比較する(ステップ1710)。
【0060】
2つのアドレスは、マスクすると、ステーション210は138.15.103であり、ステーション310は141.20.20である。ステップ1720で、マスクされたアドレスが等しくないと判断されるため、処理はステップ1730に進む。
【0061】
ステップ1720での判断により、ソースステーション210とデスティネーションステーション310は同じセグメントに接続されていないと推論される。従って、このパケットの次ホップは、ルータ(ゲートウェイ)502である。ルータ502のIPアドレスは、既に述べたように、138.15.103.52である。パケットのデスティネーションはステーション310であるが、パケットの次ホップはルータ502でなければならない。
【0062】
IPパケットを次ホップに配送するために、IPホストは、次ホップのHWアドレスを判定しなければならない。IPホストは、次ホップのIPアドレス(すなわち、ルータ502のIPアドレス)を知っているが、次ホップのHWアドレスはまだ知らない。このために、IPホストは、ネットワーク200上のあらゆるステーションにブロードキャスト形式で、次ホップのマシンのHWアドレスを問い合わせるARPメッセージを送出する(ステップ1730)。このARPメッセージは、ルータ502を宛先の受信機として識別する。
【0063】
次ホップは、ローカルネットワーク200に参加しているルータであるため、このARP要求を受信した後、自己のHWアドレスを応答することにより、次ホップステーションのHWアドレスが送信側ステーション210に提供される。既に説明したように、ウエイトと及びタイムアウトの処理が、ステップ1740、1750、及び1760で行われる。
【0064】
ARP応答が検出されると仮定すると、処理はステップ1770に進む。ARP応答が検査され、次ホップステーションのHWアドレス(この例では、ルータ502のアドレス)が判定される。
【0065】
ステップ1780で、パケットは次ホップに送られる(この例ではルータ502)。このパケットのデスティネーションIPアドレスは141.20.20.31である。ルータ502は、パケットの送り先のHWアドレスと一致するHWアドレスを有するため、このパケットを受信する。
【0066】
ルータは、自己のIPアドレスがパケットのデスティネーションIPアドレスと一致しないことを認める。従って、ルータ502は、図17に示す手続きを実行して、最終受信者へのパスにより次ホップへパケットを転送する。
【0067】
すなわち、ステーション210がパケットをステーション310に送ると、パケットはルータ502によって受け取られ、インターネット500を通じて送られ、ルータ503によって受け取られ、ステーション310に送信される。パケットは、ソースIPアドレスを、210のアドレスであるとして示す。返信時に、ステーション310は、ソースであるとして示されたIPアドレスをデスティネーションとするIPパケットを送出する。返信パケットは、ルータ503によって受け取られ、インターネット500を通じて送られ、ルータ502によって受け取られる。ルータ502は、ステーション210に対応するIPアドレスが自己のネットワークに参加しているレギュラーステーションのものであるであることを知っている。ルータ502は、ネットワーク200上にパケットを送信し、このパケットはステーション210によって受信される。
【0068】
[ゲストステーション、外部ネットワーク]
ハードウェアに関して、「ゲストマシン」あるいは「ゲストステーション」という用語は、周知のIP(internet protocol)を用いて通信可能なさまざまなコンピューティング装置あるいはコンピュータのうちの任意のものを意味する。ゲストマシンとしては、デスクトップコンピュータ、移動可能(ポータブル)コンピュータ、ラップトップあるいはノートブックコンピュータ、パームトップあるいはハンドヘルドコンピュータ、パーソナルデジタルアシスタントなどが可能である。ゲストマシンとなる可能性のある装置は、単に、IPを用いて通信可能であればよい。
【0069】
また、「ゲストステーション」は、レギュラーネットワークに接続されていないステーションを意味する。この状況は、以下で説明するように、さまざまな理由で生じることがある。
【0070】
しばしば、移動するビジネス旅行者や、ワークショップや会議の出席者は、他のサイトを訪れるときに、さまざまなポータブルなIP通信可能装置(少なくともラップトップ)を持ち運ぶ。オンライン株取引、電子メール及びその他のインターネットサービスが日常的になっているために、彼らは通常、ホスト側組織からインターネットにアクセスすることを要求する。そのような場合、しばしば、ホスト側組織のアナログ電話線のうちの1つを、ゲストが提供する28.8Kビット/秒モデムとともに使用して、ゲストのホームネットワークに、または公衆のISPに直接にダイヤルする。この解決法は、高価で(長距離電話料金)遅い(28.8Kビット/秒)のみならず、しばしば実際的でない(アナログ電話線にアクセスできない場合や、その使用許可がない場合)。
【0071】
従って、ホスト側組織がゲストに対して、ポータブルデバイスをインターネットに接続するための、より経済的で容易に使用可能な機構を提供することが好ましい。
【0072】
図8に、ゲストステーションが外部ネットワークと関与する状況を示す。図8で、ステーション210は、第3のネットワーク400上のゲストステーションである。ステーション210は、第1のネットワーク200のレギュラーステーションである。今は、ステーション210はネットワーク400に接続されている。第3のネットワーク400は、ステーション210のレギュラーネットワークではないため、第3のネットワーク400は、ステーション210にとって外部ネットワーク(foreign network)である。従って、ステーション210の視点から見ると、接続は外部ネットワークに対してなされている。第3のネットワーク400の視点から見ると、ゲストステーションが接続されている。実際には、第3のネットワーク400は、ゲストにIP接続を提供するホテルや会議センタと見なすことができる。このサービスは、ゲストステーションをホストするサービスと呼ばれ、ネットワーク400を、ホスティングネットワーク(ホストネットワーク)という。
【0073】
【発明が解決しようとする課題】
[ゲストステーションをホストする際の問題点]
ゲストステーションをホストする際の一般的な問題点について、図8及び図17を参照して、例を挙げて説明する。
【0074】
簡単のため、ソースステーション(送信側ステーション)は、図8に示すように、レギュラーネットワーク200ではなく第3のネットワーク400に接続されたステーション210であり、ステーション210は、図1に示すように、ただ1つのネットワークアダプタ140(例えば、1個のイーサネットカード)を有すると仮定する。
【0075】
ステーション210は、手動で、自己のIPアドレス(例えば、138.15.103.21)、ネットマスク(例えば、255.255.255.0)、及び、ルータ502に関連するゲートウェイIPアドレス(例えば、138.15.103.52)が設定されている。
【0076】
ステーション210は、ステーション220(そのアドレスは138.15.103.22)にパケットを送信しなければならないと仮定する。
【0077】
まず、ステーション210は、デスティネーションステーションと同じセグメントに直接に接続されているかどうかを判定する。ステーション210は、ネットマスクを考慮に入れて、自己のIPアドレスを受信側のIPアドレスと比較する(ステップ1710)。いずれのマスクされたアドレスも、最初の24ビットは138.15.103となる。
【0078】
この比較結果では、マスクされたアドレスは等しいと判断されるため、処理はこの例ではステップ1725に進む。
【0079】
ステップ1720での判断により、ソースステーション210とデスティネーションステーション220は同じセグメントに接続されていると誤って推論される。従って、このパケットの次ホップは、デスティネーションステーション220のIPアドレスを有するステーションとなる。
【0080】
IPパケットを次ホップ(これはこの例ではデスティネーションステーション220である)に配送するために、ゲストステーション210は、次ホップのハードウェアアドレス(HWアドレス)を判定しようとする。ステーション210は、ネットワーク400上のあらゆるステーションにブロードキャスト形式で、次ホップのマシンのHWアドレスを問い合わせるARPメッセージを送出する(ステップ1720)。このARPメッセージは、デスティネーションステーション220を宛先の受信機として識別する。
【0081】
次ホップは、ローカルネットワーク200に参加しているステーションではなく、ネットワーク400に参加しているいずれのステーションのIPアドレスも一致しないため、ARP要求はネットワーク400上のあらゆるステーションによって無視され、いずれのステーションもARP応答を送信しない。
【0082】
ステップ1740で、ステーション210は、ARP応答が受信されたかどうかをチェックする。応答が受信されていないため、結局、エラー状況が存在すると判定される。ステーション220へのパケットは送信することができない。
【0083】
次に、第3のネットワーク400に接続されたゲストステーション210がIPパケットを、別のネットワーク上のステーションであるステーション310へ送信しようとする場合の例について説明する。今度も、ステーション310のIPアドレスは、例として、141.20.20.31である。
【0084】
まず、ステーション210は、デスティネーションステーション310と同じセグメントに直接に接続されているかどうかを判定する。ステーション210は、ネットマスクを考慮に入れて、自己のIPアドレスを受信側のIPアドレスと比較する(ステップ1710)。
【0085】
2つのアドレスは、マスクすると、ステーション210は138.15.103であり、ステーション310は141.20.20である。ステップ1720で、マスクされたアドレスが等しくないと判断されるため、処理はステップ1730に進む。
【0086】
ステップ1720での判断により、ゲストステーション210とデスティネーションステーション310は同じセグメントに接続されていないとゲストステーション210によって推論される。従って、少なくともステーション210にプログラムされている内部IP設定によれば、このパケットの次ホップは、ルータ(ゲートウェイ)502である。ルータ502のIPアドレスは、既に述べたように、138.15.103.52である。パケットのデスティネーションはステーション310であるが、パケットの次ホップはルータ502であると設定される。
【0087】
IPパケットを次ホップ(これはこの例ではルータ502である)に配送するために、ゲストステーション210は、次ホップのハードウェアアドレスを判定しなければならない。ゲストステーション210は、次ホップのIPアドレス(すなわち、ルータ502のIPアドレス)を知っているが、次ホップのHWアドレスはまだ知らない。このために、ゲストステーション210は、第3のネットワーク400上のあらゆるステーションにブロードキャスト形式で、次ホップのマシンのHWアドレスを問い合わせるARPメッセージを送出する(ステップ1730)。このARPメッセージは、ルータ502を宛先の受信機として識別する。
【0088】
しかし、このルータは、ネットワーク400に参加していないため、ARP応答はステーション210には返ってこない。直前の例の場合と同様に、エラー状況が存在すると判定され、ゲストステーション210からデスティネーションステーション310へパケットを送信することができない。
【0089】
ゲストステーション210のパケットを送出するようにルータ504をプログラムしておくことができるとしても、以下で説明するように、依然として問題点は残る。
【0090】
ステーション210が第3のネットワーク400上のゲストであり、ルータ504を通じてパケットをステーション310へ送信すると仮定する。このパケットは、ネットワーク400上のルータ504によって受信される。ルータ504は、図6に示すルータ600のような構成を有することが可能である。ルータ504は、そのネットワークアダプタ140の一方を通じてパケットを受信する。ルータ504は、そのルーティングテーブルでデスティネーションアドレスをチェックし、このパケットが、自己のネットワーク400内のいずれのIPアドレスにも関係しないデスティネーションアドレスを有することを認める。ルータ504は、他方のネットワークインタフェース104にパケットを送信する。この時点で、パケットは、ステーション210をソースIPアドレスとし、ステーション310をデスティネーションIPアドレスとする。
【0091】
パケットは、インターネット500を通じて運ばれ、ルータ503に送られる。ルータ503は、ネットワーク300内にあると予想されるステーションに対するすべてのパケットを受信するルータであるからである。ルータ503は、このパケットを受信し、自己のルーティングテーブルから、ステーション310のIPアドレスがネットワーク300上のIPアドレスであると判断する。ルータ503は、このパケットをネットワーク300上に送信し、ステーション310はこれを受信する。
【0092】
ステーション310が返信パケットを送信するときに、問題の中心が明確になる。ステーション310によって受信されるパケットは、ステーション210をソースIPアドレスとする。従って、ステーション310は、返信パケットのデスティネーションとして、その同じIPアドレスを有する返信パケットを送信する。ステーション210のアドレスをデスティネーションIPアドレスとする返信パケットは、ルータ503によって受け取られ、インターネット500上に送られる。
【0093】
パケットは、インターネット500を通じて運ばれ、ルータ502に送られる。ルータ502は、ネットワーク200内にあると予想されるステーションに対するすべてのパケットを受信するルータであるからである。ルータ502は、このパケットを受信し、自己のルーティングテーブルから、ステーション210のIPアドレスがネットワーク200上のIPアドレスであると判断する。ルータ502は、このパケットをネットワーク300上に送信するが、ステーション210はこのネットワークに接続されていない。従って、ステーション310からステーション210への返信パケットは決してステーション210に到達することはない。ステーション210は外部ネットワーク400上のゲストとして接続されているからである。
【0094】
[ゲストステーションをホストする際の問題点に対する可能な解決法の説明]
ゲストステーションをホストする際の問題点に対する解決法は、ゲストのデバイスに変更を要求するものであるべきではない。これには4つの理由がある。第1に、そのような変更をすることは、ローカルネットワークポリシー及びIPアドレスに関する知識を必要とする。第2に、ゲストステーションのデバイスを変更することは面倒であり、エラーの生じやすい作業である。第3に、訪問が終了した後、変更を元に戻さなければならない。第4に、このような変更がゲストの装置に及ぼす影響については全く明らかであるとはいえない。このような設定変更の後にゲストのシステムのコンポーネントの調子が悪くなると、たとえそれが全く無関係な理由によるものだとしても、可能性のある原因や責任について議論が起こり得る。
【0095】
さらに、ゲストステーションをホストする際の問題点に対する解決法は、ゲストからの悪意のある攻撃を避けるために、外部ネットワーク(また、自己の視点から見れば、ホスティングネットワーク)に対するセキュリティを可能にすべきである。
【0096】
・DHCP
ダイナミックホストコンフィグレーションプロトコルDHCP(Dynamic Host Configuration Protocol)の使用は、外部ネットワーク上でのゲストステーションのサポートのために考慮され得る1つの機構である。しかし、DHCPは、ホストネットワークに対しても、ゲストステーションに対しても、セキュリティの点を考慮していないという点で不利である。
【0097】
もう1つの克服しがたいDHCPの欠点は、ゲストステーションにおけるサポートを必要とすることである。すべてのゲストステーションがDHCPをサポートしているわけではなく、特に、最小のIPスタックしか有しない古いシステムや単純なデバイスではそうである。
【0098】
さらにもう1つのDHCPの欠点は、各ゲストステーションごとに別々のIPアドレスを必要とすることである。適当な容量を提供するためには、ホストや会議施設は大きいIP番号のプールを取得することが必要になるが、そのほとんどは一般には未使用のままとなる。
【0099】
・モバイルIP
モバイルIPは、ゲストステーションをホストする際の問題点に対する解決法として考慮され得るもう1つの機構である。しかし、モバイルIPは、各ゲストに対するホームエージェントの存在に依存する。このようなホームエージェントは通常、ほとんどのゲストにとって利用可能でない。
【0100】
予想される単純なIPデバイスのほとんど(例えば、IPペン、ポータブルプリンタ)は、ホスト側組織の環境だけで働く。ホームエージェントによるモバイルIPアプローチの場合のように、それらを論理的にホーム環境に入れることは非効率的である。ゲストユーザにとっては、ゲストステーションのレギュラーネットワークを通って迂回することなく、インターネットサービスのほとんど(すなわち、WWWの閲覧、電子メールの送信、ftp、電子メールを読むためのtelnetなど)にアクセスすることができたほうがよい。
【0101】
・ネットワークアドレス変換
ネットワークアドレス変換NAT(network address translation)はRFC1631に記載されている。NATの1つのバージョンは、CISCO Systemsの市販製品で利用可能である。
【0102】
最も単純な設定では、ネットワークアドレストランスレータ(NAT:Network Address Translator)は、2つのネットワークどうしを接続するルータ上で動作する。これらのネットワークの一方(内部として指定される)は、プライベートアドレスまたは旧式(obsolete)アドレスでアドレス指定される。これらのアドレスは、パケットが他のネットワーク(外部として指定される)上に転送される前に、正式なアドレスに変換される必要がある。変換は、ルーティングとともに動作するため、NATは、変換が必要なときに、利用者側のインターネットアクセスルータ上で簡単に実行することができる。
【0103】
NATデバイスの使用は、ルータプラットフォーム上でRFC1631スタイルのネットワークアドレス変換を提供する(URL http://info.internet.isi.edu:80/in−notes/rfc/files/rfc1631.txtを参照)。NATの目標は、プライベートネットワークがあたかもグローバルに一意的なアドレスを有しておりNATデバイスが存在していないかのような機能を提供することである。市販品では、NATは、パケット内のソースIPアドレス及びデスティネーションIPアドレスの両方の変換を実行することができる。この変換は、NAT機能のあるルータで管理されるアドレス変換テーブルを用いることによって実行される。
【0104】
しかし、NATは、ゲストステーションを扱わない。NATによる変換は、アドレス変換テーブルにアドレスが入力されることを必要とする。パケットがこのようなルータによって受信される場合、ソースアドレスはアドレス変換テーブルに存在せず、変換を行うことができない。従って、NATの使用は、ゲストステーションのをアドレス変換テーブルに追加するというホスト側組織のサポートを要求する。
【0105】
【課題を解決するための手段】
従って、本発明の目的は、ゲストがゲストステーションを外部ネットワークに簡単につないで即時にIP接続ができるように、ゲストステーションをホストする際の問題点を解決することである。もう1つの目的は、外部ネットワークがイーサネットのようなブロードキャストLANを使用しているときでもこれを実現することである。本発明のさらにもう1つの目的は、以前に設定されたポータブルデバイスのネットワーク設定(IPアドレス、ネットマスク、次ホップルータ(ゲートウェイ)や、DNS(Domain Name Service)の設定など)への変更なしに、上記のことを実現することである。本発明のもう1つの目的は、ゲストステーションによるホスティングネットワークへの悪意のある攻撃を防ぐような方法で、即時のIP接続を実現することである。本発明のもう1つの目的は、ゲストステーションに対して、必要であれば、外部ネットワークからの悪意のある侵入や攻撃に対するセキュリティを提供することを可能にするような方法で、上記の接続を実現することである。さらに、本発明の目的は、大きいIPアドレスのプールを必要とせずに、ゲストステーションのIPアクセスを提供することである。最後に、本発明の重要な目的は、ゲストステーションからのサポートなしに、また、ゲストのレギュラーネットワークからのサポートを期待することなく、ゲストステーションのIPアクセスを提供することである。
【0106】
本発明による、アクセスルータがIPサービスをゲストステーションに提供するアクセスルーティング方法は、前記ゲストステーションから、元のソースIPアドレス及びデスティネーションIPアドレスを有する元の出力IPパケットをインターセプトするインターセプトステップと、前記元のソースIPアドレスをc/o(care−of)アドレスに関連づける関連づけステップと、前記元の出力IPパケットに基づいて変更された出力IPパケットに、前記元のソースIPアドレスの代わりに前記c/oアドレスを提供するステップと、からなることを特徴とする。本発明は、一実施形態において、ゲストから送信されるすべてのパケットをインターセプトして、そのゲストのIPアドレスを、ホスト側組織に属するcare−of(気付)IPアドレスで置換するインテリジェントルータ(本明細書では、アクセスルータともいう)として実現される。
【0107】
【発明の実施の形態】
以下の論文は、ここで説明する主題に関する背景情報を理解するのに有用である。
(1)ISO, ”Open Systems Interconnection (OSI) Reference Model”, Standard IS7498
(2)R. Droms, ”Dynamic Host Configuration Protocol”, RFC 2131, IETF, 1997
(3)D. Plummer, ”An Ethernet Address Resolution Protocol −or− Converting Network Addresses to 48−bit Ethernet Address for Transmission on Ethernet Hardware”, RFC826, IETF, Nov 1982
(4)”Linux IP Masquerade mini HOWTO”, http://www.dlomas.com/masquera.html, Mar 1999
(5)Object Management Group (OMG), ”The Common Object Request Broker Architecture (CORBA)”, Version 3.0, www.omg.org, April 1999
(6)W. Simpson, ”The Point−to−Point Protocol (PPP)”, RFC 1661, IETF, Jul 1994
(7)K. Hamzeh and others, ”Point−to−Point Tunneling Protocol”, Internet Draft, IETF, Jul 1997
(8)G. S. Pall and G. Zorn, ”Microsoft Point−to−Point Encryption (MPPE) Protocol”, Internet Draft, IETF, Mar 1998
(9)”Internet Demon inetd − internet super−server”, Linux User Manual, Section 8, 1997
(10)B. Schneier and Mudge, ”Cryptanalysis of Microsoft’s Point−to−Point Tunneling Protocol (PPTP)”, Proceedings of the 5th ACM Conference on Communications and Computer Security, ACM Press, November 1998
(11)C. Perkins, ”IP mobility support”, RFC 2002, IETF, Oct 1996
(12)Sun Microsystems, JINI white papers, http://www.sun.com/jini/whitepapers, 1999
【0108】
第1実施形態
本発明は、一実施形態では、ゲストから送信されるすべてのパケットをインターセプトして、そのゲストのIPアドレスを、ホスト側組織に属する care−of(気付)IPアドレスで置換するインテリジェントルータ(本明細書では、アクセスルータともいう)として実現される。
【0109】
ここで、ターゲットマシンとは、ゲストステーションがパケットを送信しようとしているステーションであることは理解されるであろう。外部ネットワーク(ゲストステーションから見て)は、ホストネットワークと言い換えることも可能である。care−ofアドレスは、c/oアドレスともいう。ゲストステーションのホームネットワークは、ゲストステーションのレギュラーネットワークとも言い換えられる。ゲストステーションは単にゲストともいう。また、ホスト側組織は、ゲストステーションにホスティングのサービスを提供する組織または個人であることが可能であり、あるいは、このようなサービスを提供するように契約した第三者であることも可能である。
【0110】
上記のように、アクセスルータは、ゲストから送信されるすべてのパケットをインターセプトして、そのゲストのIPアドレスを、ホスト側組織に属するcare−of IPアドレスで置換する。ターゲットマシンは、このようなパケットを受信した場合、応答をそのc/oアドレスに(すなわち、アクセスルータに)送ることになる。アクセスルータは、パケットを受信すると、そのc/oアドレスをゲストのIPアドレスで置換して、リンク層アドレスを用いてそのパケットを直接にゲストに配送する。ゲストの視点から見ると、(インテリジェント)アクセスルータは、彼のホームネットワーク上のマシン(特に、その次ホップルータ(ゲートウェイ))をエミュレートしている。ホスト側組織の視点から見ると、ゲストは、内部ネットワーク上の(専用のc/oアドレスを有する)新しいマシンになっている。
【0111】
図9に示すように、IPアドレスa.b.c.dを有するゲストステーションがIPアドレスw.x.y.zを有するターゲットステーションをデスティネーションアドレスとするパケットを送信すると、アクセスルータは、ソースIPアドレスa.b.c.dをローカルc/oアドレスで置換する。従って、ターゲットステーションの返信はアクセスルータへルーティングされ、そこで、アドレス変換が元に戻される。
【0112】
図7を参照すると、理解されるように、アクセスルータは、ソースIPアドレスをc/oアドレスで置換し、パケットの生存時間(ttl)値をデクリメントして、IPチェックサムを再計算する。
【0113】
アクセスルータにより、ゲストステーションは、IPトラフィックを開始することができる。すなわち、ゲストステーションは、ターゲットステーションへIPパケットを送信し、その返信を現在のロケーションで受信することができる。ゲストのIPアドレスをc/oアドレスで置換しないと、すべての返信はゲストのホームネットワークへルーティングされ、一般にそこで廃棄されることになる。
【0114】
部外者はゲストとの通信を開始することができない。部外者は、ゲストからパケットを受信するまで、c/oアドレスを知らないからである。しかし、本発明のこの実施例によるアクセスルータは、WWWドキュメント検索、電子メール送信、telnet(例えば、家で電子メールを読むため)及びftpを含むほとんどのインターネットサービスにアクセスするには十分である。
【0115】
アクセスルータのソフトウェアをインストールするのは簡単かつ容易である。DHCP(2)やモバイルIP(11)とは異なり、ゲストのマシンやゲストステーションのレギュラーネットワークには、セットアップシグナリングやあらかじめインストールされたソフトウェアは不要である。必要なことは、ゲストが、あらかじめインストールされているIP設定を有することだけである。従って、任意の既存のIPデバイス、オペレーティングシステム及び設定を、変更なしでサポートすることができる。シグナリングや初期セットアップがないため、ここで提案する技術は高速で非常にスケーラブルである。
【0116】
・詳細な実装−第1実施例
以下で、本発明の第1実施例を実装することに関する詳細について説明する。
【0117】
アクセスルータを用いてゲストステーションにIPアクセスを提供する際の第1ステップは、ゲストのポータブルデバイスがIPパケットを任意のリモートデスティネーションへ送信することを可能にすること、及び、そこからの返信がポータブルデバイスの現在のロケーションに戻ってくることを保証することである。これは2ステップで実現される。第1ステップでは、アクセスルータは、ゲストから送信されるすべてのIPパケットを、指定された次ホップのIPアドレスが何であっても、インターセプトする。第2に、インターセプトしたパケットをさらに転送する前に、その同じアクセスルータは、ゲストのIPアドレスをローカルc/o IPアドレスで置換する。同様に、帰路(リターン)トラフィックでは、このc/oアドレスは、パケットが最終的に物理リンクを通じてゲストに直接に配送される前に、ゲストの真の(ホーム)IPアドレスに逆変換される。
【0118】
・プロキシARPを用いたIPパケットインターセプション
ゲストステーションとアクセスルータが物理ポイントツーポイント媒体を通じて接続されているとき、IPパケットのインターセプション(横取り)は容易である。ゲストステーションとルータが共有媒体を通じて接続されているとき、いくつかの考慮すべき点がある。このような共有媒体の例には、有線あるいは無線のイーサネットがある。
【0119】
インターネットのトポロジー、すなわち、その接続グラフは、IPアドレスにより規定される。IPパケットを転送するとき、ネットワークノードは、そのパケットについてルーティングテーブル参照を行うことにより、そのパケットが次に送られなければならないノードのIPアドレスを得る。このノードを次ホップという。パケットは最終的にこれらの2つのノード間の物理媒体により伝送されるため、送信側は、次ホップのIPアドレスを媒体依存のハードウェアアドレスに変換しなければならない。共有媒体では、このIP−ハードウェアアドレス変換はアドレス解決プロトコルARP(3)によって行われる。
【0120】
ネットワークノードは、IPアドレスをハードウェアアドレスに変換しなければならないとき、直接に接続されているすべてのマシンへARPメッセージをブロードキャストする。次ホップ(ルータまたは最終受信者)が、これらのマシンのうちの1つとなる。次ホップは、自己のIPアドレスに対するARPメッセージを受信すると、自己のハードウェアアドレスを応答する。このハードウェアアドレスを用いて、ARP要求を発信したホストは、今度は物理層により次ホップへデータパケットを送信することができる。
【0121】
ARP要求で指定されるIPアドレスを有するステーションの代わりに、別のマシンがそのARP要求に応答することが可能である。この機構をプロキシ(代理)ARPといい、ターゲットマシンがARPをサポートしていない場合に使用することができる。
【0122】
ARPメッセージの交換は物理層で行われる。従って、各媒体ごとに、すべての可能なARPメッセージと、その媒体のメッセージフォーマットとの間のマッピングを定義しておく必要がある。
【0123】
本発明の第1実施例の好ましい実装によれば、プロキシARPを用いて、ゲストの出力IPトラフィックをインターセプトする。ゲストステーションは、最初にホスティングネットワークに接続されるとき、そのネットワークのハードウェアアドレスを知らない。従って、依然としてホームネットワークに接続されていると仮定して、ゲストステーションは、次ホップルータ(ゲートウェイ)と、ホームネットワークセグメントに属する他のマシンのハードウェアアドレスについて知るためにARP要求を送出する。これらはホスティングネットワークに存在しないため、ARP要求は未応答のままとなる。これらの「欠けている」マシンをエミュレートするため、アクセスルータは自己のハードウェアアドレスにより(代理として)ARP要求に応答する。これにより、ゲストステーションは、そのアクセスルータがもともと通信したい次ホップマシンであると考えて、アクセスルータへすべてのトラフィックを送信することになる。
【0124】
しかし、重要な点であるが、このアクセスルータは、ローカルネットワークセグメントに実際に存在するマシン(特に、他のゲスト)のARP要求には応答しない。もしもアクセスルータが他のゲストに代理として応答すれば、ゲストステーションから他のゲストステーション宛のすべてのIPトラフィックは物理的にアクセスルータへ送信されることになり、他のゲストステーションは実質的に到達不可能となる。
【0125】
本発明のこの実施例で対処しなければならないもう1つの考慮すべき点は、多くのマシンが起動時に自己のIPアドレスのARP要求を送出することである。これは、新たに起動されるマシンが、自己のIPアドレスが既に他のマシンによって使用されているかどうかを判定するために行われる。もしもアクセスルータがこのようなARP要求に自己のハードウェアアドレスで応答すると、起動されたマシンは、アクセスルータが自分と同じIPアドレスを使用していると考え、ネットワークインタフェースをシャットダウンしてしまうことになる。この問題に対処する1つの方法について以下で説明する。
【0126】
例えばLinuxなどのUnixシステムのようなBerkeley Socket Programming Interface(ソケット)をサポートするオペレーティングシステムでは、接続されている各ネットワーク上にブロードキャストされたすべてのARP要求をユーザレベルプロセスが受信することが可能である(実装のヒント:ETH#P#ARPとして指定されたプロトコルのパケットソケットを用いる)。すべてのARPメッセージをリスン(listen)することにより、このプログラムは、ローカルネットワークに接続されているすべてのマシン(ゲストを含む)のIPアドレスと、対応するHWアドレスとについて知ることができる。このプログラム(インテリジェントルータ内で実行される)が、まだIP/HWアドレスマッピングを有しないIPアドレスに対するARP要求を受信した場合、このARP要求は、新しいゲストから来ていると結論する。ただし、このプログラムはまず、ある期間(現在の実装では20ミリ秒間)待機する。この時間後、ARP要求型のマシンによって送信されていない場合、このプログラムは、実際に新しいゲストを検出したと結論し、最初のARP要求に対して、自己のHWアドレスにより応答する。このアルゴリズムは、(1)新しいゲストのARP要求が応答されること、及び(2)実際に存在するマシンの代理としてARP応答が生成されることはないこと、を保証する。
【0127】
本発明のこの第1実施例のルータによるパケットのインターセプションについて、以下、図17、図18、図19、及び図20を参照して説明する。
【0128】
図19に、本発明のこの実施例によるルータを示す。参照符号900は、アクセスルータを示す。アクセスルータは、CPU910、メモリ920、ならびにネットワークアダプタ941及び942を有する。このルータは、以下で説明するステップに従って動作させるソフトウェアを備えた汎用デジタルコンピュータとすることが可能である。
【0129】
図18に、前のいくつかのセクションで説明し図8に示したのと同様のネットワークを示す。しかし、図18では、ルータ504は、アクセスルータ900で置き換えられている。図19に示すように、アクセスルータ900の第1のネットワークアダプタ941は、ローカルネットワーク400に接続されている。同様に、アクセスルータ900の第2のネットワークアダプタ942は、参照符号500で示される外部ネットワーク、あるいはインターネットに接続されている。アクセスルータ900のメモリ920は、ARPあて先テーブル921及びゲストサービステーブル922を有する。
【0130】
ステーション210は、ネットワーク400に対してはゲストステーションである。ステーション210のレギュラーネットワークは第1のネットワーク200であるからである。この例ではステーション210は、第2のネットワーク300内の通常の一にあるステーション310へIPパケットを送信しようとしている。ステーション310は、このIPパケットのデスティネーションステーションである。この例では、ステーション210の、レギュラーネットワークにおけるIPアドレスは138.15.103.21である。ステーション310のアドレスは141.20.20.31である。ルータ900のアドレスは、216.52.92.54である。ステーション210は、自己のルータがルータ502であり、そのIPアドレスは138.15.103.52であることを認識して、レギュラーネットワーク内で動作するようにあらかじめ設定されている。
【0131】
ゲストステーション210の動作を図17に示す。これは、ゲストステーションの視点から見て、ゲストステーション210があたかも自己のホームアドレスにあるのと全く同じである。
【0132】
まず、ステップ1710で、ゲストステーション210は、自己の所定のネットマスクを用いて、自己のIPアドレスを、出力IPパケットのデスティネーションアドレスと比較する。ステップ1720の比較は、マスクされたアドレスが等しくないことを示すため、処理はステップ1730に進む。ゲストステーション210は、所定のルータIPアドレス138.15.103.52へARP要求を送出する。
【0133】
通常の状況では、ネットワーク400上にはIPアドレス138.15.103.52を有するステーションはないため、ゲストステーション210は通常は応答を受信しない。しかし、アクセスルータ900がネットワーク400上で動作しており、プロキシARPプログラムにより、図20に示すようにARP要求に応答する。
【0134】
ステップ2010で、アクセスルータ900は、ゲストステーション210によって送信されたARP要求を検出する。ステップ2020で、アクセスルータのプロキシARPプログラムは、自己のARPテーブル921をチェックして、ARP宛先がアクセスルータに既に知られているかどうかを判定する。ARP要求の宛先のIPアドレスが既にARP宛先テーブル921に記録されている場合、処理はステップ2110に進む。ARP要求の宛先のIPアドレスがARP宛先テーブル921にまだ記録されていない場合、処理はステップ2040に進む。この例では、ゲストステーション210はネットワーク400に接続されたばかりであるため、ARP宛先テーブルは、ゲストステーション210からのARP要求の宛先となるステーションのエントリを有している可能性は少ない(すなわち、ルータ502のエントリはない)。
【0135】
従って、処理はステップ2040に進む。ステップ2040で、アクセスルータは、ネットワーク400上の他のステーションからゲストステーション210へ送られるARP応答をリスンする。アクセスルータが、ネットワーク400上の他のステーションからのARP応答を検出した場合、処理はステップ2060に進む。そうでない場合、処理はステップ2070に進む。
【0136】
ネットワーク400上の別のステーションがゲストステーション210からのARP要求に応答した場合、これは、ARP宛先がローカルネットワーク400に参加していることを意味する。この状況は、ゲストステーション210とそのARP宛先との間で通信が行われるためにこれ以上アクセスルータ900による介入が不要であることを意味する。しかし、この例では、目的のARP宛先(ルータ502)はネットワーク400に参加していないため、処理はステップ2070に進む。
【0137】
ステップ2070で、アクセスルータ900はウェイト状態に入る。ウェイト状態が満了した後、処理はステップ2080に進む。ステップ2080で、あらかじめ定義されたルータARPウェイトしきい値が満了したかどうかが判定される。この好ましい実施例では、ルータARPウェイトしきい値は30ミリ秒である。しかし、ARPプロトコルの要求−応答期間の最大遅延の少なくとも2倍の時間しきい値を使用すれば十分である。
【0138】
ステップ2080で、ルータARPウェイトしきい値がまだ過ぎていない場合、処理はステップ2050に進み、ARP応答が受信されたかどうかを調べる。この例では、ネットワーク400上の他のステーションはゲストステーション210からのARP要求メッセージに対するARP応答を送信しない。従って、ルータARPウェイトしきい値は満たされ(経過し)、処理はステップ2090に進む。
【0139】
ステップ2090で、アクセスルータ900は、ステーション210へプロキシARP応答を返送する。このプロキシARP応答は、アクセスルータ900のHWアドレスを示す。ステップ2100、アクセスルータは、IPアドレス138.15.103.52(すなわち、ルータ502のIPアドレス)を、非ローカルステーションとして、ARP宛先テーブル921に追加する。ステップ2110の処理については後述する。
【0140】
図17に戻って、ゲストステーション210は前に、ARP要求を、ルータ502のあらかじめ定義されたIPアドレス(すなわち、IPアドレス138.15.103.52)に送出していた。ステップ1740で、ゲストステーション210はARP応答を検出するため、処理はステップ1770に進む。しかし、このARP応答は、実際にはアクセスルータ900から送信されたプロキシARP応答である。このプロキシARP応答により、ゲストステーション210は、ルータ900のHWアドレスが、自己のホームネットワークの次ホップマシン(この例ではルータ502)のHWアドレスであると考える。ステップ1770で、ゲストステーション210によって受信された応答を解析し、次ホップHWアドレスを取得する。この次ホップHWアドレスは、アクセスルータ900のHWアドレスである。ステップ1780で、ゲストステーション210は、出力IPパケットアドレス141.20.20.31(すなわち、デスティネーションステーション310のIPアドレス)を有する出力IPパケットを次ホップへ送信する。ゲストステーション210が、この次ホップHWアドレスはルータ502のHWアドレスであると考えていることは問題ではない。重要な効果は、ホスティングネットワーク400にとって外来者であるゲストステーションからパケットが送信されていても、パケットが次ホップへ送信されることである。
【0141】
図20に戻って、次に、ステップ2110での動作について説明する。特に、ゲストステーション210が、ARP宛先をステーション502とするもう1つのARP要求を送出することが起こり得る。このような場合、アクセスルータ900は、ステップ2010でそのARP要求を検出する。アクセスルータは、ステップ2020でARP宛先テーブル921をチェックする。ステップ2030で、そのアドレスが既に既知でありテーブルにあるかどうかを判定する。ステップ2110で、ARP宛先がネットワーク400にとってローカルである場合、アクセスルータ900は何のアクションもとらない。アクセスルータ900は、ローカルステーションがARP要求に応答すると期待するからである。他方、ARP宛先がARP宛先テーブル921で非ローカルステーションであると示されている場合、アクセスルータ900は、自分がプロキシARP応答を送信することによってARP要求メッセージに応答しなければならないことを知る。この応答は、処理がステップ2090に進むと送信される。
【0142】
上記の例では、ゲストステーション210は、通常は自己のレギュラーネットワーク200に属していなかったデスティネーション310へパケットを送信しようとしていた。次に、ゲストステーション210が、通常はステーション210と同じレギュラーネットワークにあるステーション220へIPパケットを送信しようとする場合の簡単な例について説明する。
【0143】
簡単にいえば、ステップ1720における比較の結果、ゲストステーション210とデスティネーションステーション220のマスクされたアドレスは等しいと判定される。従って、ステップ1725で、ゲストステーション210は、ステーション220のIPアドレス(今の例では138.15.103.22)へARP要求を送出することになる。
【0144】
ステップ2010で、アクセスルータは、ARP要求メッセージを検出する。ステップ2020におけるARP宛先テーブルのチェックにより、ステップ2030で、ARP宛先(すなわちステーション220)はアクセスルータ900にとって未知であることがわかる。ステップ2040で、アクセスルータは、ネットワーク400上のステーションがARP応答を送信するのをリスンする。
【0145】
ステーション220の所有者も、ステーション210の所有者と同じホテルあるいは会議に出席しているという場合がある。この場合、ステーション220は、ステーション210へ直ちにARP応答を返送し、アクセスルータ900は、ARP宛先テーブル921にローカルステーションとしてステーション220のIPアドレスを追加する。こうして、ステーション210と220は、アクセスルータ900の介在なしに直接に通信することができる。しかし、ステーション220がそのレギュラーネットワーク200に接続されていると仮定すると、ゲストステーション210にARP応答は戻ってこない。
【0146】
ステップ2080で、ルータARPウェイトしきい値が経過すると、アクセスルータ900は、自己のHWアドレスを与えるプロキシARP応答をステーション210へ送信する。さらに、ARP要求宛先のIPアドレスが、非ローカルステーションとして、ARP宛先テーブル921に追加される。
【0147】
ステップ1740で、ゲストステーション210はARP応答を受信し、アクセスルータ900のHWアドレスを用いて、出力IPパケットを次ホップへ送信する。こうして、出力IPパケットのデスティネーションステーションが、ゲストステーションのレギュラーネットワークに通常は接続されているステーションであるか、それとも、ゲストステーションのレギュラーネットワークに通常は接続されていないデスティネーションステーションであるかにかかわらず、アクセスルータ900は、ゲストステーション210に、出力IPパケットをアクセスルータ900へ送信させる。ただし、本発明のこの実施例は、通常は同じレギュラーネットワークを共有する2つのゲストステーションが存在するという状況を考慮に入れている。
【0148】
アクセスルータ900がそのHWアドレスをゲストステーションに提供し、それによりゲストステーションが出力IPパケットをアクセスルータに送信するとき、これを、アクセスルータが出力IPパケットをインターセプトするという。
【0149】
・c/oアドレス割当て
アクセスルータは、出力IPパケットをインターセプトすると、IPヘッダ(図7)のソースIPアドレスフィールドから、ゲストステーションのIPアドレス、すなわち、ゲストがそのホームネットワークで使用するIPアドレスを知ることができる。このホームアドレスはグローバルに一意的であるため、これは、ゲストステーションを識別するためにアクセスルータ内でさらに用いられる。ゲストが、グローバルに一意的である必要のないローカル/プライベートIPアドレス(すなわち、192.168.x.xの形のIPアドレス)を有するという特殊な場合には、ゲストのIPアドレスを、ゲストのグローバルに一意的なHWアドレスとともに用いてゲストを識別する。
【0150】
さらに、登録されるゲストごとに、アクセスルータは、ゲストサービステーブル922内に、統計及びその他のゲストごとのデータを有するゲストサービスレコードを管理する。ゲストサービスレコードは、例えば、ゲストがいくつかの連続するping要求に応答しないときに削除される。このようなping要求は、所定時間だけイナクティブになっている各ゲストステーションに対してアクセスルータが定期的に発行する。
【0151】
既に説明したように、アクセスルータが通常のゲートウェイルータのようにふるまい、インターセプトしたパケットを単に転送する場合、受信機はゲストのIPアドレスに応答し、すべてのこのような応答パケットは失われてしまう。これらのパケットは、ホスティングネットワークではなくゲストのホームネットワークへルーティングされることになるからである。これを避けるため、アクセスルータは、ゲストのホームアドレスにローカルc/oアドレスを関連づけ、これをIPヘッダのソースアドレスフィールドに書き込む。これらのパケットに対する応答はアクセルルータに戻り、そこで、ゲストへの最終的な配送を行うことができる。ゲストステーションと、それに割り当てられたc/oアドレスとの間の関連づけは、ゲストサービスレコードに保持される。アクセスルータは、ゲストサービスレコードの存在しないIPパケットを受信した場合、自動的に新しいゲストを認識し、新しいゲストサービスレコードを(新しく関連づけられたc/oアドレスとともに)作成する。
【0152】
入力(帰路)トラフィックでは、アクセスルータは、デスティネーションアドレス(これは、前に割り当てたc/oアドレスのうちの1つであるはずである)を用いて、対応するゲストサービスレコードを見つける。そして、ゲストのホームIPアドレスをIPヘッダのデスティネーションアドレスフィールドに入れて、パケットを物理層によりゲストへ配送する。
【0153】
・ICMPエコー応答メッセージ
ICMPエコー応答メッセージは、以前に発行されたICMPエコー要求に対する応答である。IETF標準で規定されているように、この応答メッセージは、もとのエコー要求をワークロード内に「ピギーバック」して運ぶ。特殊な扱いがなければ、アクセスルータは、もとのメッセージ(これは、IPヘッダに、ゲストのホームアドレスではなくc/oアドレスを含む)をカプセル化し、これは、アクセスルータに変更なしに渡される。一部のシステム、具体的には、Microsoft Windowsシステムは、カプセル化されたもとのエコー要求メッセージ内に誤ったIPソースアドレスのあるICMPエコー要求を受信すると混乱する。tracert(UNIXのtracerouteのWindowsバージョン)のようなプログラムはうまく動作しない。この特定の場合には、本発明の第1実施例によるアクセスルータは、カプセル化されたパケットのIPヘッダにおいて、c/oアドレスをゲストのホームアドレスで置換することによって、IPパケットのワークロードを変更する。
【0154】
・チェックサムの計算
IPパケットのソースアドレスまたはデスティネーションアドレスが変更された場合には、IPヘッダチェックサムを再計算する必要がある。アクセスルータは各パケットのソースIPアドレスを変更するため、ヘッダチェックサムのこの再計算も同時に実行しなければならない。さらに、TCP、UDP、及びICMPのプロトコルでは、TCP/UDP/ICMPのヘッダチェックサムも再計算しなければならない。IPヘッダのソースアドレス及びデスティネーションアドレスがこれらのチェックサムの計算には含まれるからである。
【0155】
・ゲスト間通信
本発明のこの好ましい実施例は、既に説明したように、あるゲストが別のゲストと通信したいときに、これらのゲストが通常は同じレギュラーネットワーク上にある場合でも、通信を提供する。この特殊な場合は実際には、最初に思われるほどまれではない。訪問者がいくつかのIP機能付きデバイス(例えば、ラップトップ、ポータブルプリンタ、及びその他の有用な装置)をホスト側組織の環境に持ち込むと、それぞれがゲストステーションとなる。これらのゲストステーションはおそらく相互作用する必要がある。この状況は、SUN MICROSYSTEMSのJINI技術(12)と類似している。JINIでは、ポータブルデバイスはプラグアンドプレイにより即時にコミュニティを形成し、事前の計画や人間のインストールなしに、ユーザに高レベルのサービスを提供する。
【0156】
上記の状況では、2つのゲストはアクセスルータの関与なしに相互作用した。これらの異なるゲストステーションあるいはデバイスがネットワーク400に接続するタイミングに依存して、ゲストのうちの1つのレコードに、別のゲストの代わりにアクセスルータのハードウェアアドレスが記録され、アクセスルータはその別のゲストの代理(プロキシ)として作用しており、アクセスルータはそのパケットをインターセプトすることになるという可能性がある。その後、通常は最初のゲストと同じレギュラーネットワークを共有する別のゲストがネットワーク400に接続する。本発明の実施例によるアクセスルータは、ARP宛先テーブル921で非ローカルであるとして示されるARP宛先が、ゲストサービステーブル922においてゲストであるとして示されるのを認識するようにプログラムされる。このような場合、アクセスルータ900は、ARP宛先テーブル内のステータスをローカルに変更することにより、そのゲストが、ルータの介在なしに通信することを可能にする。これを実現するのに、出力パケットを、受信したのと同じネットワークアダプタ(すなわち、図19におけるアダプタ941)を通じて変更なしに転送するなどの、他の方法も可能である。いずれの場合でも、ゲストどうしは、ホームIPアドレスを用いて相互に通信することができる。
【0157】
第2実施形態
本発明の第2実施形態は、ホスティングネットワークに対して追加のセキュリティ保護を提供する。
【0158】
想起されるように、アクセスルータは、ゲストから送信される各パケットを受け取り、そのソースIPアドレス(すなわち、ゲストのアドレス)をc/oアドレスで置換する。このc/oアドレスにより、パケットは、あたかもホストネットワークに関連するIPアドレスから発信されたかのように見える。しかし、このように見えることは、ホストネットワークの観点からは好ましくないことがある。特に、ホストネットワークのレギュラーステーションが、通常はホスティングネットワークのレギュラーメンバに予約されている特権を有することがある。さらに、ホスト側組織は、通常は部外者に対してファイアウォールにより保護されているホストネットワーク内でゲストがIPパケットを放出する場合に、セキュリティハザードと見なす可能性がある。
【0159】
また、悪意のあるゲストは、ホスティングネットワークのメンバであるふりをして、ホスティングネットワークに(アクセスルータを通じて)パケットを送信することができる可能性がある。このようなパケット内のソースIPアドレスは、c/oアドレスで置換された後は、ホスティングネットワークのレギュラーステーションによって送信されたパケットと区別がつかない。
【0160】
本発明のこの第2実施形態によれば、アクセスルータと(公衆インターネット内のルータのような)外部ステーションとの間のIPトンネルを用いて、ホスティングネットワーク及びその環境を悪意のあるゲストからのIPパケットに対して保護する。パケットがゲストからホスト側組織内のマシンへ送信されると、まず、IPトンネルを通じてホスト側組織のネットワークを抜けた後、企業のファイアウォールを通じて再び入らなければならない。ここで、「外部ステーション」とは、ホスト側組織のファイアウォールの外側のステーションである。これにより、ゲストからのIPパケットは、企業ファイアウォールによって認可されなければ(すなわち、通らなければ)、ホスティングネットワーク内のステーションに決して到達することができない。
【0161】
この追加保護は、アクセスルータの出力ネットワークインタフェースを、企業ファイアウォールの外側の次ホップルータに物理的に(例えば、長いケーブル(long cable)で)接続することによって実現することができる。その場合でも、アクセスルータは依然として物理的にはホスト側組織の構内に位置する。ネットワークの観点から見ると、アクセスルータは企業ネットワークの外側にあり、公衆インターネットドメイン内にある。ゲストが、ホスト側組織の内部マシンのうちの1つへIPパケットを送信すると、このパケットは、公衆インターネットから来たのと全く同様に、ファイアウォールを通らなければならない。
【0162】
アクセスルータを外部次ホップルータに接続するために物理配線を使用する代わりに、IPトンネルの形式の「仮想配線」を用いて、ずっと経済的かつフレキシブルな方法で、同じ機能と同程度の保護を提供することが可能である。
【0163】
IPトンネルは、IPアドレスによって識別される2つのトンネルエンドポイントにより規定される。トンネルの目的は、物理的なポイントツーポイント配線をエミュレートすることである。これは、これらの2点間でIPパケットを伝送する物理媒体の代わりに使用することができる。システムエンジニアの観点から見ると、IPトンネルエンドポイントは、「論理的な」ネットワークインタフェース及びそれに等価のもの(例えば、イーサネットネットワークカードのインタフェース)として表されることが多い。IPトンネルを通じてIPパケットを送信するためには、別のIPパケット内にカプセル化し、ホップバイホップで相手側のトンネルエンドポイントへルーティングする。そのエンドポイントに到達すると、カプセル化されたパケットが取り出される。
【0164】
もとのパケットは、カプセル化する側のパケットのワークロードに閉じ込められるため、そのIPヘッダは、カプセル化する側のパケットのルーティングに影響を及ぼすことはない。すなわち、カプセル化されたパケットがトンネルを離れることは不可能である。
【0165】
物理配線が通常有する十分なレベルのプライバシをエミュレートするには、IPトンネルの両方のトンネルエンドポイントは一般に、相互に認証し、カプセル化されたパケットを暗号化する必要がある。しかし、本発明のこの実施例では、IPトンネルは、ゲストのトラフィックをホスト側のネットワーク内で放出することができないことを保証するためにのみ使用されるため、認証/暗号化は、ホスト側環境にとっての関心事ではなく、省略可能である。
【0166】
図10に、アクセスルータと公衆ネットワーク内の次ホップルータの間のIPトンネルを示す。ゲストステーションが送信し、アクセスルータが変更するパケットはすべてこのIPトンネルを通って送られる。
【0167】
IPトンネルを作成するためにいくつかの技術が利用可能である。すべて、明示的なトンネルセットアップを必要とする。異なるのはカプセル化の方式である。非常にオーバーヘッドの少ない(増えるデータは20バイトで、パケットごとのデータ処理はない)1つのIPトンネリング技術はIP−over−IPである。LINUXシステム上では、ifconfigコマンドを用いてこのようなトンネルをセットアップすることができる。
【0168】
オプションとして、c/oアドレスのうちの1つを宛先とするトラフィックがトンネルを通じてルーティングされることを保証するように、外部ルータのルーティングテーブルを調整することも可能である。
【0169】
第3実施形態
本発明の第3の実施形態は、ゲストステーションに対して追加のセキュリティを提供する。
【0170】
ゲストは、ホスト側の環境を信頼しない可能性があり、また、公衆インターネットからの攻撃を心配する可能性もある。ゲストと特定のc/oアドレスとの関連づけは一時的でしかないため、インターネットからの攻撃はむしろ困難である。攻撃者には、いつどこで、彼の攻撃対象にどのc/oアドレスが割り当てられるかはわからないからである。アクセルルータを通じて送信されるパケットはゲストステーションのIPアドレスを含まず、c/o IPアドレスのみを含む。従って、ゲストステーションのIPアドレスは、アクセスルータにしかわからない。これに対して、ホスト側環境は、ゲストのIPアドレスと、それに割り当てられたc/o IPアドレスとともに知っている。従って、パスワードやその他の秘密情報を含むゲストのIPパケットを容易にモニタし、その内容を変更することさえ可能な場合がある。
【0171】
ゲストのセキュリティを改善するために、ゲストは、ゲストステーションと、ゲストステーションのホームネットワークのような信頼される環境に存在するルータとの間にセキュアIPトンネルを作成することが可能である。このようなルータをトンネルサーバとして図11に示す。ゲストステーションと、信頼された環境内のトンネルサーバとの間のセキュアIPトンネルの作成は、ゲストがあたかも実際にホームにいるかのようにゲストをそのホームネットワークに接続する「ロングワイヤ」をエミュレートするという追加の利点を有する。ゲストステーションからのすべてのトラフィックは、ホームネットワークセグメントで放出される。ゲスト宛のホームネットワークセグメントからのすべてのトラフィックはゲストによって受信されることが可能である。
【0172】
本発明のこの実施形態は、ゲストのホームネットワークからのサポートを必要とする。具体的には、ホームネットワークは、相互エンドポイント認証及びデータ暗号化を有するIPトンネルをサポートしなければならない。この方式の欠点の1つは、Windows 95、98、及びNTは、ゲストステーションにおけるルーティングをサポートしていないことである。ゲストからのすべてのトラフィックは同じトンネルを通じてルーティングされ、これは、近くのデスティネーションへのトラフィックに対して不要な迂回を生じる。LINUXシステムでは、例えば、ゲストはインターネット内の他の信頼されるルータへの追加のセキュアトンネルを作成することも可能である。このような追加のトンネルを、出力トラフィックの代替経路として使用することができる。
【0173】
図11に示すように、ゲストは、上記の第2実施形態によるアクセスルータによって提供されるIP接続を使用して、ゲストステーションと、そのホームネットワーク内のVPNサーバ(すなわちトンネルサーバ)のような信頼されるエンティティとの間にセキュアIPトンネルを作成する。
【0174】
MicrosoftのWindowsオペレーティングシステムのうちの1つを使用するゲストステーションに対応するために、本発明のこの第3実施形態の実際の実装は、トンネルエンドポイント認証にMicrosoft Challenge Handshakeプロトコル(MS−Chap)を使用し、トラフィック暗号化にMicrosoft Point−to−Point Encryption(MPPE)(8)を用いる、PPP(6)ベースのトンネリング技術を使用することが好ましい。さらに、トンネルの開始及び制御を行い、2つのトンネルエンドポイント間でPPPパケットを交換するために、Microsoft Point−to−Point Transport Protocol(PPTP)を使用するのが好ましい。このアプローチの主要な利点は、すべてのコンポーネントが上記のMicrosoftのシステムで利用可能であることである。さらに、これらのプロトコルはIETFによって標準化されているため、提案した解決法は他のオペレーティングシステムとも互換性がある。
【0175】
従って、ゲストがMicrosoftのシステムを使用する場合、ゲストステーションがトンネルクライアントの役割を果たすには新たなソフトウェアは不要である。トンネルサーバ側では、市販のMicrosoft NT VPNサーバが使用可能である。本発明のもう1つの実施例として、同等の機能を有するサーバを、LINUXオペレーティングシステムで実装することも好ましい。
【0176】
ゲストステーションがホスト側組織からIPアクセスを取得した後、ゲストステーションのユーザは、簡単な方法で、ホームネットワークへのセキュアIPトンネルの作成を開始することが可能である。例えば、セキュアIPトンネルの作成は、MS Windowsのデスクトップ上のNetwork−Dial−Inアイコンをクリックすることによって開始される。このダイヤルイン手続きは、電話番号の代わりにIPアドレスがリモートピアとして指定されることを除いては、アナログ電話線を通じてのダイヤルインと非常に似ている。ゲストがダイヤルインGUIの”Connect”(接続)ボタンを押した後、クライアントシステムは、指定されたトンネルサーバへのPPTPコネクションを作成する。このPPTPコネクションは、実際にはサーバポート1723へのTCPコネクションであり、まずIPサポートを提供するアクセスルータのアクティビティにより可能となる。PPTPパケットは、トンネルサーバに到達すると、ホスト側組織のc/oアドレスを運ぶ。しかし、カプセル化されたIPパケットは、ゲスト自身のIPアドレスを運ぶが、アクセスルータからは見えない。アクセスルータの視点から見ると、ゲストは単にPPTPコネクションを有する。上記のトンネルは実際は2つのトランスポートコネクションを有する。一方は、トンネル制御のためのTCPコネクションであり、他方は、カプセル化されたパケットの交換のためのコネクションである。ただし、ゲストは、このトンネル内に任意の数のコネクションを維持することが可能である。
【0177】
本発明のこの実施例の好ましい実装では、トンネルサーバはLINUXオペレーティングシステム上で動作する。インターネットデーモンinetdは、PPTPコネクション要求が到着すると、自動的にpptpサーバの新しいインスタンスを起動する(inetdに関する詳細は(9)を参照)。この新しいpptpサーバインスタンスは、入ってくるTCPコネクションを受け入れ、クライアントともに、それをPPTP制御コネクションとして使用する。さらに、トンネルサーバは、自分と発信側ゲストとの間にワークロードコネクションを作成する。このコネクションは、リモートゲストによってではなくPPTPサーバによって開始されるため、ゲストのホームネットワークのファイアウォールがそれをブロックすることはない。このワークロードコネクションは、PPPパケットを含むMPPE PDUを運ぶために使用される。最初のPPPメッセージは実際には、2つのトンネルエンドポイントの相互認証と、トンネルの動作モードのネゴシエーション(暗号化方法及び初期キーのネゴシエーションを含む)のための制御メッセージである。
【0178】
注意すべき点であるが、トンネルは必ずしも対称である必要はない。それぞれの方向で異なる動作モードをネゴシエートすることが可能である。この実施例の好ましい実装では、トンネルサーバはMPPE暗号化を必要とするが、40ビットと128ビットの間の選択はゲストに委ねられる。知られているように(10を参照)、Microsoft MPPEで実装されるような40ビット暗号化は解読可能であるが、これには非常な労力を必要とする。
【0179】
初期ネゴシエーションが完了した後、ワークロードコネクションを使用して、トンネルサーバとリモートクライアントの間で暗号化されたIPパケットを交換する。トンネルサーバのPPP部分は、LINUXシステム上では別個のプロセス(PPPデーモンpppd)であり、通常は、リモートトンネルエンドポイントのIPアドレスに対するプロキシARPとなる。従って、これは、ゲスト宛にホームネットワークセグメントに到着するすべてのIPパケットをインターセプトし、セキュアトンネルを通じてそれを転送する。逆方向では、ゲストからセキュアトンネルを通じてホームネットワークに到着するパケットはホームネットワーク内で放出される。
【0180】
このように、暗号化と組み合わせて、ゲスト自身が、エンドツーエンドIPトンネルを使用して、ホスト側環境と公衆インターネットに対して自分のトラフィックを保護することが可能である。さらに、このようなIPトンネルはゲストをホームネットワークのVPNサーバと接続することが可能である。この場合、ゲストは、ホスト側組織のネットワーク及び公衆インターネットをIPトンネルのための実装基盤としてのみ使用して(これは、ゲストデバイスとホームネットワークセグメントの間の仮想的なケーブルとして作用する)、ホームネットワークと(論理的に)接続されることになる。
【0181】
次に、pptpサーバと、トンネルセットアップのいくつかの実際的な事項について簡単に説明する。
【0182】
[LINUX上におけるPPTPサーバのインストール]
本発明の実際の実装では、Microsoft Point−to−Point Encryption(MPPE)をサポートするPPTPサーバの、完全にLINUXベースの実装が作成される。このサーバは、PPPデーモン、PPTPサーバプログラム及びMPPE LINUXカーネルモジュールという3つの部分を有する。以下、これらの3つの部分のそれぞれについて説明する。
【0183】
・PPPのインストール
LINUXシステムは通常、既にPPPデーモン(pppd)がインストールされている可能性がある。しかし、現在のバージョンは、Microsoft Point−to−Point Encryptionプロトコル(MPPE)のパラメータのネゴシエーションをサポートしていない可能性がある。従って、新しいpppdのバージョンをPPTPサーバに含めることが必要になる場合がある。これを実行するには、以下のことが必要である。
【0184】
PPPデーモン実行可能ファイルを/usr/sbin/pppdにコピーする。
【0185】
/usr/sbin/pppdの所有者(オーナ)をルートに設定し、このファイルのset−uidビットをセットする(新しいトンネルを確立するとき、pppdは、プログラムroute及びarpを呼び出して、システムのルーティングテーブル及びARPテーブルを変更する必要があり、これはスーパーユーザ特権を必要とする)。
【0186】
configファイルにより、1行に1つのオプションずつ、pppdを構成する。重要なオプションを図12に示す。
【0187】
MS−CHAP認証プロセス中にpppd自身を呼出し側(リモートクライアント)に対して認証し、呼出し側の識別を確認するために使用する、図13に示すような秘密情報をpppdに与える。
【0188】
・PPTPデーモンのインストール
PPTPデーモンは、TCPポート1723で、呼出しの到着を待機する。ダイヤルイン要求(すなわち、新しいトンネルを確立する要求)が受信されると、PPTPデーモンは、呼出し側とのTCP制御コネクションと、追加のワークロードコネクションを確立する。これらのステップが正しく完了した場合、PPTPデーモンはPPPデーモンを起動し、エンドレスループで、トンネルを通じて受信するすべてのデータをPPPデーモン入力にコピーする。逆に、PPTPデーモンは、PPPデーモンの出力をインターセプトして、トンネルを通じてそれをリモートクライアントへ送る。
【0189】
PPPデーモンは、ファイル/etc/ppp/optionsを読み出して自分を構成し、リモート側の相手とのネゴシエーションを開始する。後で暗号化がネゴシエートされる場合でも、このネゴシエーションプロセス中に交換されるメッセージは暗号化されない。ネゴシエーションの完了後、PPPデーモンはローカルネットワークインタフェースを作成し(例えばLINUX上ではppp0)、すべての出力IPパケットをPPPパケット内にカプセル化する。PPTPサーバは、これらのパケットを、PPPデーモンの出力からインターセプトして、GRE(General Routing Encapsulation)パケット内にカプセル化した後にトンネルを通じて送信する。同様に、逆方向では、PPTPデーモンはリモートクライアントからGREパケットを受信し、PPPパケットを取り出し、それをPPPデーモンの入力に転送し、そこで、カプセル化されたIPパケットが取り出される。
【0190】
PPTPサーバ(pptp−server)は単一のプログラムである。これは、例えば、/usr/sbin/pptp#serverのようにインストールされなければならない。特別な特権は不要である。
【0191】
PPTPサーバを実行するために現在のところ好ましい方法は、TCPポート1723をモニタしてこのポートに対するコネクション要求が到着したときに自動的にPPTPデーモンを起動するように、インターネットデーモンinetdを構成することである。PPTPサーバの位置が上記の通りであると仮定すると、inetd構成(コンフィグレーション)ファイル内の対応する行は図14に示すようにすることが可能である。
【0192】
ただし、これは、PPTPサービスの名前pptpが、図15に示すように/etc/servicesファイル内の行によってシステムに導入されていることを仮定している。
【0193】
・MPPE暗号化モジュールのインストール
MPPEは、暗号化/復号を、圧縮/伸長の特殊な形式と見なす。圧縮/伸長アルゴリズムが、圧縮モジュールを通じてLINUXに利用可能になっていなければならない。このようなモジュールは、静的にカーネル内にコンパイルすることも可能であり(その場合にはこのようなモジュールは常に利用可能となる)、あるいは、コマンドinsmod mppe#compで動的にロードされることも可能である。
【0194】
・トンネルのセットアップ
IPトンネルは、アクセスルータと、ホスティングネットワークの企業ファイアウォールの外部のマシンとの間に、ゲストからのすべてのトラフィックが公衆インターネットまでの途中で保護されることを保証するように作成される。ここで、「保護」とは、ファイアウォールを通って戻ることなしに、ゲストステーションから来るパケットがその出力パスを離れることや、ホスト側組織のネットワーク内のステーションに到達することができないことを保証することを意味する。
【0195】
IP−over−IPトンネルは、このような保護機構を確立するための多くの可能な技術のうちの1つに過ぎない。このようなトンネルを使用することは、最も少ないオーバーヘッドしか要求しないために、好ましい。次に、このようなトンネルを確立する実際の例について説明する。
【0196】
2つのマシン128.1.1.1と128.2.2.2の間にIP−over−IPトンネルを確立するために、擬似ネットワークインタフェースtun10を作成し構成しなければならない(これらのIPアドレスは、これらのトンネルエンドポイントのイーサネットインタフェースに属するものである)。
【0197】
図16に示すコマンドは、IPアドレス128.1.1.1のマシン(アクセスルータ)からIPアドレス128.2.2.2のマシン(外部ルータ)への一方向トンネルを作成する。
【0198】
外部ルータ(外部ポストということもある)が入力トラフィックに対するルータとして作用しない場合、プロキシARPを用いて、外部ルータがc/oアドレスに対する入力トラフィックを受信することを保証しなければならない。以下のコマンドはこれを実行するが、認識されるように、外部ルータがイーサネットインタフェースeth0を通じて、入力トラフィックを運ぶネットワークセグメントに接続されていると仮定している。
arp −s <c/o address> <eth0−hardware−addr> −i eth0 pub
【0199】
第4実施形態
本発明の第4実施形態は、IPアドレスの大きいプールの必要性を回避する方法を提供する。
【0200】
多数のゲストをサポートすることができるためには、ホスト側組織は十分多くのc/oアドレス(ゲストごとに1つのアドレス)を確保しなければならない。ゲストの数とポータブルデバイスの数は増大するであろう。インターネットのルーティング構造のもとでは、与えられたアクセスルータに新しいc/oアドレスを割り当てることが困難である。これらの2つのファクタが組み合わさることにより、ホスト側組織に重大な問題を生じる可能性がある。
【0201】
本発明のこの第4実施形態によれば、2つの機能がc/oアドレスによって実行される。第1に、c/oアドレスは、応答(返信)トラフィックがゲストのホームネットワークの代わりにアクセスルータへルーティングされることを保証する。第2に、一意的なc/oアドレスにより、アクセスルータは、それぞれの返信パケットが属するゲストを識別する。
【0202】
第1の目的を実現するためには、すべてのゲストに対する単一のc/oアドレスで十分である。第2の目的のためには、IPマスカレード(4)と呼ばれる技術を適用することにより、TCPあるいはUDPのポート番号を用いて、入力IPパケットに対応するゲストを識別する。
【0203】
ホーム−c/o IPアドレス変換と同様に、アクセスルータは、ゲストのソースポート番号を、ルータ内で一意的なc/oソースポート番号に変換する。c/o IPアドレスはすべてのゲストに対して同一となる。一意的なソースポート番号(返信トラフィックにおいてデスティネーションポート番号として現れる)を用いて、ゲストサービスレコード(これは、c/oアドレスをゲストの真の(ホーム)IPアドレスで置換するために必要となる)を検索し、c/oポート番号をもとのソースポート番号で置換することが可能である。こうして、ゲストごとに平均で10個以下の同時コネクションがある場合に、c/oアドレスあたり6,500までのゲストをサポートすることが可能である。
【0204】
ただし、IPマスカレードは、UDPやTCPのように、ポート番号で上位レベルプロトコルを運ぶIPトラフィックに対してのみうまく動作する。しかし、これらのプロトコルは、まさにゲストが最も関心のあるプロトコルであり、上記のPPTP IPトンネルを作成するのに必要なプロトコルである。ゲストは、IPトンネルを確立した後、再び、他のすべてのゲストとは独立に、216個のすべてのポート番号を使用することが可能である。
【0205】
第5実施形態
本発明の第5実施形態は、効率的なDNS問合せ(クエリ)の取扱いを実現する。
【0206】
DNSは、既に述べたように、www.nec.comのような人間が読取り可能なホスト名を143.101.250.20のようなIPアドレスへと解決するネットワークサービスである。ゲストステーションのIP設定には、ゲストのホームネットワークにおけるいくつかのDNSサーバ(これらにすべてのDNSと居合わせ葉送られる)が指定されているはずである。DNS問合せを含むIPパケットは、IPヘッダのプロトコルフィールドにおける値17(これはUDPを示す)と、UDPヘッダにおけるデスティネーションポート番号53(これはDNSを示す)によって認識することができる。
【0207】
この実施形態によるアクセスルータは、DNS問合せであるIPパケットを認識すると、そのDNSとい合わせのデスティネーションIPアドレスを、ローカルDNSサーバのIPアドレスで置換する。DNSはグローバルなネットワークサービスであるため、問合せが、ゲストステーションのホームネットワークのDNSエージェントの代わりに実際にはホスト側組織のDNSエージェントによって応答されることは、ホスティングネットワークのローカルなDNSエージェントを使用するほうが高速で効率的に動作することを除いては、実際上何の問題もない。
【0208】
このことは、DNS問合せが公衆インターネット上で見えるホストに対して行われる限りにおいて正しい。しかし、ゲストのホームネットワークのDNSサーバが、外部には見えないマシンに関するエントリを維持している可能性がある。そのようなホストに関する問合せは、ホスト側組織のローカルDNSサーバによっては明らかに応答され得ない。さらに、ホスト側組織は、ローカルDNSサーバへのアクセス権を任意のゲストに与えることに関して予約を有する可能性がある。ゲストは、ホスト側組織のネットワークの外部から見えることを想定していないホスティングネットワークに関する情報を受けとる可能性があるからである。従って、この第5実施例の変形によれば、DNS問合せをローカルDNSサーバへリダイレクトする機能は、ホスト側組織によってオフにすることが可能なオプションである。すなわち、DNSリダイレクト機能は、現在の好ましい実施例では選択可能な機能である。
【0209】
このような選択可能性を実現するために、アクセスルータは制御インタフェースを有することが可能である。この実施例の実際の実装では、この制御インタフェースは、CORBA(5)に基づくオープンな実装とすることが可能である。このようなインタフェースにより、リモートクライアントは、現在登録されているゲストのリストを取得することが可能となる。さらに、これは、DNSサーバを特定のゲストに割り当てる方法や、DNS問合せリダイレクト機能をオフにするための方法を提供する。
【0210】
CORBAは本来的にリモートアクセスをサポートするため、ホスト側組織のネットワーク管理者は、アクセスルータをリモート制御することができる。相互ピア認証やデータ暗号化のようなCORBAの組込みセキュリティ機能は、このインタフェースの無権限の使用に対する保護を行う。
【0211】
第6実施形態
DNS問合せリダイレクトが提供される第5実施形態と同様に、この実施形態は、ローカルプリンタあるいはプリントサーバへのプリントジョブのリダイレクトを提供する。アクセスルータは、プリントサービス要求が認識されると、ゲストステーションからのパケット内のIPデスティネーションアドレスをローカルプリンタあるいはプリントサーバのIPアドレスで置換することによりこれをサポートすることができる。プリントサービスに関連するトラフィックは、デスティネーションポート番号によって認識される。本発明のこの実施形態によれば、アクセスルータは、オープンなCORBAベースのインタフェースを提供する。これによれば、特定のローカルプリンタを各ゲストに割り当てること、あるいは、プリントリダイレクトを選択的にオフにすること(この場合、プリントサービス要求によってゲストのホームにあるプリンタが起動される)が可能となる。
【0212】
第7実施形態
本発明の第7実施形態は、ゲストサービスレコードの制御のためのGUIを提供する。このGUIは、ホスティングネットワークのシステム管理者のためのコンポーネントと、ゲストステーションを使用するゲストのためのコンポーネントを含む。
【0213】
[ホスト側組織のシステム管理者のためのコンポーネント]
ホスト側組織のシステム管理者は、CORBA機能付きJavaアプレットを提供するウェブサイトをアクセスルータ(access−router)からダウンロードすることができる(URL http://<access−router>/GuestIPcontrol.html)。このアプレットは、現在登録されているゲスト、そのゲストのホームIPアドレス、及び、そのゲストに割り当てられているc/oアドレスのリストを示すGUIを備える。このリストから項目を選択することによって、システム管理者は、特定のゲストについての詳細、例えば、そのゲストが登録された時刻や、そのゲストが選択することが可能なローカルDNSサーバ及びローカルプリンタのリスト、を問い合わせることができる。そして、システム管理者は、このリストをゲストごとに編集して、特定のゲストにさらに選択肢を与えたり、選択肢を減らしたりすることができる。さらに、システム管理者は、選択されたゲストの代わりに、利用可能な選択肢のうちの1つを選択する特権を有する。
【0214】
[ゲストのためのコンポーネント]
ホスト側組織のシステム管理者によって設定される制限内で、ゲストは、ウェブページhttp://<access−router>/GuestIP.htmlを開くことが可能である。このウェブページは、ローカルサーバへのDNS問合せのリダイレクトや、ローカルプリンタへのプリンタ要求のリダイレクトの現在の設定を示すCORBA機能付きJavaアプレットを提供する。
【0215】
次に、パフォーマンスについていくつかの考察を行う。
【0216】
パフォーマンス
アクセスルータにおいてc/oアドレス変換を実行するための主なコストは、ゲストのサービスレコードのルックアップと、IP/UDP/TCP/ICMPヘッダのチェックサムの再計算である。ゲストのサービスレコードは、ゲストとの間のIPパケットごとに検索する必要がある。ルックアップは、トラフィックの方向に依存して、ゲストのホームアドレスまたはc/oアドレスに基づく。このオペレーションのコストはO(log(n))である。ただし、nは登録されているゲストの数である。nは通常小さい(20より小さい)ため、このオペレーションによって受ける転送遅延は無視し得る。
【0217】
ヘッダチェックサムの再計算(チェックサムフィールド自体を除くIPパケット全体の16ビットの1の補数の1の補数和)のコストは、IPパケットサイズに線形に比例する。しかし、ソースIPアドレスフィールドのみが変更されるため、このコストは、ゲストによって前に計算されたIPチェックサムを再使用する際には一定となる。
【0218】
認識されるように、本発明の上記の実施例によるアクセスルータを用いたIPゲストサポートはネットワークエッジで提供される。ここでは、要求されるスループットは、コアネットワークほど厳しくはない。
【0219】
【発明の効果】
結論
インターネットは、現在の支配的なネットワークである。ユーザ数と高度なサービスの数の急速な増大により、インターネットに接続されることは日々ますます重要になっている。同時に、コンピュータのようなネットワークのエンドサービスの物理的サイズは急速に減少しており、(潜在的に)ポータブルになっている。これには、ラップトップのみならず、小型のプリンタ、入力/スキャンデバイス、カメラ、及びその他の、近い将来の多くの有用な装置が含まれる。これらのポータブルデバイスが固有の一意的IPアドレスを有するようになり、これがグローバルに一意的な識別を提供する。本発明によれば、これらのデバイスは、一時的なロケーションにおいても、IPサービスを容易かつ簡単に受けられ、ゲストステーションをホストする際の問題点が解決される。
【0220】
本発明によるIPアクセスによれば、ホスト側組織は、ローカルなc/oアドレスをポータブルデバイスに関連づける。ポータブルデバイス(すなわち、ゲストステーション)でのサポートや変更を必要とせずに、インテリジェントアクセスルータは透過的にポータブルデバイスのIPアドレス(ホームアドレス)を、そのデバイスの現在のロケーションを指定する関連づけられたc/oアドレスで置換する。これにより、帰路トラフィックがポータブルデバイスの現在のロケーションに到達することが可能となる。このアドレス変換は入力トラフィックに対しては元に戻されるため、全体のプロセスはポータブルデバイスにとっては透過的なままである。
【0221】
ホスト側組織は、IPトンネルを用いて、悪意のあるゲストに対して自分を効果的に保護することができる。さらに、ゲスト(すなわち、ポータブルデバイス)は、セキュアIPトンネルを用いて、自分をホスト側組織及び公衆インターネットに対して保護することができる。最後に、IPマスカレードにより、アクセスポイントにおいて多数のポータブルデバイスをサポートするのに必要なc/oアドレスの数を大幅に少なくすることができる。
【0222】
さらに、ゲストを、ローカルネットワークの設定(DNSサーバやプリンタのアドレスなど)に適合させるためのフレキシブルな機構により、ローカルネットワーク管理者の作業が軽減される。新たな、あるいは一時的に異なるネットワーク設定についての情報をあらゆるユーザのローカルシステムに入れる必要がないためである。
【図面の簡単な説明】
【図1】コンピュータ及びそのいくつかのモジュールの例を示す図である。
【図2】ネットワーク上のステーションを示す図である。
【図3】互いに通信していない2つのネットワークの図である。
【図4】より概念的に、互いに通信していない3つのネットワークを示す図である。
【図5】ネットワークによって相互接続された図4の3つのネットワークの図である。
【図6】ルータがどのようにして2つのネットワークを接続するかを示す図である。
【図7】IPパケットのヘッダの図である。
【図8】1つのステーションが外部ネットワークのゲストステーションであるような、図5のネットワークの図である。
【図9】本発明の実施例によるルータを通じてゲストがターゲットマシンと通信することを示す図である。
【図10】公衆インターネットにおける、アクセスルータと次ホップルータの間のIPトンネルを示す図である。
【図11】IP接続を用いて、ゲストステーションがどのようにして、自分と、信頼されたエンティティ(例えば、ゲストステーションのレギュラーネットワーク内のVPNサーバ)との間にセキュアIPトンネルを作成するかを示す図である。
【図12】本発明の一実施例の具体的実装に関連するいくつかの具体的なコマンド及びエントリを示す図である。
【図13】本発明の一実施例の具体的実装に関連するいくつかの具体的なコマンド及びエントリを示す図である。
【図14】本発明の一実施例の具体的実装に関連するいくつかの具体的なコマンド及びエントリを示す図である。
【図15】本発明の一実施例の具体的実装に関連するいくつかの具体的なコマンド及びエントリを示す図である。
【図16】本発明の一実施例の具体的実装に関連するいくつかの具体的なコマンド及びエントリを示す図である。
【図17】IPパケットを送信するステーションに関連する流れ図である。
【図18】本発明の実施例によるアクセスルータがホスティングネットワーク上に設けられた、図8のネットワークの図である。
【図19】本発明の実施例によるアクセスルータの概略図である。
【図20】本発明の実施例によるアクセスルータの動作に関する流れ図である。
【符号の説明】
10 汎用デジタルコンピュータ
100 中央処理装置(CPU)
110 メインメモリ
120 I/Oプロセッサ
130 I/Oデバイス
140 ネットワークアダプタ
200 第1のネットワーク
210 コンピュータ
220 コンピュータ
230 コンピュータ
240 コンピュータ
300 第2のネットワーク
310 コンピュータ
320 コンピュータ
330 コンピュータ
340 コンピュータ
400 第2のネットワーク
410 レギュラーステーション
420 レギュラーステーション
430 レギュラーステーション
440 レギュラーステーション
500 インターネットワーク
502 アクセスステーション
503 アクセスステーション
504 アクセスステーション
600 ルータ
900 アクセスルータ
910 CPU
920 メモリ
921 ARPあて先テーブル
922 ゲストサービステーブル
941 ネットワークアダプタ
942 ネットワークアダプタ
Claims (21)
- あるネットワークのアクセスルータが別のネットワークからのゲストステーションに対してIPサービスを提供するアクセスルーティング方法において、
前記ゲストステーションから、元のソースIPアドレス及びデスティネーションIPアドレスを有する元の出力IPパケットをインターセプトするインターセプトステップと、
前記元のソースIPアドレスをc/o(care-of)アドレスに関連づける関連づけステップと、
前記元の出力IPパケットに基づいて変更された出力IPパケットに、前記元のソースIPアドレスの代わりに前記c/oアドレスを提供するステップと、
を有し、前記インターセプトステップは、
前記ゲストステーションから送信される、前記アクセスルータ以外のステーション宛のARP要求を検出するステップと、
前記ARP要求のARP宛先がARP宛先テーブルに登録されているか否かを判定するステップと、
前記ARP宛先が前記ARP宛先テーブルに登録されていない場合は、前記ARP要求に対するARP応答を検出したか否かを判定するステップと、
前記ARP要求に対するARP応答を検出しなかった場合は、前記ARP要求に対して、前記アクセスルータのハードウェアアドレスを含むプロキシARP応答を前記ゲストステーションへ送信し、前記ARP宛先を非ローカルステーションとして前記ARP宛先テーブルに登録するステップと、
前記ARP要求に対する前記ARP応答を検出した場合は、前記ARP宛先をローカルステーションとして前記ARP宛先テーブルに登録するステップと、
前記ARP宛先が前記ARP宛先テーブルに登録されている場合は、前記ARP宛先がローカルステーションであるか否かを判定するステップと、
前記ARP宛先がローカルステーションであれば、終了するステップと、
前記ARP宛先がローカルステーションでなければ、前記ARP要求に対して、前記アクセスルータのハードウェアアドレスを含むプロキシARP応答を前記ゲストステーションへ送信し、前記ARP宛先を非ローカルステーションとして前記ARP宛先テーブルに登録するステップと、
前記ARP要求に対して前記アクセスルータのハードウェアアドレスを含むプロキシARP応答を前記ゲストステーションへ送信するステップと、
を有することを特徴とするアクセスルーティング方法。 - 前記ARP要求に対するARP応答を検出したか否かを判定するステップは、予め定められた期間内で検出するか否かを判定することを特徴とする請求項1記載の方法。
- 前記関連づけステップは、
前記ゲストステーションのソースポート番号を前記ゲストステーションに一意的なc/oポート番号に関連づけるステップを含むことを特徴とする請求項1記載の方法。 - 外部ステーションへのIPトンネルを通じて前記変更された出力IPパケットを送信するステップをさらに有することを特徴とする請求項1記載の方法。
- DNSリダイレクトステップをさらに有し、
該DNSリダイレクトステップは、
DNS問合せパケットをインターセプトするステップと、
インターセプトされたDNS問合せパケットのデスティネーションIPアドレスを、ローカルDNSサーバのIPアドレスで置換して、変更されたDNS問合せパケットを提供するステップと、
前記変更されたDNS問合せパケットを前記ローカルDNSサーバへ送るステップと、
からなることを特徴とする請求項1記載の方法。 - 前記DNSリダイレクトステップは選択可能であることを特徴とする請求項5記載の方法。
- プリントジョブリダイレクトステップをさらに有し、
該プリントジョブリダイレクトステップは、
プリントジョブパケットをインターセプトするステップと、
インターセプトされたプリントジョブパケットのデスティネーションIPアドレスを、ローカルプリンタのIPアドレスで置換して、変更されたプリントジョブパケットを提供するステップと、
前記変更されたプリントジョブパケットを前記ローカルプリンタへ送るステップと、
からなることを特徴とする請求項1記載の方法。 - 前記プリントジョブリダイレクトステップは選択可能であることを特徴とする請求項7記載の方法。
- 外部ネットワークと内部ネットワークとの間にファイアウォール装置を有し、前記アクセスルータは前記内部ネットワーク内の所定ネットワークに設けられ、
前記アクセスルータから前記外部ネットワークの所定外部ステーションへのIPトンネルを通じて前記c/oアドレスが提供された出力IPパケットを前記外部ネットワークへ直接送信するステップを更に有することを特徴とする請求項1に記載の方法。 - 前記c/oアドレスが提供された出力IPパケットのデスティネーションIPアドレスが前記内部ネットワーク内のIPアドレスである場合には、前記c/oアドレスが提供された出力IPパケットは、前記外部ステーションから前記ファイアウォール装置を通して前記内部ネットワークへ入るステップを更に有することを特徴とする請求項9記載の方法。
- 前記インターセプトステップは、
前記ゲストステーションから送信される、前記アクセスルータ以外のステーション宛のARP要求を検出するステップと、
前記ARP要求のARP宛先がARP宛先テーブルに登録されているか否かを判定するステップと、
前記ARP宛先が前記ARP宛先テーブルに登録されていない場合は、前記ARP要求に対するARP応答を検出したか否かを判定するステップと、
前記ARP要求に対するARP応答を検出しなかった場合は、前記ARP要求に対して、前記アクセスルータのハードウェアアドレスを含むプロキシARP応答を前記ゲストステーションへ送信し、前記ARP宛先を非ローカルステーションとして前記ARP宛先テーブルに登録するステップと、
前記ARP要求に対する前記ARP応答を検出した場合は、前記ARP宛先をローカルステーションとして前記ARP宛先テーブルに登録するステップと、
前記ARP宛先が前記ARP宛先テーブルに登録されている場合は、前記ARP宛先がローカルステーションであるか否かを判定するステップと、
前記ARP宛先がローカルステーションであれば、終了するステップと、
前記ARP宛先がローカルステーションでなければ、前記ARP要求に対して、前記アクセスルータのハードウェアアドレスを含むプロキシARP応答を前記ゲストステーションへ送信し、前記ARP宛先を非ローカルステーションとして前記ARP宛先テーブルに登録するステップと、
前記ARP要求に対して前記アクセスルータのハードウェアアドレスを含むプロキシ ARP応答を前記ゲストステーションへ送信するステップと、
を有することを特徴とする請求項9または10に記載の方法。 - ゲストステーションにIP層アクセスを提供するシステムにおいて、
ゲストステーションIPアドレスを有するゲストステーションと、
前記ゲストステーションと通信するホスティングネットワークと、
前記ホスティングネットワークに参加するアクセスルータとを有し、
前記アクセスルータは、
前記ゲストステーションから送信される、前記アクセスルータ以外のステーション宛のARP要求を検出し、
前記ARP要求のARP宛先がARP宛先テーブルに登録されているか否かを判定し、
前記ARP宛先が前記ARP宛先テーブルに登録されていない場合は、前記ARP要求に対するARP応答を検出したか否かを判定し、
前記ARP要求に対するARP応答を検出しなかった場合は、前記ARP要求に対して、前記アクセスルータのハードウェアアドレスを含むプロキシARP応答を前記ゲストステーションへ送信して、前記ARP宛先を非ローカルステーションとして前記ARP宛先テーブルに登録し、
前記ARP要求に対する前記ARP応答を検出した場合は、前記ARP宛先をローカルステーションとして前記ARP宛先テーブルに登録し、
前記ARP宛先が前記ARP宛先テーブルに登録されている場合は、前記ARP宛先がローカルステーションであるか否かを判定し、
前記ARP宛先がローカルステーションであれば終了し、
前記ARP宛先がローカルステーションでなければ、前記ARP要求に対して、前記アクセスルータのハードウェアアドレスを含むプロキシARP応答を前記ゲストステーションへ送信して、前記ARP宛先を非ローカルステーションとして前記ARP宛先テーブルに登録し、
前記ARP要求に対して前記アクセスルータのハードウェアアドレスを含むプロキシARP応答を前記ゲストステーションへ送信することで、
前記ゲストステーションから送信されてくる、元のソースIPアドレス及びデスティネーションIPアドレスを有する元の出力IPパケットをインターセプトし、
前記元のソースIPアドレスをc/o( care-of )アドレスに関連づける関連づけ、
前記元の出力IPパケットに、前記元のソースIPアドレスの代わりに前記c/oアドレスを提供することを特徴とするゲストステーションにIP層アクセスを提供するシステム。 - 前記アクセスルータは、IPマスカレードを用いて、前記ゲストステーションIPアドレスをc/oアドレスで置換することを特徴とする請求項12記載のシステム。
- ゲストステーションがホスティングネットワークに接続される際に該ゲストステーションにIPアクセスを提供するためのコンピュータシステムにおいて、
プロセッサとソフトウェア命令を含むメモリとを有し、
前記ソフトウェア命令は、前記コンピュータシステムが、
前記ゲストステーションから、元のソースIPアドレス及びデスティネーションIPアドレスを有する元の出力IPパケットをインターセプトするインターセプトステップと、
前記元のソースIPアドレスをc/o(care-of)アドレスに関連づける関連づけステップと、
前記元の出力IPパケットに基づいて変更された出力IPパケットに、前記元のソースIPアドレスの代わりに前記c/oアドレスを提供するステップと、
を実行することを可能にし、
前記インターセプトステップは、
前記ゲストステーションから送信される、前記アクセスルータ以外のステーション宛のARP要求を検出するステップと、
前記ARP要求のARP宛先がARP宛先テーブルに登録されているか否かを判定するステップと、
前記ARP宛先が前記ARP宛先テーブルに登録されていない場合は、前記ARP要求に対するARP応答を検出したか否かを判定するステップと、
前記ARP要求に対するARP応答を検出しなかった場合は、前記ARP要求に対して、前記アクセスルータのハードウェアアドレスを含むプロキシARP応答を前記ゲストステーションへ送信し、前記ARP宛先を非ローカルステーションとして前記ARP宛先テーブルに登録するステップと、
前記ARP要求に対する前記ARP応答を検出した場合は、前記ARP宛先をローカルステーションとして前記ARP宛先テーブルに登録するステップと、
前記ARP宛先が前記ARP宛先テーブルに登録されている場合は、前記ARP宛先がローカルステーションであるか否かを判定するステップと、
前記ARP宛先がローカルステーションであれば、終了するステップと、
前記ARP宛先がローカルステーションでなければ、前記ARP要求に対して、前記アクセスルータのハードウェアアドレスを含むプロキシARP応答を前記ゲストステーションへ送信し、前記ARP宛先を非ローカルステーションとして前記ARP宛先テーブルに登録するステップと、
前記ARP要求に対して前記アクセスルータのハードウェアアドレスを含むプロキシARP応答を前記ゲストステーションへ送信するステップと、
を実行することを可能にすることを特徴とするコンピュータシステム。 - 前記ARP要求に対するARP応答を検出したか否かを判定するステップは、予め定められた期間内で検出するか否かを判定することを特徴とする請求項14記載のシステム。
- 前記関連づけステップは、
前記ゲストステーションのソースポート番号を前記ゲストステーションに一意的なc/oポート番号に関連づけるステップを含むことを特徴とする請求項14記載のシステム。 - 前記ソフトウェア命令は、前記コンピュータシステムが、外部ステーションへのIPトンネルを通じて前記変更された出力IPパケットを送信するステップを実行することを可能にするソフトウェア命令を含むことを特徴とする請求項14記載のシステム。
- ゲストステーションがホスティングネットワークに接続される際に、コンピュータが該ゲストステーションにIPアクセスを提供することを可能にするコンピュータプログラムを記録した記録媒体において、
前記コンピュータプログラムは、
前記ゲストステーションから、元のソースIPアドレス及びデスティネーションIPアドレスを有する元の出力IPパケットをインターセプトするインターセプトステップと、
前記元のソースIPアドレスをc/o(care-of)アドレスに関連づける関連づけステップと、
前記元の出力IPパケットに基づいて変更された出力IPパケットに、前記元のソースIPアドレスの代わりに前記c/oアドレスを提供するステップと、
を実行することを可能にし、
前記インターセプトステップは、
前記ゲストステーションから送信される、前記アクセスルータ以外のステーション宛のARP要求を検出するステップと、
前記ARP要求のARP宛先がARP宛先テーブルに登録されているか否かを判定するステップと、
前記ARP宛先が前記ARP宛先テーブルに登録されていない場合は、前記ARP要求に対するARP応答を検出したか否かを判定するステップと、
前記ARP要求に対するARP応答を検出しなかった場合は、前記ARP要求に対して、前記アクセスルータのハードウェアアドレスを含むプロキシARP応答を前記ゲストステーションへ送信し、前記ARP宛先を非ローカルステーションとして前記ARP宛先テーブルに登録するステップと、
前記ARP要求に対する前記ARP応答を検出した場合は、前記ARP宛先をローカルステーションとして前記ARP宛先テーブルに登録するステップと、
前記ARP宛先が前記ARP宛先テーブルに登録されている場合は、前記ARP宛先がローカルステーションであるか否かを判定するステップと、
前記ARP宛先がローカルステーションであれば、終了するステップと、
前記ARP宛先がローカルステーションでなければ、前記ARP要求に対して、前記アクセスルータのハードウェアアドレスを含むプロキシARP応答を前記ゲストステーションへ送信し、前記ARP宛先を非ローカルステーションとして前記ARP宛先テーブルに登録するステップと、
前記ARP要求に対して前記アクセスルータのハードウェアアドレスを含むプロキシARP応答を前記ゲストステーションへ送信するステップと、
を含むことを特徴とする記録媒体。 - 前記ARP要求に対するARP応答を検出したか否かを判定するステップは、予め定められた期間内で検出するか否かを判定することを特徴とする請求項18記載の記録媒体。
- 前記関連づけステップは、
前記ゲストステーションのソースポート番号を前記ゲストステーションに一意的なc/oポート番号に関連づけるステップを含むことを特徴とする請求項18記載の記録媒体。 - 前記所定オペレーションは、外部ステーションへのIPトンネルを通じて前記変更された出力IPパケットを送信するステップをさらに含むことを特徴とする請求項18記載の記録媒体。
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US09/357,907 US6591306B1 (en) | 1999-04-01 | 1999-07-21 | IP network access for portable devices |
US09/357907 | 1999-07-21 |
Publications (2)
Publication Number | Publication Date |
---|---|
JP2001057572A JP2001057572A (ja) | 2001-02-27 |
JP3575369B2 true JP3575369B2 (ja) | 2004-10-13 |
Family
ID=23407520
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2000021419A Expired - Fee Related JP3575369B2 (ja) | 1999-07-21 | 2000-01-31 | アクセスルーティング方法及びアクセス提供システム |
Country Status (1)
Country | Link |
---|---|
JP (1) | JP3575369B2 (ja) |
Families Citing this family (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP3873758B2 (ja) | 2002-02-05 | 2007-01-24 | コニカミノルタビジネステクノロジーズ株式会社 | ネットワークシステム |
US8027271B2 (en) | 2006-05-30 | 2011-09-27 | Panasonic Corporation | Communicating apparatus and controlling method of thereof |
JP2008211446A (ja) * | 2007-02-26 | 2008-09-11 | Nippon Telegr & Teleph Corp <Ntt> | 通信システムおよび通信方法 |
WO2017007783A1 (en) | 2015-07-06 | 2017-01-12 | Convida Wireless, Llc | Wide area service discovery for internet of things |
-
2000
- 2000-01-31 JP JP2000021419A patent/JP3575369B2/ja not_active Expired - Fee Related
Also Published As
Publication number | Publication date |
---|---|
JP2001057572A (ja) | 2001-02-27 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US6591306B1 (en) | IP network access for portable devices | |
US8526467B2 (en) | Facilitating transition of network operations from IP version 4 to IP version 6 | |
US8713641B1 (en) | Systems and methods for authorizing, authenticating and accounting users having transparent computer access to a network using a gateway device | |
US7925693B2 (en) | NAT access control with IPSec | |
US7792995B2 (en) | Accessing data processing systems behind a NAT enabled network | |
US8897299B2 (en) | Method and systems for routing packets from a gateway to an endpoint | |
US10469444B2 (en) | System and method for direct connections between previously unconnected network devices across one or more unknown networks | |
EP1479008B1 (en) | Method and system for resolving addressing conflicts based on tunnel information | |
US20130111066A1 (en) | Device and Method for Split DNS Communications | |
JP2002502152A (ja) | Tcp/ipネットワーク・アドレス携帯端末のためのプロキシ・サーバ | |
US20070078996A1 (en) | Method for managing a network appliance and transparent configurable network appliance | |
JP4600394B2 (ja) | ネットワークアクセスルータ、ネットワークアクセス方法、プログラム、及び記録媒体 | |
US20210273915A1 (en) | Multi-access interface for internet protocol security | |
JP3858884B2 (ja) | ネットワークアクセスゲートウェイ及びネットワークアクセスゲートウェイの制御方法並びにプログラム | |
US9509659B2 (en) | Connectivity platform | |
US10805260B2 (en) | Method for transmitting at least one IP data packet, related system and computer program product | |
WO2001097485A2 (en) | Method for providing transparent public addressed networks within private networks | |
Henderson et al. | The Host Identity Protocol (HIP) Experiment Report | |
JP3575369B2 (ja) | アクセスルーティング方法及びアクセス提供システム | |
US7715326B2 (en) | Webserver alternative for increased security | |
Crocker | Multiple address service for transport (mast): An extended proposal | |
US7089334B2 (en) | Intelligent network interface port for visiting computers | |
Sheikh | Networking Fundamentals | |
CN113067908B (zh) | 一种nat穿越方法、装置、电子设备和存储介质 | |
Sheikh et al. | Network Fundamentals and Infrastructure Security |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20040323 |
|
A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20040524 |
|
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: 20040615 |
|
A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20040628 |
|
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: 20070716 Year of fee payment: 3 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20080716 Year of fee payment: 4 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20090716 Year of fee payment: 5 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100716 Year of fee payment: 6 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110716 Year of fee payment: 7 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110716 Year of fee payment: 7 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120716 Year of fee payment: 8 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120716 Year of fee payment: 8 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130716 Year of fee payment: 9 |
|
LAPS | Cancellation because of no payment of annual fees |