(57)【要約】  ネットワークノードとルーティング可能なアドレスを発見するシステムおよび関連する方法は、スキャンサーバと、ローカルリンクセグメントと、ローカルリンクセグメントに接続するエージェントと、スキャンサーバをエージェントと通信するように設置するために接続するルータとを具備する。スキャンサーバは、ローカルリンクセグメントに接続するネットワークノードを発見するようにエージェントに命令する。エージェントは、ローカルリンクセグメントに接続するネットワークノードを発見するために、スキャンサーバからの命令に応答する。エージェントは、またネットワークノードのリンクローカルアドレスを獲得し、リンクローカルアドレスが位置するルーティング可能なサイトローカルアドレスを獲得する。エージェントは、スキャンサーバにルーティング可能なサイトローカルアドレスを提供する。
2009524347.tif 000002
【特許請求の範囲】
【請求項１】
少なくとも１つのスキャンサーバ（１０２）と、
少なくとも１つのローカルリンクセグメント（１１０）と、
前記ローカルリンクセグメント（１１０）に接続する少なくとも１つのエージェント（１１４）と、
前記スキャンサーバ（１０２）を前記エージェント（１１４）と通信するように設置して接続する少なくとも１つのルータ（１１２）とを備え、
前記エージェント（１１４）は、前記スキャンサーバ（１０２）に応答して、前記ローカルリンクセグメント（１１０）に接続する少なくとも１つのネットワークノード（２０２）を発見し、前記ネットワークノードに対応するリンクローカルアドレス（２１２）を獲得し、前記リンクローカルアドレス（２１２）が位置するルーティング可能なサイトローカルアドレス（２１８）を獲得し、前記ルーティング可能なサイトローカルアドレス（２１８）をスキャンサーバ（１０２）に提供することを特徴とするシステム。
【請求項２】
前記スキャンサーバは、前記エージェントに命令を発行し、前記エージェントから前記ルーティング可能なサイトローカルアドレスを受信するように適応するノード発見コンポーネントを具備することを特徴とする請求項１に記載のシステム。
【請求項３】
さらに、少なくとも１つの第２のローカルリンクセグメントと、
前記スキャンサーバを前記第２のローカルリンクセグメントと通信するように設置する少なくとも１つの第２のルータとを備え、
さらに、前記第２のローカルリンクセグメントに接続する少なくとも１つの第２のエージェントを備え、
前記第２のエージェントは、前記スキャンサーバに応答して、前記第２のローカルリンクセグメントに接続する少なくとも１つの第２のネットワークノードを発見し、前記第２のネットワークノードに対応する第２のリンクローカルアドレスを獲得し、前記第２のリンクローカルアドレスが位置する少なくとも１つの第２のルーティング可能なサイトローカルアドレスを獲得し、前記第２のルーティング可能なサイトローカルアドレスをスキャンサーバに提供することを特徴とする請求項１に記載のシステム。
【請求項４】
前記エージェントは、前記スキャンサーバからアドレス収穫命令を受信するように適応し、それに応答して前記ネットワークノードに近隣要請メッセージを発行するように適応することを特徴とする請求項１に記載のシステム。
【請求項５】
前記エージェントは、前記近隣要請メッセージに応答して前記ネットワークノードから近隣通知メッセージを受信するように適応し、前記近隣通知メッセージは、少なくとも前記リンクローカルアドレスを具備することを特徴とする請求項４に記載のシステム。
【請求項６】
さらに、前記エージェントから前記リンクローカルアドレスを受信し、前記リンクローカルアドレスをサイトローカルアドレスに位置付けるように適応するバルクリゾルバコンポーネントを備えることを特徴とする請求項１に記載のシステム。
【請求項７】
ローカルリンクセグメントに関連する少なくとも１つのエージェントに、前記ローカルリンクセグメントに接続する少なくとも１つのネットワークノードを発見するように命令するステップ（３０２）と、
前記エージェントから前記ネットワークノードに対応する少なくとも１つのルーティング可能なサイトローカルアドレスを受信するステップ（３０４）と
を具備することを特徴とするコンピュータデバイスにより少なくとも一部は実施される方法。
【請求項８】
さらに、少なくとも１つの第２のローカルリンクセグメントに関連する少なくとも１つの第２のエージェントに、前記第２のローカルリンクセグメントに接続する少なくとも１つの第２のネットワークノードを発見するように命令するステップ（３０２）を具備することを特徴とする請求項７に記載の方法。
【請求項９】
さらに、前記第２のネットワークノードに対応する少なくとも１つの第２のルーティング可能なサイトローカルアドレスを前記第２のエージェントから受信するステップを具備することを特徴とする請求項８に記載の方法。
【請求項１０】
さらに、前記ローカルリンクセグメント上で前記エージェントにより発見される少なくとも１つの前記第２のネットワークノードに対応する少なくとも１つの第２のルーティング可能なサイトローカルアドレスを前記エージェントから受信するステップを具備することを特徴とする請求項７に記載の方法。
【請求項１１】
さらに、複数のルーティング可能なサイトローカルアドレスをリストに収集するステップを具備することを特徴とする請求項７に記載の方法。
【請求項１２】
前記エージェントに命令するステップは、アドレス収穫命令を発行することを含むことを特徴とする請求項７に記載の方法。
【請求項１３】
少なくとも１つのローカルリンクセグメントに接続する少なくとも１つのネットワークノードを発見する命令を受信するステップ（４０２）と、
前記命令に応答して、前記ローカルリンクセグメントに少なくとも１つの第２の命令を発行するステップ（４０４）と、
前記第２の命令に応答して、前記ネットワークノードのための少なくとも１つのリンクローカルアドレスを含む少なくとも１つのメッセージを前記ネットワークノードから受信するステップ（４０６）と
を具備することを特徴とするコンピュータデバイスにより少なくとも一部は実施される方法。
【請求項１４】
前記命令を受信するステップは、アドレス収穫命令を受信するステップを具備することを特徴とする請求項１３に記載の方法。
【請求項１５】
少なくとも１つの第２の命令を発行するステップは、ローカルリンクセグメントに近隣要請メッセージを発行するステップを含むことを特徴とする請求項１３に記載の方法。
【請求項１６】
さらに、前記ローカルリンクセグメントに接続する少なくとも１つの第２のネットワークノードから、前記第２のネットワークノードのための少なくとも１つの第２のリンクローカルアドレスを含む少なくとも１つの第２のメッセージを受信するステップを具備することを特徴とする請求項１３に記載の方法。
【請求項１７】
前記ネットワークノードから少なくとも１つのメッセージを受信するステップは、前記ネットワークノードから近隣通知メッセージを受信するステップを含むことを特徴とする請求項１３に記載の方法。
【請求項１８】
さらに、前記リンクローカルアドレスが位置するルーティング可能なサイトローカルアドレスを獲得するステップを具備することを特徴とする請求項１３に記載の方法。
【請求項１９】
さらに、前記ルーティング可能なサイトローカルアドレスをスキャンサーバに送信するステップを具備することを特徴とする請求項１８に記載の方法。
【請求項２０】
前記ルーティング可能なサイトローカルアドレスを獲得するステップは、バルクリゾルバコンポーネントが前記リンクローカルアドレスをルーティング可能なサイトローカルアドレスに位置付けすることを要求するステップを含むことを特徴とする請求項１８に記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワークノードとルーティング可能なアドレスを発見するシステム及び方法に関する。
【背景技術】
【０００２】
ネットワーク管理者は、しばしば所定のコンピュータネットワーク上のアクティブマシンを発見する必要がある。この技術は、マシンがコンピュータネットワークの基礎をなすプロトコルまたは複数のプロトコルに依存する可能性のあることを発見したものである。インターネットプロトコルＶｅｒｓｉｏｎ４（以下「ＩＰｖ４」）のようなネットワーキングプロトコルでの動作時に、多くのツールおよび技術が、様々なネットワーク管理機能、機械発見、またはポートスキャンを実行するために利用できる可能性がある。問題のネットワークがＩＰｖ４セグメントのみを具備するとき、このときこれらの利用できるツールまたは技術のいずれかが適切である可能性がある。たとえツールまたは技術が利用できないか適切でないとしても、ＩＰｖ４ネットワーク上の力ずくの検索は、２５５．２５５．１９２．０．のネットワークマスクを有する、所定のａ／１８ネットワークの約１６３８４の可能なアドレスの検索を引き起こす可能性がある。マルチスレッド及び非同期のプログラミング技法の組合せを使用した場合、このような力ずくの検索に、約１分を必要とする。
【０００３】
他のより進んだネットワークプロトコルが導入され、益益採用されている。これらのより新しいネットワークプロトコルは、従来のネットワークプロトコルより非常に大きなアドレス空間をサポートする。そのような進んだネットワークプロトコルの１つの例は、インターネットプロトコルＶｅｒｓｉｏｎ６（以下「ＩＰｖ６」）である。ＩＰｖ６は、１２８ビットのアドレス空間をサポートし、その６４ビットはホストアドレスの指定のために予約されている。これは、ホストが見つかる可能性のある２６４（１８４，４６７，４４１，０００，０００，０００，０００）のアドレスが存在する可能性があることを意味する。
【発明の開示】
【発明が解決しようとする課題】
【０００４】
問題のネットワークが少なくとも若干のＩＰｖ６セグメントを具備するならば、ＩＰｖ４下で利用可能なツールは、効果的にＩＰｖ６セグメントに作用しない可能性があるか、全くそのようなセグメントに作用しない可能性がある。ＩＰｖ６ネットワークでノードを見つけるための力ずくのアプローチを使用することは、１８４，４６７，４４１，０００，０００，０００，０００の可能性のあるアドレス全体に亘り検索することを意味する。調査が１／１秒の率で送信すると仮定すると、この大きなアドレスのブロックをスキャンすることは、およそ５，８６５，４９４，０２８，５４０年の長さを与える。１秒当たり１，０００以上の調査を可能にする複合型マルチスレッドおよび非同期通信モデルでさえ、期間は容認できないままである。
【課題を解決するための手段】
【０００５】
ネットワークノードおよびルーティング可能なアドレスを発見するシステム、方法、および／または技術（ツール）は、スキャンサーバと、ローカルリンクセグメントと、ローカルリンクセグメントに接続するエージェントと、スキャンサーバをエージェントと通信するように設置して接続するルータとを具備する。スキャンサーバは、エージェントにローカルリンクセグメントに接続する１つ以上のネットワークノードを発見するようにエージェントに命令する。エージェントは、ローカルリンクセグメントに接続するネットワークノードを発見するために、スキャンサーバからの命令に応答する。エージェントは、ネットワークノードのためのリンクローカルアドレスを獲得し、リンクローカルアドレスが位置するルーティング可能なサイトローカルアドレスを獲得する。エージェントは、ルーティング可能なサイトローカルアドレスをスキャンサーバに提供する。
【０００６】
この概要は、発明の詳細な説明でさらに後述する簡略化された形式の概念の選択を紹介するために提供される。この概要は、要求された主題の鍵となるか重要な特徴を特定することを目的としないし、それは要求された主題の範囲を決定することの援助として使用されることを目的としない。
【０００７】
同じ符号が、構成要素および特徴の同様なものを示す開示および図を通して使用される。参照符号の第１桁の数字は、参照符号が紹介されている図面を示している。
【発明を実施するための最良の形態】
【０００８】
［概説］
以下の記載は、多くの技術及び処理を可能とするツールを記載する。以下の議論は、ツールがネットワークノードとルーティング可能なアドレスの発見を可能にする典型的な方法を記載する。この議論は、またツールが同様に他の技術を実行する方法を記載する。
【０００９】
この記載は、限定でなく、便宜のために選択される見出しにより紹介されるセクションで、便宜のためにセクションに組織される。最初に、操作環境は、ネットワークノードとルーティング可能なアドレスを発見することに関連する操作環境を例示する図１、２と関連して記載され、また実例となるデータフローを提供する。次に、処理フローは、それはネットワークノードとルーティング可能なアドレスを発見することに関連する処理フローを例示する図３、４と関連して記載される。
【００１０】
［操作環境］
図１は、ネットワークノードとルーティング可能なアドレスを発見するための操作環境１００を例示する。操作環境１００は、スキャンサーバ１０２を備えることができる。スキャンサーバ１０２は、例えばネットワークまたは他のサーバ、デスクトップコンピュータ等のようなコンピュータデバイスを含むことが可能である。一般に、スキャンサーバ１０２は、１以上の所定のネットワークのスキャンすること、ネットワーク上にマシンを配置すること、それらのセキュリティ状態を決定すること、いずれのサービスにマシンがネットワーク上でさらされるか等に関与する。スキャンサーバ１０２は、例えば法人の、大学の、または他の適当な環境を含む所定の企業におけるネットワークをサービスするために展開されることが可能である。
【００１１】
スキャンサーバ１０２は、１以上のプロセッサ１０４とコンピュータ可読媒体を具備することができる。コンピュータ可読媒体は、プロセッサ１０４により実行されるとき、ここに記載される方法のいずれかを実行する指示を具備することができる。プロセッサ１０４は、コンピュータ可読媒体１０６にアクセスし、および／またはコンピュータ可読媒体１０６を実行するように構成されることが可能である。コンピュータ可読媒体１０６は、ネットワーク対応エンティティと相互通信できるモジュール、プログラム、または他エンティティとして実施される可能性のあるノード発見コンポーネント１０８を備えるか、またはアクセスすることが可能である。ノード発見コンポーネント１０８は、ここに記載されるように、１セットのネットワークノードとそのノードのためのルーティング可能なアドレスを発見し、同じ内容をスキャンサーバ１０２に提供するように構成されることが可能である。ノード発見コンポーネント１０８およびスキャンサーバ１０２は、力ずくのノード発見技術が実行不可能であるほど十分に大きなアドレス空間をサポートするネットワークプロトコルの状況において特定の適用性を発見する可能性がある。このようなネットワークプロトコルの１つの非限定的な例は、上述のＩＰｖ６プロトコルである。
【００１２】
スキャンサーバ１０２は、これらのローカルリンクセグメント１１０のそれぞれに対応するルータ１１２を介して、１以上のローカルリンクセグメント１１０にアクセスすることができる。便宜のためだけに、図１は２つのローカルリンクセグメント１１０ａと１１０ｂを示す。しかし、操作環境１００の可能な実装は、多くのローカルリンクセグメント１１０を含みうることが理解される。ローカルリンクセグメント１１０は、例えば所定のネットワークケーブルのような所定の一般のコネクタに接続される１以上のコンピュータを含みうることが理解される。従って、所定のローカルリンクセグメント１１０内の全てのコンピュータは、ルータ１１２を通過することなく、お互いと通信することが可能である。
【００１３】
便宜のためだけに、図１は２台のルータ１１２ａと１１２ｂを示す。しかし、操作環境１００の可能な実装は、多くのルータ１１２を含みうることが理解される。一般的に、所定のネットワークのルータ１１２の数は、ローカルリンクセグメント１１０の数と対応する。「ルータ」の用語は、限定のためではなく便宜のためだけに、ここで使用されることにも注意される。例えば、ルータ１１２は、スイッチまたは他の構成要素の形態とすることができる。より一般的には、ルータ１１２は、その間のコミュニケーションを可能にするために、ローカルリンクセグメント１１０とスキャンサーバ１０２とを接続する。
【００１４】
ローカルリンクセグメント１１０は、少なくとも１つのエージェント１１４を具備する。便宜のためだけに、図１はそれぞれローカルリンクセグメント１１０ａと１１０ｂとに関連する、２つのエージェント１１４ａと１１４ｂとを示す。しかし、２以上のエージェント１１４が所定のローカルリンクセグメント１１０に含まれうることが理解される。通常、エージェント１１４は、スキャンサーバ１０２および／またはノード発見コンポーネント１０８からの命令に応答し、エージェント１１４は、この応答を同じ場所に提供する。１つの可能性のあるシナリオのみとして、エージェント１１４は、ここに記載される機能を実行するソフトウェアとして実装されることが可能であり、いずれかの適当なハードウェア構成と接続して実行することが可能である。スキャンサーバ１０２は、例えばＤＮＳネームおよび／または最後の既知のＩＰアドレス等により全て構成されたエージェント１１４に気付く可能性がある。１つの可能性のある実施形態のみとして、構成されたエージェント１１４に関する情報は、スキャンサーバ１０２にアクセス可能なデータストアに格納されることが可能である。しかし、ここに記載されるようにスキャンサーバ１０２がノード発見を実行するまで、スキャンサーバ１０２は、エージェント１１４を除いて、ローカルリンクセグメント１１０内の他のノードに気付かない可能性がある。このように、ローカルリンクセグメント１１０が多くのマシンをそれに付けられる間、スキャンサーバ１０２のノード発見コンポーネント１０８は、ノード発見を実行するまでそのようなマシンの数に気付かない。
【００１５】
スキャンサーバ１０２は、スキャンサーバ１０２が責任を有する所定のネットワークの少なくとも１部内にネットワークノードを発見するために、ノード発見コンポーネント１０８を使用することが可能である。スキャンサーバ１０２がネットワーク全体の中で全てのノードを発見することを望むならば、ノード発見コンポーネント１０８は、ネットワーク全体の中で全てのエージェント１１４と通信する可能性がある。スキャンサーバ１０２がネットワーク全体のサブネット内でそれらのノードのみを発見することを望むならば、ノード発見コンポーネント１０８は、スキャンサーバ１０２に関連するサブネット内でそれらのエージェント１１４のみと通信することが可能である。
【００１６】
ある実装形態において、図１に示すように、スキャンサーバ１０２は、ローカルリンクセグメント１１０ｃと接続することが可能である。このような実装形態において、このローカルリンクセグメント１１０ｃは、エージェント１１４と接続しないことが可能であり、エージェント１１４により実行されるものとしてここで記載される全ての機能は、代わりにスキャンサーバ１０２で実行されることが可能である。
【００１７】
図１において、全体的な操作環境１００が上記され、議論はここで所定のローカルリンクセグメント１１０で操作環境に変わり、ここで図２を参照して記載される。
【００１８】
図２は、所定のローカルリンクセグメント１１０に関連する操作環境２００を例示する。操作環境２００は、スキャンサーバ１０２に関連するサブネット内にあるローカルリンクセグメント１１０を表す。図２に示されるローカルリンクセグメント１１０は、図１に示されるローカルリンクセグメント１１０ａ、または１１０ｂのいずれかであることがわかる。同様に、代表的なノード発見コンポーネント１０８とエージェント１１４は、便宜のために図１から繰り返される。ノード発見コンポーネント１０８とエージェント１１４との間で渡す命令及び応答が１以上のルータ１１２または類似する構成要素を介して通過しうることが理解されるが、ルータ１１２は図２から省略される。
【００１９】
１以上のノード２０２は、エージェント１１４に加えて、ローカルリンクセグメント１１０と接続する。便宜ためだけに、図２は４つのノード２０２ａ、２０２ｂ、２０２ｃ、および２０２ｄを示す。ＩＰｖ６の状況において、「ノード」は所定のコンピュータがネットワークにアクセスする可能性があるネットワークカードであると考えられる。このように、図２はコンピュータ２０４のコンセントにプラグインされる２枚の異なるネットワークカードでありうる２つのノード２０２ｃと２０２ｄを含むコンピュータ２０４を示す。ある実装形態において、ノード２０２はそれぞれの一意的なＩＰアドレスと関連する可能性がある。他の実施形態において、ノード２０２は単一のＩＰアドレスとして結びつく可能性がある。
【００２０】
スキャンサーバ１０２がローカルリンクセグメント１１０上のノード発見の実行を望むとき、ノード発見コンポーネント１０８はローカルリンクセグメント１１０でアドレス収穫命令２０６をエージェント１１４に発行することが可能である。「アドレス収穫（Address Harvest」の用語は、限定ではなく、参照の便宜のためだけにここで選択される。ここに記載され、それに類似する機能と関連する他の命令が「アドレス収穫」以外のラベルにより示される可能性があることが理解される。
【００２１】
アドレス収穫命令２０６は、便宜のためだけにアドレス収穫命令２０６ａとして示されるように、ノード発見コンポーネント１０８からローカルリンクセグメント１１０まで渡される。次いで、エージェント１１４は、便宜のためだけに２０６ｂとして示されるように、ローカルリンクセグメント１１０からアドレス収穫命令にアクセスすることができる。
【００２２】
アドレス収穫命令２０６を受信した後、エージェント１１４はローカルリンクセグメント１１０上の全てのノード２０２に、近隣要請メッセージ２０８を送信する。近隣要請メッセージ２０８の適当な例は、ＩＣＭＰｖ６タイプ１３５、コード０の下で定義され、「全てのノード」（ｆｆ０２：：ｌ）のためにリンクローカルマルチキャストアドレスに送信される可能性のあるメッセージである。リンクローカルセグメント１１０上のノード２０２は、近隣通知メッセージ２１０で応答する。便宜のためだけに、図２はノード２０２ａ、２０２ｂ、２０２ｃ、および２０２ｄと対応するそれぞれのメッセージ２１０ａ、２１０ｂ、２１０ｃ、２１０ｄを示す。近隣通知メッセージ２１０の適当な例は、ＩＣＭＰｖ６タイプ１３６、コード０の下で定義されるメッセージである。ノード２０２がＲＦＣ２４６１（ｑ．ｖ．）を準拠していると仮定して、ノード２０２はメッセージ２０８にメッセージ２１０で応答する。
【００２３】
メッセージ２０８が送信された後、エージェント１１４は時間の妥当なウインドウ内で受信される全ての応答２１０のリストを維持する。適用可能な時間ウインドウは、デフォルトとして特定される可能性があるか、またはウインドウは、雑音があるかまたは長い待ち時間のネットワークを補償するために、微調整されるか、または調節される可能性がある。エージェント１１４がローカルリンクセグメント１１０上でこれらの応答２１０にアクセスしうることが理解されるが、図の明確さのために、応答２１０はローカルリンクセグメント１１０のみに渡して示される。
【００２４】
様々なノード２０２からのメッセージ２１０は、それぞれのアドレス２１２をノード２０２に提供し、エージェント１１４により収集される。しかし、これらのアドレス２１２は、ＩＰｖ６の状況においてその用語が理解されるように、リンクローカルアドレスである。ＩＰｖ６において、リンクローカルアドレスは、「％２」（スコープＩＤ２）で終了する。リンクローカルアドレス２１２は、ノード２０２上でネットワークカードに位置づける１種の物理アドレスとして見られる可能性がある。便宜のためだけに、ノード２０２の全てのためのリンクローカルアドレスは、図２の矢印２１２により集合して表現される。
【００２５】
リンクローカルアドレス２１２は、ローカルリンクセグメント１１０上だけで、有効性または意味を有する。リンクローカルアドレス２１２は、所定のローカルリンクセグメント１１０のためにルータ１１２上に有効性または意味を有さない。このように、リンクローカルアドレス２１２は、これらの現在のフォームでスキャンサーバ１０２にとってすぐに有用でない可能性がある。このように、一旦それがリンクローカルアドレス２１２を収穫し終わるならば、リンクローカルアドレス２１２を変換する要求により、エージェント１１４はそれらをバルクリゾルバ２１４に提供する。バルクリゾルバ２１４は、議論と説明の便宜のためだけに、エージェント１１４と別のものとして示される。ある実装形態において、エージェント１１４とバルクリゾルバ２１４は、互いに統合される可能性がある。
【００２６】
バルクリゾルバ２１４は、リンクローカルアドレス２１２を対応するサイトローカルアドレス２１８に変換する。リンクローカルアドレス２１２と異なり、サイトローカルアドレス２１８は、所定のローカルリンクセグメント１１０のために、ルータ１１２上に有効性または意味を有する。このように、サイトローカルアドレス２１８は、「ルーティング可能（routable）」と言われている。しかし、サイトローカルアドレス２１８は、スキャンサーバ１０２により管理される企業内のみにおいて有効性または意味を有する可能性があることが注意される。このように、例えば、サイトローカルアドレス２１８は、インターネット上の有効なアドレスでない可能性がある。
【００２７】
バルクリゾルバ２１４は、それぞれのノード２０２のためにＩＰアドレスの形式でサイトローカルアドレス２１８のリストを獲得するために、アドレスリゾリューションを実行する。この変換を実行するための適当なネームリゾリューションＡＰＩの例は、世界的なインターネットワーキング標準に準拠するためにソフトウェア開発者により実装されうるＩＥＴＦＡＰＩであるgetaddrinfo ＡＰＩである。例えば、getaddrinfo ＡＰＩは、ヒントとしてＡＩ＿ＮＵＭＥＲＩＣＨＯＳＴを使用して呼び出される可能性がある。いずれにしても、getaddrinfo ＡＰＩは、それぞれのノード２０２のために、そのノード２０２と関連する全てのアドレスを返信する。
【００２８】
リゾルブされたアドレスは、スキャンサーバ１０２が使用する可能性のあるサイトローカルＩＰｖ６アドレス２１８（スコープＩＤ５）のリストを生成するためにフィルタされる可能性がある。ＩＰｖ６において、サイトローカルアドレスは、「％５」で終了する。エージェント１１４は、ローカルリンクセグメント１１０上にスキャンサーバ１０２のノード発見コンポーネント１０８にアクセス可能であるサイトローカルアドレス２１８を設置する。
【００２９】
一旦それがサイトローカルアドレス２１８を所定のローカルリンクセグメント１１０で受信するならば、スキャンサーバ１０２は次いで所定のローカルリンクセグメント１１０上でノード２０２と通信する可能性がある。次いで、スキャンサーバ１０２は、ノード２０２を管理することに向けられる多くの活動を実行する可能性がある。例題としてのみ、スキャンサーバ１０２は、様々なノード２０２上のポートスキャンまたは保安関連機能を実行する可能性がある。他の例として、スキャンサーバ１０２は、ネットワークマップが生成される可能性のあるデータをコンパイルする可能性がある。特に、レドモンド、ワシントンのマイクロソフトから入手可能なドラフトソフトウェアＶＩＳＩＯのようないくつかのアプリケーションは、ユーザに「Ｍｙネットワーク地図」または類似した機能を提供する可能性がある。ユーザがこの機能を選択する場合、アプリケーションはユーザのネットワークの図を描くことが可能である。
【００３０】
図１および図２を記載して、いくつかの観察が注意される。操作環境１００および２００は、例えばＩＰｖ６ネットワークのような比較的大きなアドレス空間をサポートするネットワークの状況において、ノード発見を可能にする。アドレス空間全体を通しての力ずくの検索に代わりに、操作環境１００および２００は、ローカルリンクセグメント１１０上においてノード２０２を発見するために、ローカルエージェント１１４を使用する。実質的に実現可能なある実施形態において、エージェント１１４の数は、例えば６４ビットアドレス空間における可能なアドレスの数よりはるかに少ない。
【００３１】
［プロセスフロー］
図３は、所定の企業内でルーティング可能なアドレスのリストを獲得するために、プロセスフロー３００を例示する。便宜と議論の容易さのために、プロセスフロー３００は、操作環境１００および２００の他の態様と同様に、スキャンサーバ１０２および／またはノード発見コンポーネント１０８と接続してここに記載される。しかし、プロセスフロー３００は、ここに記載される明細書の精神および範囲から逸脱することなく操作環境１００および２００で示される、スキャンサーバ１０２、ノード発見コンポーネント１０８、または他の構成要素以外のデバイスまたは構成要素上で実施される可能性があることが理解される。
【００３２】
次に、更に詳細にプロセスフロー３００に見てみると、ブロック３０２は、所定のローカルリンクセグメントのために、アドレス収穫命令を送信する。アドレス収穫命令の例は、図２に示されるアドレス収穫命令２０２である。ブロック３０２は、スキャンサーバ１０２により実行される可能性がある。アドレス収穫命令は、所定のローカルリンクセグメント１１０と関連する選択されたエージェント１１４に向けられる可能性がある。
【００３３】
ブロック３０４は、ルーティング可能なアドレスを所定のローカルリンクセグメントに接続する１以上のノードで受信する。これらのノードの例は、図２に示されるノード２０２を含み、ローカルリンクセグメントの例は、図１に示されるローカルリンクセグメント１１０である。ブロック３０４は、スキャンサーバ１０２により実行される可能性がある。
【００３４】
ブロック３０６は、さらにローカルリンクセグメント１１０が関心であるかどうか調べる。例えば、スキャンサーバ１０２は、ネットワーク全体、またはそのいずれかの部分のルーティング可能なアドレスを獲得することが可能である。関心のさらなるローカルリンクセグメント１１０が存在するならば、プロセスフロー３００はＹｅｓ枝３０８によりブロック３１０へ進む。
【００３５】
３１０ブロックは、別のローカルリンクセグメント１１０を選択する。その後、プロセスフロー３００は、この次のローカルリンクセグメント１１０のためにブロック３０２−３０６を繰り返すためにブロック３０２に戻る。
【００３６】
ブロック３０６から、例えばスキャンサーバ１０２への関心のさらなるローカルリンクセグメント１１０が存在しないならば、プロセスフロー３００はＮｏ枝３１２によりブロック３１４へ進む。ブロック３１４は、プロセスフロー３００の所定の繰り返しにおいて処理されるローカルリンクセグメント１１０の全てから発見される全てのネットワークノード２０２のために、ルーティング可能なアドレスのリストを収集する。ネットワークノード２０２と対応するルーティング可能なアドレスのこのリストがあれば、スキャンサーバ１０２または別のコンポーネントは、例えばルータ１１２を介して発見されるノード２０２の全てと直接通信する可能性がある。
【００３７】
図４は、所定のローカルリンクセグメント内の１以上のノードのためにルーティング可能なアドレスのリストを生成するために、プロセスフロー４００を例示する。便宜と議論の容易さのために、プロセスフロー４００は、操作環境１００と２００の他の態様と同様に、エージェント１１４および／またはノード発見コンポーネント１０８と接続してここで記載される。しかし、プロセスフロー４００は、ここに記載される明細書の精神および範囲から逸脱することなく操作環境１００と２００で示される、エージェント１１４、ノード発見コンポーネント１０８、または他の構成要素以外のデバイスまたは構成要素上で実施される可能性があることが理解される。
【００３８】
次に更に詳細にプロセスフロー４００を見てみると、ブロック４０２は、例えばノード発見コンポーネント１０８および／またはスキャンサーバ１０２によりアドレス収穫命令２０２のようなアドレス収穫命令を受信する。ブロック４０２は、選択されたローカルリンクセグメント１１０でエージェント１１４により実行される可能性がある。
【００３９】
ブロック４０４は、図２に示される近隣要請メッセージ２０８のようなメッセージを送信する。ブロック４０４は、選択されたローカルリンクセグメント１１０においてエージェント１１４により実行される可能性があり、例えば図２に示されるノード２０２のような１以上のネットワークノードにより受信されるように近隣要請メッセージは送信される可能性がある。
【００４０】
ブロック４０６は、図２に示される近隣通知メッセージ２１０のようなメッセージを受信する。ブロック４０６は、選択されたローカルリンクセグメント１１０においてエージェント１１４により実行される可能性があり、それぞれの近隣通知メッセージは、例えば図２に示されるノード２０２のような１以上のネットワークノードから受信される可能性がある。また、ブロック４０６は、近隣通知メッセージと対応するリンクローカルアドレスも受信する。リンクローカルアドレスの例は、図２に示されるアドレス２１２を含む。
【００４１】
ブロック４０８は、ブロック４０６で受信されたリンクローカルアドレスが、サイトローカルアドレスで位置付けするか、または変換されることを要求する。例えば、エージェント１１４は、ブロック４０８に示される要求を提出する可能性がある。この要求は、例えば上述したＤＮＳＡＰＩ、またはgetaddrinfo ＡＰＩにより完了される可能性がある。いずれにしても、この要求を提供するエンティティは、エージェント１１４の一部であるか、または切り離す可能性がある。
【００４２】
ブロック４１０は、所定のローカルリンクセグメント１１０内で発見される全ての発見されるノード（例えばノード２０２）のために、サイトローカルアドレスのセットを受信して、送信する。ブロック４１０は、ブロック４０２で受信されるアドレス収穫コマンドにより要求されるデータを提供する。ブロック４１０により送信されるサイトローカルアドレスの例は、図４に示されるサイトローカルアドレス２１８である。ブロック４１０により送信されるサイトローカルアドレス２１８は、ルーティング可能であり、例えばノード発見コンポーネント１０８および／またはスキャンサーバ１０２により受信される可能性がある。
【００４３】
［結論］
システム及び方法が構造的な特徴および／または方法論的な行為を特定する言語により記載されたが、添付のクレームにおいて定義されるシステムおよび方法が記載される特定の特徴または行為に必ずしも限定される必要がないことを理解すべきである。むしろ、特定の特徴と行為は、クレームで要求されたシステムおよび方法を実装することの例示的な形態として開示される。
【００４４】
さらに、ここに記載され、かつ例示される特定のフローチャートに関して、ここで示されるプロセスと下位プロセスがこの明細書の精神および範囲から逸脱することなく例示される順序以外の順序で実行されることが可能であることが注意される。
【図面の簡単な説明】
【００４５】
【図１】ネットワークノードとルーティング可能なアドレスを発見するための操作環境のブロック図である。
【図２】所定のローカルリンクセグメントに関連する操作環境のブロック図である。
【図３】所定の企業内のルーティング可能なアドレスのリストを獲得する処理のフローチャートである。
【図４】所定のローカルリンクセグメント内の１以上のノードのためにルーティング可能なアドレスのリストを生成する処理のフローチャートである。
【図１】
2009524347.tif 000003
【図２】
2009524347.tif 000004
【図３】
2009524347.tif 000005
【図４】
2009524347.tif 000006
【国際調査報告】
2009524347.tif 000007
2009524347.tif 000008