JP2007201564A - 推定システム、端末、推定方法、およびプログラム - Google Patents

推定システム、端末、推定方法、およびプログラム Download PDF

Info

Publication number
JP2007201564A
JP2007201564A JP2006014472A JP2006014472A JP2007201564A JP 2007201564 A JP2007201564 A JP 2007201564A JP 2006014472 A JP2006014472 A JP 2006014472A JP 2006014472 A JP2006014472 A JP 2006014472A JP 2007201564 A JP2007201564 A JP 2007201564A
Authority
JP
Japan
Prior art keywords
estimation
packet
information
network
address
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.)
Pending
Application number
JP2006014472A
Other languages
English (en)
Inventor
Hideaki Yoshimi
英朗 吉見
Atsushi Enomoto
敦之 榎本
Zhenlong Cui
珍龍 崔
Kazuo Takagi
和男 高木
Atsushi Iwata
淳 岩田
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
NEC Corp
Original Assignee
NEC Corp
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 NEC Corp filed Critical NEC Corp
Priority to JP2006014472A priority Critical patent/JP2007201564A/ja
Priority to US11/625,687 priority patent/US20070171836A1/en
Publication of JP2007201564A publication Critical patent/JP2007201564A/ja
Pending legal-status Critical Current

Links

Images

Classifications

    • 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/25—Mapping addresses of the same type
    • H04L61/2503—Translation of Internet protocol [IP] addresses
    • H04L61/256—NAT traversal
    • H04L61/2575—NAT traversal using address mapping retrieval, e.g. simple traversal of user datagram protocol through session traversal utilities for NAT [STUN]
    • 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/25—Mapping addresses of the same type
    • H04L61/2503—Translation of Internet protocol [IP] addresses
    • H04L61/256—NAT traversal

Landscapes

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

Abstract

【課題】ネットワーク上でのヘッダ変換を推定するための専用サーバを設置することなく、推定に必要な情報を収集してネットワーク上でのヘッダ変換を推定できる技術を提供することにある。
【解決手段】ネットワーク上の装置に関する情報を推定するシステムであって、送信したパケットに応答して送られてくる通信用のプロトコルで定められているエラーメッセージ又は制御メッセージを用いてネットワーク上の装置に関する情報を推定するシステム。
【選択図】図５

Description

本発明は、ＩＣＭＰメッセージを利用したネットワークの環境を推定する技術に関し、特に、ネットワークに接続されている通信装置に関する情報を推定するための技術に関する。
ローカルエリアネットワーク（ＬＡＮ）やインターネットといった情報通信ネットワークは、様々な通信装置を組み合わせることにより構成されている。
まず、ネットワークの構成例として、図１のようなネットワークを考える。
図１には、インターネットのようなネットワーク４と、アドレス変換を行うＮＡＴルータ２、ＮＡＴルータ６と、ユーザが操作するＰＣ１、ＰＣ７と、インターネット上に設置されている任意のＰＣ５と、パケットの経路を行うルータ３が含まれる。また、ネットワーク４は、パケットの経路制御を行うルータ８〜１１を含んでいる。
以下において、図１の構成要素の機能について述べる。
まず、ＮＡＴルータ２の機能について説明する（以下の説明は、ＮＡＴルータ６にも当てはまる）。
ＮＡＴルータ２の主な機能としては、アドレス変換（NAT：Network Address Translation）機能が挙げられる。ＬＡＮのＰＣ１には、プライベートＩＰアドレスが割り当てられているのが一般的であるが、ＬＡＮのＰＣ１をネットワーク４と接続するには、グローバルＩＰアドレスを割り当てる必要がある。この問題を解決するために、ＮＡＴルータ２では、ＰＣ１がネットワーク４と接続できるように、プライベートＩＰアドレスとグローバルＩＰアドレスのアドレス変換を行う。具体的な処理としては、ＬＡＮのＰＣ１から送信されたパケットの送信元ＩＰアドレスをグローバルＩＰアドレスに書き換えた後、ルータ３に転送する。図２には、参考のため、ＩＰヘッダとＵＤＰヘッダのフォーマットを示している。
また、ＮＡＴルータ２は、上記のようにＰＣ１から送信されたパケットの送信元ＩＰアドレスの変換だけでなく、送信元ポート番号までも変換するＮＡＰＴ（ＮＡＰＴ：Ｎｅｔｗｏｒｋ Ａｄｄｒｅｓｓ Ｐｏｒｔ Ｔｒａｎｓｌａｔｉｏｎ）機能を搭載していることもある。NAPTはNATと同様の技術であるが、NATではIPアドレスしか変換しないのに対して、NAPTではさらにTCPやUDPのポート番号も変換するという特徴がある。これにより、1つのグローバルIPアドレスで、プライベートIPアドレスを持つ複数のＰＣを収容することができる。例えば、ダイヤルアップ接続では、インターネットサービスプロバイダ（ISP）から割り当てられるグローバルIPアドレスは1つしかないが、NAPTを使えば、LAN上の複数のＰＣが同時にネットワーク４へ接続できるようになる。
次に、ルータ３の機能について説明する（以下の説明は、ルータ８〜１１にも当てはまる）。
ルータ３の主な機能として、パケットの経路制御機能が挙げられるが、この機能に加えて、ルータ３には優先制御機能も搭載されている。優先制御機能とは、トラフィックの集中によりネットワーク内でパケット破棄が発生することが明白な場合には、重要なパケットを優先的に処理し、パケットが破棄されないようにする技術である。例えば、図１ではトラフィックの集中によりネットワーク４内でパケットが破棄される可能性がある。パケットが破棄されると、重要な通信サービスまでも応答が遅くなってしまったり、サービスが異常終了してしまったりするという現象が発生してしまう。優先制御機能は、これらの問題を解決し、重要なサービスの安定稼動を実現するために利用されるものである。
優先制御の実現方法としては、図１にその例を示しているが、ルータ３において、ネットワークの輻輳状態を監視するとともに、流入してくるパケットのToS値を書き換える。ここで、ToS値にはパケットの優先度など、パケットの品質を決める情報が書き込まれる。ネットワーク４内のルータでは，このToS値に従ったパケットの優先制御を行うことにより、特定のフローにのみ高品質の通信サービスが提供される。
また、ルータには、この優先制御機能に加えて、パケットのフラグメント機能も搭載されている。IPパケットを送信するＰＣ１は、接続しているネットワーク４の最大転送単位（MTU: Maximum Transfer Unit）を最大サイズとするパケットを送信することが理想的である。このような理想的な環境下では、ＰＣ１から送信されたIPパケットは生成されたサイズそのままで宛先ホストに到達することになるが、図１のルータ８とルータ９の間のように、通信経路上に小さなMTUを持つネットワークが存在する場合、IPパケットはその境界のルータで細分化して送られる。これがルータのフラグメント機能である。フラグメントを行ったルータ８は、パケットのフラグフィールドの第３ビットを１に設定するとともに、最終パケットのフラグフィールドに０を設定する。また、フラグメントオフセットフィールドにはデータのオフセット値を設定する。
フラグメント化されたIPパケットを元の形に戻すのは、最終的な宛先ホストの役割である。宛先ホストでは、フラグフィールドとフラグメントオフセットフィールドの情報を基にして、フラグメント化されたIPパケットを再構成する。
以上のように、NATルータやルータはパケットヘッダに様々な変換処理を施すが、このような変換処理が発生したという事象は送信元ＰＣ１には隠蔽されている。このため、送信元ＰＣ１では、ネットワークがどのように構成されており、どんな制御機能が働いているのかを把握することは出来ない。このようにネットワークがブラックボックス化され、ヘッダ変換を送信元ＰＣ側で検出できなくなると、様々な問題が出てくる。以下において、これらの問題点について述べる。
まず、ＮＡＴルータ２で実行されたヘッダ変換の内容をＰＣ１が検出できない場合の問題について述べる。
NATルータ２の内側にあるＰＣ１と、NATルータ６の内側にあるＰＣ７との間でパケットをやり取りするには、双方に設置されたＮＡＴルータのグローバルＩＰアドレスとポート番号を宛先としたパケットを送信する必要がある。つまり、あらかじめ通信相手のＮＡＴルータの情報を取得しておく必要があり、例えば、ＰＣ７からＰＣ１にパケットを送信するには、ＮＡＴルータ２の情報が必要になる。ＮＡＴルータ２の情報を取得する方法として、ＮＡＴルータ２に繋がれているＰＣ１から教えてもらうという方法が考えられるが、上述したように、ＮＡＴルータ２のアドレス変換内容はＰＣ１に隠蔽されているので、この方法は破綻してしまう。
以上のことから、NATルータのアドレス変換処理を検出できなければ、NATルータに繋がれたＰＣ間でパケットをやり取りすることは出来ない。
次に、ルータで行われたToS値の変換処理をＰＣ側で検出できない場合の問題について述べる。
ネットワークでToS値による優先制御機能が働いていなければ、ＩＰ電話やＩＰテレビなど高度な優先制御機能が必要されるリアルタイム型アプリケーションを利用することは難しい。この優先制御が働いているかどうかを判別する方法として、ToS値の変化を検出することは効果的であるが、上述のようにToS値の変換処理はＰＣ側には隠蔽されているので、この方法は破綻してしまう。
以上のことから、ルータのToS値の変換処理を検出できなければ、アプリケーションを利用できるかどうか事前に認識することは出来ない。
次に、ルータで行われたフラグメント処理を、ＰＣ側で検出できない場合の問題について述べる。
パケットのフラグメントが発生しても通信自体に支障はないが、転送効率が落とされてしまう。例えば、図１のように、ネットワーク４のルータ８とルータ９の間のＭＴＵが1000バイトである環境において、ＰＣ１から1500バイトのパケットが送信された場合、ルータ８において、1500バイトのデータは1000バイトと残りの500バイトの２つのデータにフラグメントされる。このようにフラグメントされると、ルータ８でフラグメント処理が発生するだけでなく、ルータ９では１つでなく２つのパケットを処理する必要となる。この結果、各ルータの負荷が増えるだけでなく、２つに分割されたパケットのうち、どちらかが壊れると、両方のパケットを廃棄しなければならなくなるため、ネットワーク４の負荷も増えてしまう。このようなフラグメントの発生を防ぐ方法として、ＰＣ１においてフラグメントが起こらないパケットサイズを調べ、そのサイズに合わせたパケットを送信するということが考えられるが、上述したように、フラグメントの発生はＰＣ１に隠蔽されているので、この方法は破綻してしまう。
以上のことから、ルータのフラグメント処理を検出できなければ、パケットの転送効率の低下を防ぐことが出来ない。
以上述べたように、通信経路上で行われたヘッダ変換を送信元ＰＣで検出できないと、様々な問題が生じてしまう。
この課題を解決する方法の一例が、非特許文献１や特許文献１に記載されている。
非特許文献１に記載の方法は、図３に示すように、ネットワーク３０４のようなインターネット上に専用サーバ３１２を設置する。図３のＰＣ３０１は、この専用サーバ３１２にパケットを送信する。専用サーバ３１２では、このＰＣ３０１から受信したパケットのヘッダ情報を拾い上げ、ＰＣ３０１に折り返し通知してやる。ここで、専用サーバ３１２からＰＣ３０１に折り返し通知する情報としては、ＩＰアドレスやポート番号、そしてＴｏＳ値やフラグフィールドなどが挙げられる。
一方、ＰＣ３０１では、上記のように折り返し通知されたヘッダ情報から、通信経路上でヘッダ変換が行われたか否かを検出するとともに、そのヘッダ変換の内容を把握することができる。さらに、このヘッダ変換の情報を利用することにより、上述の各課題に対して対処することができる。
例えば、ＮＡＴルータのアドレス変換処理について言えば、非特許文献１の方法により、ＰＣ３０１は、専用サーバ３１２からＮＡＴルータ３０２のＩＰアドレスとポート番号を通知してもらった後、このＮＡＴルータ３０２の情報をＰＣ３０７に通知してやれば、ＰＣ３０７からＰＣ３０１にパケットを送信することができる。
また、ルータのToS値の変換処理について言えば、非特許文献１の方法により、ＰＣ３０１は、専用サーバ３１２からパケットのToS値を通知してもらえば、ネットワーク内で優先制御機能が働いているかどうか認識できる。
また、ルータのフラグメント処理について言えば、非特許文献１の方法により、ＰＣ３０１は、専用サーバ３１２からパケットのフラグメントフィールドを通知してもらえば、フラグメントが起こらないようなパケットサイズを検出することができ、パケットの転送効率を最大化できる。
Ｊ・ローゼンバーグ（J. Rosenberg）、他３名、"ＲＦＣ３４８９：ＳＴＵＮ技術" [online]、[平成１６年９月１日検索]、インターネット http://www.faqs.org/rfcs/rfc3489.html 特開２００５−１０２１９６
以下において、非特許文献１に記載の方法の問題点を述べる。
非特許文献１に記載の方法は、専用サーバ３１２をインターネット上に設置しなければならないため、専用サーバ３１２の保守/運用作業が必要であり、手間がかかる。
また、専用サーバ３１２へのインターネット上の悪意のある第３者からの攻撃を防ぐために、専用サーバ３１２のセキュリティレベルを維持する作業が必要であり、手間がかかる。
さらに、専用サーバ３１２の処理負荷の急増を防ぐために、専用サーバ３１２の負荷分散作業が必要であり、手間がかかる。
本特許は、これら全ての問題を解決するためになされたものであり、その目的とするところは、専用サーバ３１２を設置することなく、通信経路上でのヘッダ変換を推定できる方法を提供することにある。
上記課題を解決するための第１の発明は、
ネットワーク上の装置に関する情報を推定する推定システムであって、
送信されて来た情報収集用のパケットに応答して制御用のメッセージを返信する返信手段と、
前記返信手段からの制御用のメッセージに基づいて、前記ネットワーク上の装置に関する情報を推定する推定手段と
を備えたことを特徴とする。
上記課題を解決するための第２の発明は、上記第１の発明において、
前記返信手段は、待ち受け状態となっていないポート番号を宛先とした情報収集用のパケットに応答して、到達不能を示す制御用のメッセージを返信する手段であることを特徴とする。
上記課題を解決するための第３の発明は、上記第１又は第２の発明において、
前記返信手段は、前記情報収集用のパケットをヘッダのデータ部に格納した制御用のメッセージを返信する手段であることを特徴とする。
上記課題を解決するための第４の発明は、上記第１から第３のいずれかの発明において、
前記返信手段は、前記情報収集用のパケットが通過できる装置の個数を示す情報が０である情報収集用のパケットに応答して、前記情報収集用のパケットを破棄したことを示す制御用のメッセージを返信する手段であることを特徴とする。
上記課題を解決するための第５の発明は、上記第１から第４のいずれかの発明において、
前記推定手段は、品質を示す情報に基づいて推定する手段であることを特徴とする。
上記課題を解決するための第６の発明は、上記第１から第４のいずれかの発明において、
前記推定手段は、前記情報収集用のパケットが分割されたことを示す情報に基づいて推定する手段であることを特徴とする。
上記課題を解決するための第７の発明は、上記第１から第４のいずれかの発明において、
前記推定手段は、チェックサム値に基づいて推定する手段であることを特徴とする。
上記課題を解決するための第８の発明は、上記第７の発明において、
前記推定手段は、ＩＰチェックサム値に基づいて、前記制御用のメッセージのデータ部の送信元ＩＰアドレスを変更した装置に関する情報を推定し、ＵＤＰチェックサム値またはＴＣＰチェックサム値に基づいて前記制御用のメッセージのデータ部の送信元ポート番号を変更した装置に関する情報を推定する手段であることを特徴とする。
上記課題を解決するための第９の発明は、上記第８の発明において、
前記推定手段は、ＵＤＰチェックサム値またはＴＣＰチェックサム値に基づいて、前記制御用のメッセージのデータ部の送信元ＩＰアドレスを変更した装置に関する情報を推定する手段であることを特徴とする。
上記課題を快活するための第１０の発明は、上記第７から第８のいずれかの発明において、
前記推定手段は、ネットワークの経路調査試験の結果を加味して、推定する手段であることを特徴とする。
上記課題を解決するための第１１の発明は、上記第１０の発明において、
前記経路調査試験は、通過できる装置の個数を示す情報の数値が互いに異なる複数の情報収集用のパケットを送信することによって行われる調査試験であることを特徴とする。
上記課題を解決するための第１１の発明は、上記第１０又は第１１の発明において、
前記経路調査試験は、以前推定された端末までに通過する装置の個数を調査する試験であることを特徴とする。
上記課題を解決するための第１３の発明は、上記第１０から第１２のいずれかの発明において、
前記経路調査試験は、プライベートIPアドレスとグローバルIPアドレスとが切り替わる位置に設置されている装置までに通過した装置の個数を調査する試験であることを特徴とする。
上記課題を解決するための第１４の発明は、上記第１から第１３のいずれかの発明において、
前記推定手段は、推定結果を前記ネットワーク上の端末に通知する手段であることを特徴とする。
上記課題を解決するための第１５の発明は、上記第１４の発明において、
前記推定手段は、前記ネットワーク上の他の端末から推定結果を受け取ると、その推定結果を記憶するように構成されていることを特徴とする。
上記課題を解決するための第１４又は第１５の発明において、
前記推定手段は、複数の推定結果に基づいて前記ネットワーク上のコンピュータのポート番号の割り当て処理の規則性を推定する手段であることを特徴とする。
上記課題を解決するための第１７の発明は、上記第１４から第１６のいずれかの発明において、
前記推定手段は、前記推定結果をメールまたは電話を用いて通信相手に通知するように構成されていることを特徴とする。
上記課題を解決するための第１８の発明は、上記第１から第１７のいずれかの発明において
前記推定手段は、前記情報収集用のパケットが通過できる装置の個数を示す情報を前記推定結果に基づいて取得した宛先に届かない値に設定して、この宛先にSYNパケットを送信し、このSYNパケットのシーケンス番号を前記宛先に通知する手段であることを特徴とする。
上記課題を解決するための第１９の発明は、上記第１８の発明において、
前記推定手段は、前記送信されたSYNパケットのシーケンス番号を受け取ると、このシーケンス番号を考慮した応答確認パケットを送信する手段であることを特徴とする。
上記課題を解決するための第２０の発明は、
ネットワーク上の装置に関する情報を推定するシステムであって、
通信用のプロトコルで定められているエラーメッセージ又は制御メッセージを用いて前記ネットワーク上の装置に関する情報を推定することを特徴とする。
上記課題を解決するための第２１の発明は、
端末であって、
情報収集用のパケットを送信する手段と、
前記情報収集用のパケットに応答して送信された制御用のメッセージに基づいて、ネットワーク上の装置に関する情報を推定する推定手段と
を有することを特徴とする。
上記課題を解決するための第２２の発明は、
ネットワーク上の装置に関する情報を推定する推定方法であって、
送信されて来た情報収集用のパケットに応答して制御用のメッセージを返信する返信ステップと、
受信したメッセージが前記情報収集用のパケットに応答して返信された制御用のメッセージであるかを判断する判断ステップと、
前記判断の結果、受信したメッセージが前記情報収集用のパケットに応答して返信された制御用のメッセージであると判断された場合、この制御用のメッセージに基づいて、前記ネットワーク上の装置に関する情報を推定する推定ステップと
を備えたことを特徴とする。
上記課題を解決するための第２３の発明は、上記第２２の発明において、
前記返信ステップは、待ち受け状態となっていないポート番号を宛先とした情報収集用のパケットに応答して、到達不能を示す制御用のメッセージを返信するステップであることを特徴とする。
上記課題を解決するための第２４の発明は、上記第２２又は第２３の発明において、
前記返信ステップは、前記情報収集用のパケットをヘッダのデータ部に格納した制御用のメッセージを返信するステップであることを特徴とする。
上記課題を解決するための第２５の発明は、上記第２２から第２４のいずれかの発明において、
前記返信ステップは、前記情報収集用のパケットが通過できる装置の個数を示す情報が０である情報収集用のパケットに応答して、前記情報収集用のパケットを破棄したことを示す制御用のメッセージを返信するステップであることを特徴とする。
上記課題を解決するための第２６の発明は、上記第２２から第２５のいずれかの発明において、
前記推定ステップは、品質を示す情報に基づいて推定するステップであることを特徴とする。
上記課題を解決するための第２７の発明は、上記第２２から第２５のいずれかの発明において、
前記推定ステップは、前記情報収集用のパケットが分割されたことを示す情報に基づいて推定するステップであることを特徴とする。
上記課題を解決するための第２８の発明は、上記第２２から第２５のいずれかの発明において、
前記推定ステップは、チェックサム値に基づいて推定するステップであることを特徴とする。
上記課題を解決するための第２９の発明は、上記第２８の発明において、
前記推定ステップは、
ＩＰチェックサム値に基づいて、前記制御用のメッセージのデータ部の送信元ＩＰアドレスを変更した装置に関する情報を推定するステップと、
ＵＤＰチェックサム値またはＴＣＰチェックサム値に基づいて前記制御用のメッセージのデータ部の送信元ポート番号、若しくはＩＰアドレスを変更した装置に関する情報を推定するステップと
を有することを特徴とする。
上記課題を解決するための第３０の発明は、上記第２８又は第２９の発明において、
前記推定ステップは、
ネットワークの経路調査試験を実行する経路調査実行ステップと、
前記実行結果を加味して装置に関する情報を推定する詳細情報推定ステップと
を有することを特徴とする。
上記課題を解決するための第３１の発明は、上記第３０の発明において、
前記経路調査実行ステップは、通過できる装置の個数を示す情報の数値が互いに異なる複数の情報収集用のパケットを送信するステップであることを特徴とする。
上記課題を解決するための第３２の発明は、上記第３０又は上記第３１の発明において、
前記経路調査実行ステップは、以前推定された装置までに通過する装置の個数を調査するステップであることを特徴とする。
上記課題を解決するための第３３の発明は、上記第３０から第３２のいずれかの発明において、
前記経路調査実行ステップは、プライベートIPアドレスとグローバルIPアドレスとが切り替わる位置に設置されている装置までに通過した装置の個数を調査するステップであることを特徴とする。
上記課題を解決するための第３４の発明は、上記第２２から第３３のいずれかの発明において、
前記推定ステップは、推定結果を前記ネットワーク上の端末に通知するステップを有することを特徴とする。
上記課題を解決するための第３５の発明は、上記第３４の発明において、
前記推定ステップは、前記ネットワーク上の他の端末から推定結果を受け取ると、その推定結果を記憶するステップを有することを特徴とする。
上記課題を解決するための第３６の発明は、上記第３４又は第３５の発明において、
前記推定ステップは、複数の推定結果に基づいて前記ネットワーク上のコンピュータのポート番号の割り当て処理の規則性を推定するステップであることを特徴とする。
上記課題を解決するための第３７の発明は、上記第３４から第３６のいずれかの発明において、
前記推定ステップは、前記推定結果をメールまたは電話を用いて通信相手である端末に通知する推定ステップを有することを特徴とする。
上記課題を解決するための第３８の発明は、上記第２２から第３７のいずれかの発明において、
前記推定ステップは、前記情報収集用のパケットが通過できる装置の個数を示す情報を、前記推定結果に基づいて取得した宛先に届かない値に設定して、この宛先にSYNパケットを送信し、このSYNパケットのシーケンス番号を前記宛先に通知するステップを有することを特徴とする。
上記課題を解決するための第３９の発明は、上記第３８の発明において、
前記推定ステップは、
前記送信されたSYNパケットのシーケンス番号を受け取る受取ステップと、
前記受け取ったシーケンス番号を考慮した応答確認パケットを送信するステップと
を有することを特徴とする。
上記課題を解決するための第４０の発明は、
ネットワーク上の装置に関する情報を推定する推定システムのプログラムであって、前記プログラムは前記システムを、
送信されて来た情報収集用のパケットに応答して制御用のメッセージを返信する返信手段と、
前記返信手段からの制御用のメッセージに基づいて、前記ネットワーク上の装置に関する情報を推定する推定手段と
して機能させることを特徴とする。
上記課題を解決するための第４１の発明は、
端末のプログラムであって、前記プログラムは前記端末を、
受信したメッセージが情報収集用のパケットに応答して返信された制御用のメッセージであるかを判断する判断手段と、
前記判断の結果、受信したメッセージが前記情報収集用のパケットに応答して返信された制御用のメッセージであると判断された場合、この制御用のメッセージに基づいて、前記ネットワーク上の装置に関する情報を推定する推定手段
として機能させることを特徴とする。
上記課題を解決するための第４２の発明は、
ネットワーク上の装置に関する情報を推定するシステムのプログラムであって、前記プログラムは前記システムを、
通信用のプロトコルで定められているエラーメッセージ又は制御メッセージを用いて前記ネットワーク上の装置に関する情報を推定する手段として機能させることを特徴とする。
本発明の第１の推定システムは、ネットワーク上のＰＣの待ち受け状態となっていないポート番号宛にパケットを送信するパケット送信部と、ネットワーク上のＰＣから送り返されてきたICMPポート到達不能メッセージを受信するパケット受信部と、受信したICMPポート到達不能メッセージのチェックサムからネットワークで行われたヘッダ変換を検出する解析部とを有する。本発明の第１の推定システムは、このような構成を採用し、ネットワーク上のＰＣから送り返されてきたICMPポート到達不能メッセージのチェックサムを元にして、ヘッダ変換を推定することにより、専用サーバを設置することなく、ＮＡＴルータによるヘッダ変換の内容を把握することができる。以上の理由により、本発明の目的を達成することができる。
本発明の第２の推定システムは、本発明の第１の推定システムの解析部において実行する処理を変更している。そして、本発明の第２の推定システムの解析部は、本発明の第１の推定システムの解析部の処理に加えて、ネットワークの経路調査試験を行い、ヘッダ変換の推定精度を高めている。本発明の第２の推定システムは、このような構成を採用し、ネットワークの経路調査試験の結果を加味して、ヘッダ変換を推定することにより、本発明の第１の推定システムで完全に絞り込めていない場合でも、ヘッダ変換の内容を正確に把握することができる。以上の理由により、本発明の目的を達成することができる。
本発明の第３の推定システムは、本発明の第１の推定システムの解析部、パケット送信部、およびパケット受信部において実行する処理を変更している。本発明の第３の推定システムは、ネットワーク上のＰＣ宛にTTLの値を小さく設定したパケットを送信するパケット送信部と、ネットワーク上のルータから送り返されてきたICMP Time Exceededメッセージを受信するパケット受信部と、受信したICMP Time Exceededメッセージのチェックサムからネットワークで行われたヘッダ変換を検出する解析部とを有する。本発明の第３の推定システムは、このような構成を採用し、ネットワーク上のルータから送り返されてくるICMP Time Exceededメッセージのチェックサムを元にして、ヘッダ変換を推定することにより、ICMPポート到達不能メッセージがネットワーク内で破棄されてしまった場合でも、専用サーバを設置することなく、ＮＡＴルータによるヘッダ変換の内容を把握することができる。以上の理由により、本発明の目的を達成することができる。
本発明の第４の推定システムは、本発明の第３の推定システムの解析部、パケット送信部、およびパケット受信部において実行する処理を変更している。本発明の第４の推定システムは、ネットワーク上のＰＣ宛にTTLの値を小さく設定したパケットを送信するパケット送信部と、ネットワーク上のルータから送り返されてきたICMP Time Exceededメッセージを受信するパケット受信部と、受信したICMP Time Exceededメッセージのチェックサムからネットワークで行われたヘッダ変換を検出する解析部とを有する。本発明の第４の推定システムは、このような構成を採用し、ＮＡＴルータにおいて、ICMP Time ExceededメッセージのＩＰチェックサムが正しい値に変換されてしまう場合でも、専用サーバを設置することなく、ICMP Time ExceededメッセージのＵＤＰチェックサムを元にして、ＮＡＴルータによるヘッダ変換の内容を把握することができる。以上の理由により、本発明の目的を達成することができる。
本発明の第５の推定システムは、本発明の第３の推定システムの解析部、パケット送信部、およびパケット受信部において実行する処理を変更するとともに、アプリケーション部を含んでいる。本発明の第５の推定システムは、ネットワーク上のＰＣ宛にTTLの値を小さく設定したパケットを送信するパケット送信部と、ネットワーク上のルータから送り返されてきたICMP Time Exceededメッセージを受信するパケット受信部と、受信したICMP Time Exceededメッセージのチェックサムからネットワークで行われたヘッダ変換を検出するとともに、その検出結果を通信相手となるＰＣに通知する解析部と、通信相手となるＰＣとパケットのやり取りを行うアプリケーション部とを有する。本発明の第５の推定システムは、このような構成を採用し、お互いのＰＣがＮＡＴルータの配下に設置されている場合でも、ICMP Time ExceededメッセージのチェックサムからＮＡＴルータによるヘッダ変換の内容を把握するとともに、ＰＣ間でその情報を通知しあうことにより、専用サーバを設置することなく、ＰＣ間でパケットをやり取りするために必要な情報を把握することができる。以上の理由により、本発明の目的を達成することができる。
本発明の第６の推定システムは、本発明の第３の推定システムの解析部において実行する処理を変更している。本発明の第６の推定システムの解析部は
受信したICMP Time Exceededメッセージからネットワークで行われたToSフィールドの変化を検出している。本発明の第６の推定システムは、このような構成を採用し、ネットワーク上のルータから送り返されてくるICMP Time Exceededメッセージを元にして、ToSフィールドの変化を推定することにより、専用サーバを設置することなく、ネットワーク内で優先制御機能が働いているかどうかを把握できる。以上の理由により、本発明の目的を達成することができる。
本発明の第７の推定システムは、本発明の第３の推定システムの解析部において実行する処理を変更している。本発明の第７の推定システムは、受信したICMP Time Exceededメッセージからネットワークで行われたフラグメントフィールドの変化を検出している。本発明の第７の推定システムは、このような構成を採用し、ネットワーク上のルータから送り返されてくるICMP Time Exceededメッセージを元にして、フラグメントフィールドの変化を推定することにより、専用サーバを設置することなく、ネットワーク内でフラグメントが発生したかどうかを把握できる。以上の理由により、本発明の目的を達成することができる。
本発明の第８の推定システムは、本発明の第５の推定システムの解析部、パケット送信部、パケット受信部において実行する処理を変更するとともに、TCP部４００８を追加している。本発明の第８の推定システムは、このような構成を採用し、通信相手と３way handshake処理を行うことにより、専用サーバを設置することなく、PC間でTCPパケットをやり取りするのに必要な情報を把握することができる。以上の理由により、本発明の目的を達成することができる。
本発明によると、専用サーバをインターネット上に設置することなく、既存の標準的な通信プロトコルでＩＣＭＰを巧みに利用することにより、ＩＣＭＰヘッダのチェックサムの値から、ネットワーク内におけるヘッダ変換を推定できるので、本発明の目的を達成することができる。
このため、専用サーバの保守/運用コストが不要になるとともに、専用サーバが外部の不正なユーザから攻撃されるといったこともないので安全である。さらに、ＬＡＮのＰＣの数が増加した場合でも、各ＰＣごとにＵＤＰパケットの宛先を変えれば、ＩＣＭＰパケットを送り返すＰＣ４０５の負荷も大きくならないので、スケーラビリティの面でも優れている。
本発明の上述の特徴と優位点を得ることができる形態を説明するために、以下において、図面を参照して具体的な実施例を述べるものとする。しかしながら、これらの図面および説明は、本発明の典型的な実施形態のみを示しており、その範囲を限定するものではないことを理解すれば、本発明は、以下に添付する図面を用いて、さらに明確および詳細に記載され、説明されるであろう。
本発明を実施するための第１の実施の形態について図面を参照して詳細に説明する。
<構成>
図４を参照すると、本発明の第１の実施の形態は、インターネットのようなネットワーク４０４と、アドレス変換を行うＮＡＴルータ４０２、ＮＡＴルータ４０６と、ユーザが操作するＰＣ４０１、ＰＣ４０７と、インターネット上に設置されている任意のＰＣ４０５と、パケットの経路制御を行うルータ４０３とを含む。
また、ネットワーク４は、パケットの経路制御を行うルータ４０８〜４１１を含む。
ここで、ＰＣ４０５には非特許文献１に記載の専用サーバ３１２のような特別な機能は搭載されておらず、ＰＣ４０５は標準的な任意の端末であるとする。
ＰＣ４０１の内部構成を図５に示す。
図５に示されるように、ＰＣ４０１は、解析部５０６と、パケット受信部５０４と、パケット送信部５０５と、オペレーティングシステム５００とを含んでいる。ここで、オペレーティングシステム５００は、ＵＤＰ部５０３と、ＩＰ部５０２と、ＭＡＣ部５０１とを含んでいる。
解析部５０６は、ネットワーク内で行われたヘッダ変換の内容を検出するために必要な情報を収集するためのＵＤＰパケットを、設定されたＩＰアドレス及びポート番号宛に送信するようにパケット送信部５０５に命令する。また、解析部５０６は、パケット受信部５０４から渡されるＩＣＭＰパケットのヘッダ情報から、ネットワーク内で行われたヘッダ変換の内容を検出する。尚、ＵＤＰパケットはダミーパケットであってもよい。
パケット送信部５０５は、解析部５０６からＵＤＰパケットの送信命令を受け取ると、解析部５０６によって指定された宛先に向けてＵＤＰパケットの送信処理を行うために、データをＵＤＰ部５０３に渡す。
パケット受信部５０４は、ＩＰ部５０２からＩＣＭＰパケットを受け取り、そのデータを解析部５０４に渡す。
ＵＤＰ部５０３は、パケット送信部５０５から渡されたデータにＵＤＰヘッダを追加した後、ＩＰ部５０６に渡す。
ＩＰ部５０２は、ＵＤＰ部５０３から渡されたデータにＩＰヘッダを追加した後、ＭＡＣ部５０１に渡す。
また、ＩＰ部５０２は、ＭＡＣ部５０１からデータを受け取ると、そのデータがＵＤＰパケットに応答して送信されたＩＣＭＰパケットのデータ部分であるかを判断し、判断の結果、ＵＤＰパケットに応答して送信されたＩＣＭＰパケットである場合には、パケット受信部５０４に渡す。
ＭＡＣ部５０１は、ＩＰ部５０２から渡されたデータにＭＡＣヘッダを追加した後、伝送路に送信する。また、ＭＡＣ部５０１は、伝送路からデータを受け取ると、ＭＡＣヘッダを外した後、ＩＰ部５０２に渡す。
ここで、ＵＤＰ部５０３、ＩＰ部５０２、およびＭＡＣ部５０１には、オペレーティングシステム５００が標準的に搭載しているTCP/IP機能を流用するのが一般的である。
<動作>
続いて、図４〜図１８を参照しながら、本発明を実施するための実施の形態の動作について詳細に説明する。
まず、図５の解析部５０６は、何らかのタイミングを契機に、ＵＤＰパケットを送信する（図６のステップＳ６０２）。
このＵＤＰパケットを送信するタイミングとしては、下記のうちのいずれか、および組み合わせが考えられる。
・ユーザインターフェースや他のアプリケーションから命令された時
・解析部のサービス起動時
・PCの電源投入時
・一定の時間間隔毎
・PCのIPアドレスの更新時
ただし、前述の送信タイミングは単なる例であることが理解されるべきである。本説明を再検討すれば、送信タイミングとして多種多様なものが存在することは、本技術分野の当業者にとって明らかであろう。
また、ＵＤＰパケットの宛先としては、下記のうちのいずれか、および組み合わせが考えられる。
・ユーザインターフェースや他のアプリケーションから指定された、ＩＰアドレスとポート番号に向けて送信する
・設定ファイルなどに予め設定されているＩＰアドレスとポート番号に向けて送信する
・ランダムに選んだＩＰアドレスとポート番号に向けて送信する
ただし、前述のパケットの宛先は単なる例であることが理解されるべきである。本説明を再検討すれば、パケットの宛先として多種多様なものが存在することは、本技術分野の当業者にとって明らかであろう。
以下の動作説明では、解析部５０６のサービス起動時に、ＰＣ４０１からＵＤＰパケットを予め設定ファイルに登録されているＩＰアドレス及びポート番号に向けて送信する方法を採用した場合を例に説明する。
ここで、設定ファイルには、ＩＰアドレスとして図４のＰＣ４０５の２００．２０．１．１、ポート番号として９９９９が登録されているものとする。このポート番号９９９９は、ＰＣ４０５で待ち受け状態になっていないポート番号であるとする。このようなポート番号を宛先に設定している理由は、ＰＣ４０５からＩＣＭＰポート到達不能メッセージを返してもらうためである。
図５の解析部５０６は、パケット送信部５０５に上記のＩＰアドレスとポート番号を通知し、ネットワーク内で行われたヘッダ変換の内容を検出するためのパケットであるＵＤＰパケットの送信を依頼する（図６のステップＳ６０３）。
パケット送信部５０５は、解析部５０６からＵＤＰパケットの送信依頼を受けると（図７のステップＳ７０１）、指定されたＩＰアドレスとポート番号宛のＵＤＰソケットをオープンし、ＵＤＰ部５０３にデータを渡す（図７のステップＳ７０２）。
ＵＤＰ部５０３は、パケット送信部５０５からデータ送信の依頼を受けると（図８のステップＳ８０１）、データにＵＤＰヘッダを付加してＵＤＰパケットを生成し（図８のステップＳ８０２）、ＩＰ部５０２に転送する（図８のステップＳ８０３）。
ＩＰ部５０２は、ＵＤＰ部５０３からＵＤＰパケットを受け取ると、ＩＰパケットを付加してＩＰパケットを生成し、ＭＡＣ部５０１に転送する（図９のステップＳ９０３）。
ＭＡＣ部５０１は、ＩＰ部５０２からＩＰパケットを受け取ると（図１０のステップＳ１００１）、ＭＡＣヘッダを付加してＭＡＣフレームを生成し（図１０のステップＳ１００２）、伝送路に送信する（図１０のステップＳ１００３）。
図１１（a）には、上記の処理により、ＰＣ４０１から送信されるパケットを示している。
このように送信されたデータは、まず、図４のＮＡＴルータ４０２において、送信元ＩＰアドレスと送信元ポート番号が変換される。この例では、送信元ＩＰアドレスが１９２．１６８．０．２から２００．１０．１．１へ、送信元ポート番号が６５０００から６５００１に変更される。また、これらの変更に伴い、ＩＰヘッダのチェックサムとＵＤＰヘッダのチェックサムも再計算される。この例では、ＩＰヘッダのチェックサムが0x10から0x20に、UDPヘッダのチェックサムが0x100から0x200に変更されたとする。
図１１（b）には、上記の処理により、ＮＡＴルータ４０２から送信されるパケットを示している。
このように変更されたパケットは、幾つものルータを経由しながら、ＰＣ４０５に届けられる。説明を簡単にするために、この例では、ＮＡＴルータ以外の通信装置はヘッダを変換しないものとする。
ＰＣ４０５は、このパケットを受信するが、宛先ポート番号である９９９９は待ち受け状態になっていない。このため、パケットの送信元であるＮＡＴルータ４０２に、ＩＣＭＰポート到達不能メッセージを送り返す。
このＩＣＭＰポート到達不能メッセージは、図１１（c）のように、ＩＣＭＰパケットとして送られるが、ＩＣＭＰパケットのデータ部には、先程受信した図１１(b)のパケットがそのまま付加される。
図１１（c）には、上記の処理により、ＰＣ４０５から送信されるパケットを示している。
ＮＡＴルータ４０２は、このＩＣＭＰパケットを受信すると、ＩＣＭＰパケットをＰＣ４０１に転送するために、そのＩＰヘッダの宛先ＩＰアドレスを２００．１０．１．１から１９２．１６８．０．２に変更する。また、この変更に伴い、ＩＰヘッダのチェックサムも再計算し、0x30から0x40に変更している。
また、ＮＡＴルータ４０２は、ＩＣＭＰヘッダのデータ部も変更する。具体的には、送信元ＩＰアドレスを２００．１０．１．１から１９２．１６８．０．２へ、送信元ポート番号を６５００１から６５０００に変更する。このようにＩＣＭＰヘッダのデータ部も変更してやることにより、あくまでＰＣ４０１へのＩＣＭＰポート到達不能メッセージであるかのように見せかけることができる。
ここで、ＮＡＴルータ４０２では、図１１（d）に示されるように、ＩＣＭＰヘッダのデータ部のチェックサムまでは変更されないため、チェックサムは誤った値となっている。
ＰＣ４０１は、このＩＣＭＰパケットをＮＡＴルータ４０２から受け取ると（図１２のステップＳ１２０１）、まずＭＡＣ部５０１でＭＡＣヘッダを外した後（図１２のステップＳ１２０２）、ＩＰ部５０２に転送する（図１２のステップＳ１２０３）。
ＩＰ部５０２は、ＭＡＣ部５０１からＩＣＭＰパケットを受け取ると（図１３のステップＳ１３０１）、ＩＰヘッダを外した後（図１３のステップＳ１３０２）、そのデータがＵＤＰパケットに応答して送信されたＩＣＭＰパケットのデータ部分であるかを判断する。判断の結果、ＵＤＰパケットに応答して送信されたＩＣＭＰパケットである場合には、パケット受信部５０４に転送する（図１３のステップＳ１３０３）。
パケット受信部５０４は、ＩＰ部５０２からＩＣＭＰデータを受け取ると（図１４のステップＳ１４０１）、そのＩＣＭＰヘッダのデータ部を解析部５０６に転送する（図１４のステップＳ１４０２）。
解析部５０６は、パケット受信部５０４からデータ部を受け取ると（図１５のステップＳ１５０１）、そのチェックサムの状態から、ネットワークでヘッダ変換が行われたのかどうか検出する。以下において、その方法について述べる。
まず、解析部５０６では、受け取ったデータのＩＰヘッダから、ＩＰチェックサムを計算する（図１５のステップＳ１５０２）。
続いて、この計算されたＩＰチェックサムが、受け取ったデータのＩＰチェックサムと一致するかどうか確認する（図１５のステップＳ１５０３）。
ここで、ＮＡＴルータ４０２においてＩＰアドレスの変換が行われた場合には、ＩＰチェックサムが一致しないので、ＩＰアドレス変換の発生を検出することができる。
一致しなかった場合には、ＩＰアドレスの変換が起こったと考え、ＮＡＴルータ４０２のＩＰアドレスを推定するために、図１５のステップＳ１５０４に進む。
一致した場合には、ＩＰアドレスの変換が起こらなかったものとして、ステップＳ１５０５に進み、受け取ったデータのＵＤＰヘッダから、ＵＤＰチェックサムを計算する。
そして、この計算されたＵＤＰチェックサムが、受け取ったデータのＵＤＰチェックサムと一致するかどうかを確認する（図１５のステップＳ１５０６）。
ここで、ＮＡＴルータ４０２においてポート番号の変換が行われた場合には、ＵＤＰチェックサムが一致しないので、ポート番号変換の発生を検出することができる。
一致しなかった場合には、ポート番号の変換が起こったと考え、ＮＡＴルータ４０２のポート番号を推定するために、図１５のステップＳ１５０７に進む。
一致した場合には、ポート番号の変換が起こらなかったものとして、処理を終了する。
以下では、ＩＰチェックサムとＵＤＰチェックサムの両方が誤っている場合の推定処理について説明する。
図１６には、図１５のステップＳ１５０４で実行されるＩＰアドレスの推定処理を示している。
ＩＰアドレスは３２ビットで構成されるが、解析部５０６では、まずＩＰアドレスの上位１６ビットをＸとし、下位１６ビットがＹであると仮定する。送信元ＩＰアドレスをこのように仮定して、受け取ったデータのＩＰチェックサムの方程式を立てる（図１６のステップＳ１６０２）。
ここでＩＰチェックサムの計算方法について補足すると、ＩＰチェックサムは、ＩＰヘッダを１６ビットごとに分割して、それぞれの「１の補数」の総和を求めた後、その総和の「１の補数」がＩＰチェックサムとなる。
解析部５０６では、ＩＰアドレスを推定するために、ステップＳ１６０２で求められた方程式を満足するＸとＹを総当り計算する（図１６のステップＳ１６０４〜ステップＳ１６０７）。
この方程式を満足するＩＰアドレスには、ＮＡＴのＩＰアドレスと一致するものが存在するが、上記方程式を満足するＸとＹの組み合わせは３２７６８通り存在する。第１の実施の形態では、これらの組み合わせ候補を絞り込む方法については言及しない。
一方、図１７には、図１５のステップＳ１５０７で実行されるポート番号の推定処理を示している。
ポート番号は１６ビットで構成されるが、解析部５０６では、答えとなるポート番号がＷであると仮定する。送信元ポート番号をこのように仮定して、受け取ったデータのＵＤＰチェックサムの方程式を立てる（図１７のステップＳ１７０２）。
ここでＵＤＰチェックサムの計算方法について補足すると、ＵＤＰチェックサムは、「ＵＤＰヘッダ」と「ペイロードデータ」、そして図１８に示される「ＵＤＰ擬似ヘッダ」の３つの部分が計算の対象となる。
ここで、「UDP擬似ヘッダ」とは、チェックサムの計算時だけに使われる仮想的なヘッダであり、実際のUDPパケット中には含まれていない。ＵＤＰチェックサムは、この「ＵＤＰ擬似ヘッダ」を含んだヘッダ全体を１６ビットごとに分割して、それぞれの「１の補数」の総和を求めた後、その総和の「１の補数」がＵＤＰチェックサムとなる。
解析部５０６では、ポート番号を推定するために、ステップＳ１７０２で求められた方程式を満足するＷを計算する（図１７のステップＳ１７０３）。ここで、擬似ヘッダ中の送信元ＩＰアドレスには、上述の図１６の処理によって求められたＩＰアドレスが代入されることになる。
この方程式を満足するポート番号には、ＮＡＴのポート番号と一致するものが存在する。
以上の処理により、ＩＣＭＰヘッダのチェックサムから、ＮＡＴの送信元ＩＰアドレスとポート番号を推定できることが示された。
尚、上記実施の形態では、待ち受け状態になっていないポート番号を宛先に設定してパケットを送信し、ＩＣＭＰポート到達不能メッセージ（エラーメッセージ）を返してもらう構成について説明したが、この限りではない。即ち、ＰＣ４０１がＰＣ４０５宛にパケットを送信し、ＰＣ４０１がこのパケットに応答して制御メッセージをＰＣ４０１に返信する構成であればよい。また、本明細書では、エラー（到達不能）メッセージや制御メッセージ等のように、通信のプロトコルで定められている通信の手続上のメッセージ（パケット）を総称して制御用のメッセージ（パケット）とする。
<効果>
続いて、本発明を実施するための第１の実施の形態の効果について説明する。
本発明を実施するための第１の実施の形態では、専用サーバをインターネット上に設置することなく、既存の標準的な通信プロトコルでＩＣＭＰを巧みに利用することにより、ＩＣＭＰヘッダのチェックサムの値から、ネットワーク内におけるヘッダ変換を推定できるので、本発明の目的を達成することができる。
このため、専用サーバの保守/運用コストが不要になるとともに、専用サーバが外部の不正なユーザから攻撃されるといったこともないので安全である。さらに、ＬＡＮのＰＣの数が増加した場合でも、各ＰＣにＵＤＰパケットの宛先を変えれば、ＩＣＭＰパケットを送り返すＰＣ４０５の負荷も大きくならないので、スケーラビリティの面でも優れている。
次に、本発明を実施するための第２の実施の形態について図面を参照して詳細に説明する。
<構成>
本発明の第１の実施の形態では、ＩＣＭＰポート到達不能メッセージのチェックサムから、ＮＡＴルータのＩＰアドレスとポート番号を推定していた。しかしながら、ＩＰチェックサムとＩＰアドレスの情報量に差が存在するため、ＩＰチェックサムからＩＰアドレスを推定しようとしても、ＩＰアドレスを一意に絞り込むことができない可能性がある。
この理由は、ＩＰチェックサムが１６ビット、つまり３２７６８通りの組み合わせしか持たないのに対して、ＩＰアドレスは３２ビット、つまり３２７６８×３２７６８通りもの組み合わせを持っており、同じＩＰチェックサムを計算結果とするＩＰアドレスが３２７６８通りも存在してしまうからである。
以上のことから、本発明の第１の実施の形態では、チェックサムからＮＡＴルータのＩＰアドレスとポート番号を絞り込むことができず、推定精度が悪かった。
本発明の第２の実施の形態では、図５の解析部５０６とパケット送信部５０５、およびパケット受信部５０４で実行する処理を変更する。本発明の第２の実施の形態の構成を図１９に示す。
解析部１９０６は、図５の解析部５０６の処理に加えて、ＩＰアドレスの推定精度を高めるために、ネットワークの経路調査用パケットを送信するようにパケット送信部１９０５に命令する。また、解析部１９０６は、パケット受信部１９０４から渡されるネットワークの経路調査結果から、ＩＰアドレスの絞込み処理を行う。
パケット送信部１９０５は、図５のパケット送信部５０５の処理に加えて、解析部１９０６から経路調査用パケットの送信命令を受け取ると、経路調査用パケットを送信する。ここで行う経路調査方法は、あるＰＣから別のＰＣまでの経路上にどのようなルータが位置しているかを調べることである。
パケット受信部１９０４は、図５のパケット受信部５０４の処理に加えて、経路調査結果をネットワークから受け取ると、その結果を解析部１９０６に渡す。
その他の構成は、第１の実施の形態の図５と同じであるため、説明を省略する。
<動作>
続いて、図１９を参照して本発明を実施するための第２の実施の形態の動作について詳細に説明する。
まず、本発明の第１の実施の形態と同じ処理を実行することにより、ＮＡＴルータのＩＰアドレスとポート番号とを推定する。ただし、この時点では、上述したように、まだＩＰアドレスとポート番号を一意に値に絞り込めておらず、３２７６８通りの組み合わせが存在する。
続いて、解析部１９０６は、ネットワークの経路調査試験を行う。この経路調査試験では、経路上に存在する各ルータを割り出すために、IPパケットにおけるTTL（Time To Live）の仕組みを利用する。TTLとは、IPパケットヘッダに指定可能な「生存時間」である。ただし、実際には時間ではなく、「ホップ数」を意味している。つまり、そのパケットが「生存」できるホップ数を指定するのがTTLである。
TTLには最大255が設定可能で、ルータをホップするごとに必ずTTLが1ずつ減らされる。そして、TTLが0に達するとパケットがルータで破棄されるとともに、パケットを破棄したルータはICMP Time Exceededエラーを送信元ＰＣに送り返す。このICMPTime Exceededエラーには、破棄したルータのIPアドレスが含まれる。送信元ＰＣはこのICMP Time Exceededエラーを受け取ることで、その送信元IPアドレスから、破棄したルータのIPアドレスを検出することができる。
上記のネットワークの経路調査試験では、TTLを１から順に増やしながら試行を重ねることにより、経路上に存在する各ルータの情報を得ている。例えば、ＰＣ４０１から、まず最初にTTLを１としたIPパケットをＰＣ４０５に送出すると、１番目のＮＡＴルータ４０２（１ホップ目）が受け取った時点でTTLを減算した結果、０となってしまうので、ＮＡＴルータ４０２からICMP Time Exceededエラーが送り返される。これが１台目のルータの結果となる。ただし、ここで得られるＩＰアドレスは、ＮＡＴルータ４０２の内側（ＬＡＮ側）ＩＰアドレス（１９２．１６８．０．１）である。次にTTLを２にして送出すれば、2台目のルーター４０３のＩＰアドレス（２００．１０．１．２）が得られる。
上記の処理を実行するために、解析部１９０６は、まず、設定ファイルに登録されている宛先IPアドレスを取得し（図２０のステップＳ２００１）、ＰＣ４０５のＩＰアドレスとTTL値１をパケット送信部１９０５に通知する（図２０のステップＳ２００３）。
パケット送信部１９０５は、解析部１９０６から宛先IPアドレスを受け取り（図２１のステップＳ２１０１）、この受け取った宛先IPアドレスとTTL値から、ICMP Echoリクエストパケットを生成し、MAC部１９０１に渡す（図２１のステップＳ２１０２）。
MAC部１９０１は、パケット送信部１９０５からICMP Echoリクエストパケットを受け取ると（図２２のステップＳ２２０１）、MACヘッダを追加し（図２２のステップＳ２２０２）、ネットワークに転送する（図２２のステップＳ２２０３）。
ネットワークに送出されたパケットは、各ルータにおいてTTLが１ずつ減算されていき、TTLが０となった時点でルータからICMP Time ExceededパケットがＰＣ４０１に返される。
MAC部１９０１は、ネットワークからICMP Time Exceededパケットを受け取ると（図２３のステップＳ２３０１）、MACヘッダを削除し（図２３のステップＳ２３０２）、パケット受信部１９０４に転送する（図２３のステップＳ２３０３）。
パケット受信部１９０４は、MAC部１９０１からICMP Time Exceededパケットを受け取ると（図２４のステップＳ２４０１）、パケットの送信元IPアドレスＧを解析部１９０６に通知する（図２４のステップＳ２４０２）。
解析部１９０６は、パケット受信部１９０４からIPアドレスＧを受け取とると（図２５のステップＳ２５０１）、そのＩＰアドレスＧがグローバルＩＰアドレスとなっているかどうかをチェックする（図２５のステップＳ２５０２）。ここで、ＩＰアドレスＧがグローバルＩＰアドレスとなっていない場合には、次ホップのルータのＩＰアドレスを取得することを試みる。具体的な処理としては、ＰＣ４０５のＩＰアドレスとＴＴＬ値２をパケット送信部１９０５に通知する（図２５のステップＳ２５０４）。
一方、上述の図２５のステップＳ２５０２において、受け取ったＩＰアドレスＧがグローバルＩＰアドレスとなっている場合には、このときのＴＴＬ値（ここではＸとする）とＩＰアドレスＧを記憶する。
そして、解析部１９０６は、まずこのＩＰアドレスＧを元にして、第１の実施の形態で推定されたＩＰアドレスの絞込みを行う。
絞込み方法としては、図１６のステップＳ１６０６で求められたＩＰアドレスのうち、ＩＰアドレスＧと近いものを抽出し、この抽出されたＩＰアドレスをＮＡＴルータのＩＰアドレスであると推定する（図２５のステップＳ２５０７）。
この絞込み方法の正当性を以下に述べる。
解析部１９０６では、上記のネットワークの経路情報の取得処理により、ルータ４０３のＩＰアドレスＧ（２００．１０．１．２）を検出できる。ここで、ルータ４０３はNATルータ４０２と同じサブネットワークに入っているため、サブネットマスクで決められたネットワークアドレスは、ルータ４０３とＮＡＴルータ４０２は同じ値となっている。例えば、図４の例では、ルータ４０３のＩＰアドレスとNATルータ４０２のＩＰアドレスは、２００．１０．１．までは同じ値となっている。
解析部１９０６では、この特徴を利用し、本発明の第１の実施の形態において推定されたＩＰアドレスのうち、ルータ４０３のＩＰアドレスＧ（２００．１０．１．２）と近いものを検索することにより、ＮＡＴルータ４０２のＩＰアドレスとして確からしいものを選択することができる。
ただし、このとき、ルータ４０３のＩＰアドレスＧ（２００．１０．１．２）を検出できても、そのサブネットマスクが何ビットであるかまでは検出できない。このため、サブネットマスクを想定する必要があるが、サブネットマスクの想定値によって、本発明の第１の実施の形態において推定されたＩＰアドレスのうち、ルータ４０３のＩＰアドレスＧ（２００．１０．１．２）と近いと判定されるものが複数でてきてしまう。
たとえば、サブネットマスクを８ビットと想定した場合、本発明の第１の実施の形態において推定されたＩＰアドレスのうち、ルータ４０３のＩＰアドレスＧ（２００．１０．１．２）と近いと判定されるものは、２５６通りほど出てくる可能性がある。
また、サブネットマスクを１６ビットと想定した場合には、本発明の第１の実施の形態において推定されたＩＰアドレスのうち、ルータ４０３のＩＰアドレスＧ（２００．１０．１．２）と近いと判定されるものは、１つに絞りこめる。
このように、ＩＰアドレスを絞り込めるか否かは、サブネットマスクの想定値に依存する。
以下では、サブネットマスクを８ビットと想定した場合の、さらなる絞込み方式について述べる。
ここで、サブネットマスクを８ビットとしているのは、サブネットマスクは８ビット以下に設定されることがなく、このような想定を行うことにより、本絞込み方式をあらゆるネットワークに適用できるためである。
上述したように、サブネットマスクを８ビットと想定すると、本発明の第１の実施の形態において推定されたＩＰアドレスは２５６通り程度に絞り込める。
このように絞り込まれたＩＰアドレスを、さらに絞り込んで一意に特定するために、解析部１９０６は以下のような処理を行う。
解析部１９０６では、まず、上記のように２５６通りに絞り込まれた各ＩＰアドレスに対して、そのＩＰアドレスを持つ端末に到達するのに必要なホップ数を調査する。
ここで、端末までのホップ数は、LinuxやWindows（登録商標）などのOSに標準的に搭載されている traceroute（tracert）などのコマンドを使って調べることができる。
次に、プライベートIPアドレスとグローバルIPアドレスが切り替わるルータまでのホップ数を調査する。
このルータまでのホップ数の調査方法としては、PC４０５のようなグローバルIPアドレスをもつ端末に向けてtraceroute（tracert）コマンドを使用して、PC401とPC405の間のルータを調査することによって調査することができる。
例えば、PC401からPC405に向けて、traceroute（tracert）コマンドを使用した場合、以下のような結果が返される。
ホップ数 端末
1 NATルータ402（192.168.0.1）
2 ルータ403 （200.10.1.2 ）
3 ルータ408
4 ルータ411
5 ルータ410
6 PC405 (200.20.1.1)
この場合、ホップ数１と２の間で、端末のIPアドレスがプライベートIPアドレスからグローバルIPアドレスに切り替わっている。この結果から、プライベートIPアドレスとグローバルIPアドレスが切り替わるルータまでのホップ数は１であると判定する。
解析部１９０６では、２５６通りに絞り込まれた各ＩＰアドレスを一意に絞り込むために、上述のルータまでのホップ数を用いる。具体的には、２５６通りに絞り込まれた各ＩＰアドレスのうち、上述のルータまでのホップ数（この場合１であるが）と一致するものを検索し、そのIPアドレスをNATルータ402の外部IPアドレスと判定する。
以上の処理により、ネットワークの経路調査結果から、ＮＡＴルータのＩＰアドレスを絞り込めることが示された。
また、このＩＰアドレスに対応するポート番号は一意に定まるので、ポート番号も絞り込める。
<効果>
続いて、本発明を実施するための第２の実施の形態の効果について説明する。
本発明を実施するための第２の実施の形態では、専用サーバをインターネット上に設置することなく、ＩＣＭＰヘッダのチェックサムの値とネットワークの経路調査結果からヘッダ変換を推定することにより、ヘッダ変換の内容を高精度に検出できるので、本発明の目的を達成することができる。
次に、本発明を実施するための第３の実施の形態について図面を参照して詳細に説明する。
<構成>
本発明の第１および第２の実施の形態では、ＰＣ４０５から送り返されるＩＣＭＰポート到達不能メッセージのチェックサムを元にして、ＮＡＴルータのＩＰアドレスとポート番号を推定していた。しかしながら、ＩＣＭＰポート到達不能メッセージは特殊なパケットであるので、NATルータによっては破棄してしまう可能性がある。
このように、NATルータにおいてＩＣＭＰポート到達不能メッセージが破棄されてしまった場合、第１および第２の実施の形態では、ヘッダ変換の有無を検出することはできない。
以上のことから、本発明の第１および第２の実施の形態では、ＮＡＴルータの種類によっては、ヘッダ変換の内容を推定できない可能性があり、使い勝手が悪い。
本発明の第３の実施の形態では、上記の問題を解決するために、図５の解析部５０６、パケット送信部５０５、およびパケット受信部５０４で実行する処理を変更する。本発明の第３の実施の形態の構成を図２６に示す。
解析部は、図５の解析部５０６の処理に加えて、ネットワークのヘッダ変換を検出できるＮＡＴルータの種類を増やすために、ICMPポート到達不能メッセージの代わりに、より標準的なメッセージであるICMP Time Exceededエラーを利用する。このICMP Time Exceededエラーをルータから送り返してもらうために、解析部２６０６は、TTLの値を小さく設定したUDPパケットを送信するようにパケット送信部２６０５に命令する。また、解析部２６０６は、パケット受信部２６０４から渡されるICMPTime Exceededメッセージのヘッダ情報から、ネットワーク内で行われたヘッダ変換の内容を推定する。
パケット送信部２６０５は、解析部２６０６からＵＤＰパケットの送信命令を受け取ると、指定された宛先に向けてＵＤＰパケットの送信処理を行うために、データをＭＡＣ部２６０１に渡す。
パケット受信部２６０４は、ルータから送られてきたICMP Time Exceededメッセージを受信し、そのヘッダ情報を解析部２６０６に渡す。
その他の構成は、第２の実施の形態の図１９と同じであるため、説明を省略する。
<動作>
続いて、図２６を参照して本発明を実施するための第３の実施の形態の動作について詳細に説明する。
まず、解析部２６０６は、何らかのタイミングを契機に、ＵＤＰパケットまたはＴＣＰパケットを送信する。
ＵＤＰパケット、またはＴＣＰパケットを送信するタイミングとしては、下記のうちのいずれか、および組み合わせが考えられる。
・ユーザインターフェースや他のアプリケーションから命令された時
・解析部のサービス起動時
・PCの電源投入時
・一定の時間間隔毎
・PCのIPアドレスの更新時
ただし、前述の送信タイミングは単なる例であることが理解されるべきである。本説明を再検討すれば、送信タイミングとして多種多様なものが存在することは、本技術分野の当業者にとって明らかであろう。
また、ＵＤＰパケット、またはＴＣＰパケットの宛先としては、下記のうちのいずれか、および組み合わせが考えられる。
・ユーザインターフェースや他のアプリケーションから指定された、ＩＰアドレスとポート番号に向けて送信する
・設定ファイルなどに予め設定されているＩＰアドレスとポート番号に向けて送信する
・ランダムに選んだＩＰアドレスとポート番号に向けて送信する
ただし、前述のパケットの宛先は単なる例であることが理解されるべきである。本説明を再検討すれば、パケットの宛先として多種多様なものが存在することは、本技術分野の当業者にとって明らかであろう。
以下の動作説明では、解析部のサービス起動時に、ＵＤＰパケットを予め設定ファイルに登録されているＩＰアドレスとポート番号に向けて送信する方法を採用した場合を例に説明する。
ここで、設定ファイルには、ＩＰアドレスとしてＰＣ４０５の２００．２０．１．１、ポート番号として９９９９が登録されているものとする。
ただし、ポート番号として９９９９番を想定しているが、第３の実施の形態は、第１の実施の形態と異なり、ＩＣＭＰポート到達不能メッセージを送り返してもらう必要がないので、ポート番号として任意のものを選択することができることは、本技術分野の当業者にとって明らかであろう。
さらに、ここで送信するＵＤＰパケットのＴＴＬには、２や３といった非常に小さな値が設定される。
ＴＴＬに小さな値を設定している理由は、ネットワーク内のルータからICMP TTL Exceededメッセージを返してもらうためである。
解析部２６０６は、パケット送信部２６０５に上記のＩＰアドレスとポート番号、およびＴＴＬ値を通知し、ＵＤＰパケットの送信を依頼する（図２７のステップＳ２７０３）。
パケット送信部２６０５は、解析部２６０６から受け取った宛先IPアドレスとポート番号、およびTTL値から、UDPベースのIPパケットを生成し、MAC部２６０１に渡す（図２８のステップＳ２８０２）。
MAC部２６０１は、パケット送信部２６０５からIPパケットを受け取ると、ＭＡＣヘッダを付加してＭＡＣフレームを生成し、伝送路に送信する（図１１(a)）。
このように送信されたデータは、まず、図４のＮＡＴルータ４０２において、送信元ＩＰアドレスと送信元ポート番号が変換される。この例では、送信元ＩＰアドレスが１９２．１６８．０．２から２００．１０．１．１へ、送信元ポート番号が６５０００から６５００１に変更されたとする。また、これらの変更に伴い、ＩＰヘッダのチェックサムとＵＤＰヘッダのチェックサムも再計算される。この例では、ＩＰヘッダのチェックサムが0x10から0x20に、UDPヘッダのチェックサムが0x100から0x200に変更されたとする。さらに、ＮＡＴルータでは、ＴＴＬを２から１に書き換える。（図１１(b)）
このように変更されたパケットは、つぎにルータ４０３に届けられる。ルータ４０３では、ＴＴＬを１から０に書き換えるが、ＴＴＬが０になったので、このパケットを破棄する。そして、ルータ４０３はパケットの送信元であるＮＡＴルータ４０２にICMP Time Exceededメッセージを送り返す。
このICMP Time Exceededメッセージは、図１１（c）ののようなパケットして送られるが、そのデータ部には先程ルータ４０３が受信したパケットがそのまま付加される。
ＮＡＴルータ４０２は、このICMP Time Exceededメッセージを受信すると、ＰＣ４０１に転送するために、そのＩＰヘッダの宛先ＩＰアドレスを２００．１０．１．１から１９２．１６８．０．２に変更する。また、この変更に伴い、ＩＰヘッダのチェックサムも再計算し、0x30から0x40に変更している。
また、ＮＡＴルータ４０２では、ICMP Time Exceededメッセージのデータ部も変更している。具体的には、送信元ＩＰアドレスと２００．１０．１．１から１９２．１６８．０．２へ、送信元ポート番号を６５００１から６５０００に変更する。このようにＩＣＭＰヘッダのデータ部も変更してやることにより、このICMP Time ExceededメッセージをあくまでＰＣ４０１へのICMP Time Exceededメッセージであるかのようにできる。
ただし、ＮＡＴルータ４０２では、ＩＣＭＰヘッダのデータ部のチェックサムまでは変更されないため、チェックサムは誤った値となっている（図１１(d)）。
ＰＣ４０２は、このＩＣＭＰパケットをＮＡＴルータ４０２から受け取ると、まずＭＡＣ部２６０１でＭＡＣヘッダを外した後、ＩＰ部２６０２に転送する。
ＩＰ部２６０２は、ＭＡＣ部２６０１からＩＣＭＰパケットを受け取ると、ＩＰヘッダを外した後、そのデータがＵＤＰパケットに応答して送信されたＩＣＭＰパケットのデータ部分であるかを判断する。判断の結果、ＵＤＰパケットに応答して送信されたＩＣＭＰパケットである場合には、パケット受信部２６０４に転送する。
パケット受信部２６０４は、ＩＰ部２６０２からＩＣＭＰパケットを受け取ると、そのＩＣＭＰヘッダのデータ部を解析部２６０６に転送する。
解析部２６０６は、パケット受信部からデータ部を受け取ると、そのチェックサムの状態から、ネットワークでヘッダ変換が行われたのかどうかを検出する。
具体的には、ＩＰアドレスの変換が行われた場合には、データ部のＩＰチェックサムが誤った値となるので、検出することができる。また、ポート番号の変換が行われた場合には、データ部のＵＤＰチェックサムが誤った値となるので、同様に検出することができる。
解析部２６０６は、ヘッダ変換の発生を検出すると、ヘッダの変更内容の推定処理を開始する。この解析部で行われる推定処理は、第１の実施の形態の解析部５０６で行われる推定処理と同じであるため、説明を省略する。
また、本発明の第３の実施の形態だけでは、本発明の第１の実施の形態と同じ理由により、ＩＰアドレスとポート番号を一意に絞り込むことはできないが、本発明の第２の実施の形態と組み合わせることにより、推定精度を高めることができる。
以上の処理により、ＩＣＭＰポート到達不能メッセージがＮＡＴルータで破棄されてしまう場合でも、より標準的なメッセージであるICMP Time Exceededエラーを利用することにより、ＮＡＴの送信元ＩＰアドレスとポート番号を推定できることが示された。
<効果>
続いて、本発明を実施するための第３の実施の形態の効果について説明する。
本発明を実施するための第３の実施の形態では、ルータから送り返されてくるICMPTime Exceededメッセージの情報を元にして、ネットワーク内におけるヘッダ変換を推定することにより、ICMPポート到達不能メッセージがネットワーク内で破棄されてしまった場合でも、専用サーバをインターネット上に設置することなく、ネットワークのヘッダ変換を検出することができ、本発明の目的を達成することができる。
次に、本発明を実施するための第４の実施の形態について図面を参照して詳細に説明する。
<構成>
本発明の第１、第２、および第３の実施の形態では、図１１(b)のように、ＮＡＴルータ４０２において、ＩＰアドレスだけでなく、ポート番号も変換されることを仮定していた。すなわち、ＮＡＴルータ４０２において、ＮＡＰＴの処理が実行されることを想定していた。また、図１１(d)のように、ＮＡＴルータ４０２において、ネットワークから送り返されるＩＣＭＰパケットのチェックサムのうち、ＩＰチェックサムとＵＤＰチェックサムの両方が誤った値のまま転送されることを仮定していた。
しかしながら、ＮＡＴルータによっては、そのヘッダ変換の動作が、図１１(b)とは異なり、ＩＰアドレスのみを変換し、ポート番号は変換しないという単純なＮＡＴ動作であるものも多い。また、ＮＡＴルータによっては、そのヘッダ変換の動作が、図１１(d)とは異なり、ネットワークから送り返されるＩＣＭＰパケットのチェックサムのうち、ＩＰチェックサムについては正しい値に変換してから転送するものも多い。
本発明の第４の実施の形態では、ＮＡＴルータ４０２の動作として上記のように、ＮＡＴ処理を行うとともに、ＩＰチェックサムは正しく訂正するようなものを想定し、このような状況においても、ＩＣＭＰパケットのチェックサムの値から、ＮＡＴルータのＩＰアドレスを推定する方法について述べる。
本発明の第４の実施の形態では、上記の問題を解決するために、図２６の解析部２６０６、パケット送信部２６０５、およびパケット受信部２６０４で実行する処理を変更する。本発明の第４の実施の形態の構成を図２９に示す。
解析部２９０６は、図２６の解析部の処理に加えて、ＮＡＴルータ４０２がＮＡＴの動作を実行しているかどうかを確かめるために、ある宛先に向けてパケットを送信するようにパケット送信部２９０５に命令する。また、解析部２９０６は、パケット受信部２９０４から渡されるICMP Time Exceededメッセージのヘッダ情報から、ネットワーク内で行われたヘッダ変換の内容を検出する。
パケット送信部２９０５は、解析部２９０６からパケットの送信命令を受け取ると、指定された宛先に向けてパケットの送信処理を行うために、データをＭＡＣ部２６０１に渡す。
パケット受信部２９０４は、ルータから送り返されてきたICMP Time Exceededメッセージを受信し、そのヘッダ情報を解析部２９０６に渡す。
<動作>
続いて、図２９を参照して本発明を実施するための第４の実施の形態の動作について詳細に説明する。
解析部２９０６からパケットをＰＣ４０５に向けて送信する処理は、第３の実施の形態と同じであるため、説明を省略する。
以降の動作説明では、第３の実施の形態と同様に、ＵＤＰパケットをＰＣ４０１から送信することを想定しているが、ＵＤＰパケットの代わりにＴＣＰパケットを送信しても支障がないことは、本技術分野の当業者にとって明らかであろう。
このように送信されたデータは、まず、図４のＮＡＴルータ４０２において、送信元ＩＰアドレスが変換される。この例では、図３０（b）のように、送信元ＩＰアドレスが１９２．１６８．０．２から２００．１０．１．１に変換される。ここで、送信元ポート番号は６５０００番から変更されないものとする。また、この変更に伴い、ＩＰヘッダのチェックサムとＵＤＰヘッダのチェックサムも再計算される。
この例では、ＩＰヘッダのチェックサムが0x10から0x20に、UDPヘッダのチェックサムが0x100から0x200に変更されたとする。さらに、ＮＡＴルータ４０２では、ＴＴＬを２から１に書き換える。
このように変更されたパケットは、つぎにルータ４０３に届けられる。ルータ４０３では、ＴＴＬを１から０に書き換えるが、ＴＴＬが０になったので、このパケットを破棄する。そして、ルータ４０３はパケットの送信元であるＮＡＴルータ４０２にICMP Time Exceededメッセージを送り返す。
このICMP Time Exceededメッセージは、図３０（c）のようなパケットして送られるが、そのデータ部には先程ルータ４０３が受信したパケットがそのまま付加される。
ＮＡＴルータ４０２は、このICMP Time Exceededメッセージを受信すると、ＰＣ４０１に転送するために、そのＩＰヘッダの宛先ＩＰアドレスを２００．１０．１．１から１９２．１６８．０．２に変更する。また、この変更に伴い、ＩＰヘッダのチェックサムも再計算し、0x30から0x40に変更している。
また、ＮＡＴルータ４０２では、ICMP Time Exceededメッセージのデータ部も変更している。具体的には、送信元ＩＰアドレスと２００．２０．１．１から１９２．１６８．０．２に変更する。このようにＩＣＭＰヘッダのデータ部も変更してやることにより、このICMP Time ExceededメッセージをあくまでＰＣ４０１へのICMP Time Exceededメッセージであるかのようにできる。また、この変更に伴い、図３０（d）に示されるように、ＩＣＭＰヘッダのチェックサムのうち、ＩＰチェックサムを再計算し、0x20から0x50に変更している。
ただし、ＮＡＴルータ４０２では、ＵＤＰチェックサムまでは変更しないため、ＵＤＰチェックサムは誤った値となっている。
ＰＣ４０１は、このＩＣＭＰパケットをＮＡＴルータ４０２から受け取ると、第３の実施の形態で述べた処理により、ＩＣＭＰヘッダのデータ部が解析部２９０６に転送される。
解析部２９０６は、パケット受信部２９０４からＩＣＭＰヘッダのデータ部を受け取ると、そのチェックサムの状態から、ネットワークでヘッダ変換が行われたのかどうかを検出する。
ここで、データ部のＩＰチェックサムは正しい値となっているので、ＩＰチェックサムから、ＮＡＴルータ４０２でＩＰアドレスの変換が行われたかどうかを検出することはできない。
しかしながら、ＵＤＰチェックサムは誤った値となっているので、ＮＡＴルータ４０２において、ＩＰアドレスまたはポート番号の変換が行われたことを検出することができる。
このように、ＵＤＰチェックサムが誤っている原因がＩＰアドレスの変換にあると考えられる理由としては、ＵＤＰチェックサムが図１８のように、ＩＰアドレスを含む擬似ヘッダを加味した形で計算されるからである。
よって、解析部２９０６では、ＮＡＴルータ４０２でＩＰアドレスの変換が行われたと想定して、ＵＤＰチェックサムからＮＡＴルータ４０２のＩＰアドレスを推定する。この推定処理は、本発明の第１の実施の形態と同様であるため、説明を省略する。また、この推定処理だけでは、ＮＡＴルータ４０２のＩＰアドレスを一意に絞り込むことはできないため、第２の実施の形態のように、さらにネットワークの経路調査試験を行うことにより、推定精度を上げることが望ましい。
以上の処理により、ＮＡＴルータ４０２において、ＩＰチェックサムが正しい値に変換されてしまう場合でも、ＵＤＰチェックサムの値から、ＮＡＴルータ４０２のＩＰアドレスを推定できることが示された。
<効果>
続いて、本発明を実施するための第４の実施の形態の効果について説明する。
本発明を実施するための第４の実施の形態では、ＮＡＴルータにおいて、ＩＰチェックサムが正しい値に変換されてしまう場合でも、ＩＣＭＰパケットのＵＤＰチェックサムの値からＮＡＴルータのＩＰアドレスを推定できるため、専用サーバをインターネット上に設置することなく、ヘッダ変換を検出するという本発明の目的を達成することができる。
次に、本発明を実施するための第５の実施の形態について図面を参照して詳細に説明する。
<構成>
本発明の第１から第４の実施の形態では、ＮＡＴルータのＩＰアドレスとポート番号の推定方法について述べた。本発明の第５の実施の形態では、このようにＮＡＴルータの情報を推定するのに加えて、ＮＡＴルータの配下に繋がれているＰＣ間でパケットを送受信するのに必要な情報の推定方法について述べる。
具体的には、図４のＰＣ４０１とＰＣ４０７の間でパケットをやり取りするのに必要な情報の推定方法について述べる。
本発明の第５の実施の形態の構成を図３１に示す。本発明の第５の実施の形態では、上記の問題を解決するために、図２６の解析部２６０６、パケット送信部２６０５、およびパケット受信部２６０４で実行する処理を変更するとともに、アプリケーション部３１０７を含む。
図３１の解析部３１０６は、図２６の解析部２６０６の処理に加えて、自ノードが繋がれているＮＡＴルータのＩＰアドレスとポート番号を通信相手となるＰＣに通知する。また、解析部３１０６は、通信相手となるＰＣから、そのＰＣが繋がれているＮＡＴルータのＩＰアドレスとポート番号を受け取り、そのＩＰアドレスとポート番号宛にＵＤＰパケットを送信するようにパケット送信部３１０５に命令する。
アプリケーション部３１０７は、通信相手となるＰＣにデータを送信する場合、解析部３１０６にデータ送信要求を発行する。また、アプリケーション部３１０７は、通信相手となるＰＣからデータを受信する場合、解析部３１０６からデータを受け取る。
その他の構成は、第１から第４の実施の形態と同じであるため、説明を省略する。
<動作>
続いて、図３１を参照して本発明を実施するための第５の実施の形態の動作について詳細に説明する。
まず、解析部３１０６は、何らかのタイミングを契機に、ＵＤＰパケットまたはＴＣＰパケットを送信する。
ＵＤＰパケット、またはＴＣＰパケットを送信するタイミングとして、下記のうちのいずれか、および組み合わせが考えられる。
・ユーザインターフェースや他のアプリケーションから命令された時
・解析部のサービス起動時
・PCの電源投入時
・一定の時間間隔毎
・PCのIPアドレスの更新時
ただし、前述の送信タイミングは単なる例であることが理解されるべきである。本説明を再検討すれば、送信タイミングとして多種多様なものが存在することは、本技術分野の当業者にとって明らかであろう。
また、ＵＤＰパケット、またはＴＣＰパケットの宛先として、下記のうちのいずれか、および組み合わせが考えられる。
・ユーザインターフェースや他のアプリケーションから指定された、ＩＰアドレスとポート番号に向けて送信する
・設定ファイルなどに予め設定されているＩＰアドレスとポート番号に向けて送信する
・ランダムに選んだＩＰアドレスとポート番号に向けて送信する
ただし、前述のパケットの宛先は単なる例であることが理解されるべきである。本説明を再検討すれば、パケットの宛先として多種多様なものが存在することは、本技術分野の当業者にとって明らかであろう。
以下の動作説明では、アプリケーション部３１０７からの命令を契機に、ＵＤＰパケットを予め設定ファイルに登録されているＩＰアドレスとポート番号に向けて送信する方法を採用した場合を例に説明する。
以降の動作説明では、第３の実施の形態と同様に、ＵＤＰパケットをＰＣ４０１から送信することを想定しているが、ＵＤＰパケットの代わりにＴＣＰパケットを送信しても支障がないことは、本技術分野の当業者にとって明らかであろう。
ここで、解析部３１０６からＵＤＰベースのＩＰパケットが送信される処理は、第３の実施の形態と同じであるため、説明を省略する。
また、ＮＡＴルータ４０２でのヘッダ変換処理、およびルータ４０３でのICMP Time Exceededパケットの返信処理についても、第３の実施の形態と同じであるため、説明を省略する。
ＰＣ４０１は、ルータ４０３から送り返されたICMP Time Exceededパケットを受け取る。
このICMP Time Exceededパケットのヘッダのデータ部が解析部３１０６に渡される処理は、第３の実施の形態と同じであるため、説明を省略する。
解析部３１０６は、パケット受信部３１０４からICMP Time Exceededパケットのヘッダのデータ部を受け取ると、そのチェックサムの状態から、ネットワークでヘッダ変換が行われたのかどうかを検出する。
解析部３１０６は、ヘッダ変換の発生を検出すると、ヘッダの変更内容の推定処理を開始するが、ここで行われる推定処理は、第３の実施の形態の解析部で行われる推定処理と同じであるため、説明を省略する。
解析部３１０６では、このように推定されたＮＡＴルータ４０２のＩＰアドレスとポート番号を通信相手となるＰＣ４０７に通知する。
この通知手段としては、通信相手となるＰＣ４０７のユーザに向けてメールを送信したり、そのユーザに電話をかけたり、ＦＡＸを送信して伝える等といったことが考えられる。この通知の様子が、図３３に経路１として示されている。
次に、通信相手となるＰＣ４０７側の動作について述べる。
ＰＣ４０７では、前記通知手段により、ＰＣ４０１からＮＡＴルータ４０２のＩＰアドレスとポート番号を受け取ると、ＰＣ４０７の解析部３１０６はそのＩＰアドレスとポート番号をパケット送信部３１０５に通知し、ＵＤＰパケットの送信を依頼する（図３２のステップＳ３２０３）。
以降のパケット送信処理は、第１の実施の形態の図７〜図１０と同じであるため、説明を省略する。
このようにＰＣ４０７から送信されたデータは、図４のＮＡＴルータ４０６において、送信元ＩＰアドレスと送信元ポート番号が変換される。この例では、送信元ＩＰアドレスが１９２．１６８．１．２から２００．３０．１．１へ、送信元ポート番号が６５０００から６５００１に変更されたとする。
このように変更されたパケットは、通信相手側のＮＡＴルータ４０２に届けられる。
ＮＡＴルータ４０２の動作モードが非特許文献１に示されるような「Full Cone NAT」と呼ばれるタイプであれば、このように届けられたパケットは、ＮＡＴルータ４０２で破棄されることなく、ＮＡＴルータ４０２からＰＣ４０１に転送される。
ＰＣ４０１は、このパケットをＮＡＴルータ４０２から受け取ると、このパケットをＭＡＣ部３１０１からパケット受信部３１０４に吸い上げる。
解析部３１０６は、パケット受信部３１０４からパケットを受け取ると、そのヘッダから通信相手のＮＡＴルータ４０６のＩＰアドレスとポート番号を取得できる。
以上の処理により、ＮＡＴルータに繋がれたＰＣ４０１とＰＣ４０７の間でパケットをやり取りするために必要な情報を推定することができた。
この後、ＰＣ４０１とＰＣ４０７のアプリケーション間で通信する際には、アプリケーション部３１０７は解析部３１０６を介してデータをやり取りする。例えば、解析部３１０６は、アプリケーション部３１０７からデータを受け取ると、通信相手となるＮＡＴルータのＩＰアドレスとポート番号をパケット送信部３１０５に通知し、ＵＤＰパケットの送信を依頼する。以降の送信処理は、第１の実施の形態の図７〜図１０と同じであるため、説明を省略する。
一方、ＰＣ４０７では、ＰＣ４０１から送信されたパケットを、第１の実施の形態の図１２〜図１４の処理により、ＭＡＣ部３１０１から解析部３１０６に吸い上げる。この後、解析部３１０６からからアプリケーション部３１０７にデータを転送する。
以上、NATルータの動作モードが「Full Cone NAT」と呼ばれるタイプの場合の動作について説明した。
一方、ＮＡＴルータの動作モードが非特許文献１に示されるような「Restricted Cone NAT」、または「Port Restricted Cone NAT」と呼ばれるタイプの場合、図３２のステップＳ３２０３で、ＰＣ４０７からＮＡＴルータ４０２宛に送信されたパケットはＮＡＴルータ４０２において破棄されてしまう。
このように破棄されてしまう理由は、これらのＮＡＴルータでは、非特許文献１に示されるように、一度パケットを送信したことのあるＩＰアドレス/ポート番号からのパケットしか受け付けないためである。
本発明の第５の実施の形態では、ＮＡＴルータがこのようなタイプの場合でも、パケットをやり取りするのに必要な情報を推定するために、以下のような処理を行う。
まず、前述の通知手段により、ＰＣ４０７は、ＰＣ４０１からＮＡＴルータ４０２のＩＰアドレスとポート番号を受け取ると、ＮＡＴルータ４０６のＩＰアドレスとポート番号を取得することを試みる。ＮＡＴルータ４０６の情報の取得方法としては、第３の実施の形態と同様に、TTL値を小さくしたUDPパケットを送信する。ただし、ここで送信するUDPパケットの宛先としては、ＰＣ４０１から通知されたＮＡＴルータ４０２のＩＰアドレスとポート番号を指定するものとする。
ここで行われるパケット送信処理は、第３の実施の形態の図２７〜図２８と同じであるため、説明を省略する。
このようにＰＣ４０７から送信されたパケットは、まず、図４のＮＡＴルータ４０７において、送信元ＩＰアドレスと送信元ポート番号が変換される。変換処理の内容は、図１１と同じであるため、説明を省略する。
このように変更されたパケットは、つぎにルータ４１１に届けられる。ルータ４１１では、ＴＴＬを１から０に書き換えるが、ＴＴＬが０になったので、このパケットを破棄する。そして、ルータ４１１はパケットの送信元であるＮＡＴルータ４０６にICMP Time Exceededメッセージを送り返す。
ＰＣ４０７は、このICMP Time ExceededメッセージをＮＡＴルータ４０６から受け取ると、第３の実施の形態と同様にして、そのチェックサムからNATルータ４０６のＩＰアドレスとポート番号を取得することができる。
ここで行われるパケット受信処理とヘッダの変更内容の推定処理は、第３の実施の形態と同じであるため、説明を省略する。
ＰＣ４０７の解析部３１０６では、このように推定されたＮＡＴルータ４０６のＩＰアドレスとポート番号を通信相手となるＰＣ４０１に通知する。
この通知手段としては、通信相手のＰＣ４０１のユーザに向けてメールを送信したり、そのユーザに電話をかけたり、ＦＡＸを送信して伝える等といったことが考えられる。この通知の様子が、図３３に経路２として示されている。
ＰＣ４０１では、前記通知手段により、ＰＣ４０７からＮＡＴルータ４０６のＩＰアドレスとポート番号を受け取ると、ＰＣ４０１の解析部３１０６はそのＩＰアドレスとポート番号をパケット送信部３１０５に通知し、ＵＤＰパケットを送信を依頼する（図３２のステップＳ３２０３）。
ここで行われるパケット送信処理は、第１の実施の形態の図７〜図１０と同じであるため、説明を省略する。
このように送信されたデータは、図４のＮＡＴルータ４０２において、送信元ＩＰアドレスと送信元ポート番号が変換された後、通信相手側のＮＡＴルータ４０６に届けられる。
ＮＡＴルータ４０６は、先程の通信処理において、このパケットの送信元であるＮＡＴルータ４０２にパケットを送信したことがあるので、パケットを破棄することなく、ＰＣ４０７に転送する。
ＰＣ４０７は、このパケットをＮＡＴルータ４０２から受け取ると、このパケットをＭＡＣ部３１０１から解析部３１０６に吸い上げるが、この処理は第１の実施の形態の図１２〜図１４と同じであるため、説明を省略する。
解析部３１０６は、パケット受信部３１０４からパケットを受け取ると、そのヘッダから通信相手のＮＡＴルータ４０６のＩＰアドレスとポート番号を取得できる。
以上の処理により、ＮＡＴルータに繋がれたＰＣ４０１とＰＣ４０７の間でパケットをやり取りするために必要な情報を推定することができた。
この後、ＰＣ４０１とＰＣ４０７のアプリケーション間で通信する際には、アプリケーション部３１０７は解析部３１０６を介してデータをやり取りする。
以上のように、ＰＣがＮＡＴルータに繋がれている場合でも、ＩＣＭＰパケットのチェックサムから推定されたＮＡＴルータのＩＰアドレスとポート番号を通信相手に通知し合うことにより、ＰＣ間でパケットをやり取りするのに必要な情報を推定できることが示された。
以上、NATルータの動作モードが「Restricted Cone NAT」、または「Port Restricted Cone NAT」と呼ばれるタイプの場合の動作について説明した。
一方、ＮＡＴルータの動作モードが非特許文献１に示されるような「Symmetric NAT」と呼ばれるタイプの場合、上述のような処理を行っても、PC４０１からNATルータ４０６に送信されたパケットはNATルータ４０６において破棄されてしまう。
破棄されてしまう理由は、このようなＮＡＴルータでは、非特許文献１に示されるように、NATルータにおける送信元ポート番号が宛先IPアドレス／宛先ポート番号に応じて変化してしまうためである。例えば、図３３の経路１で、PC４０１からPC４０７にNATルータ402のPC４０５との通信用ポート番号を通知しているが、PC４０７では受け取ったポート番号を宛先としたパケットを送信する。また、PC４０７は、図３３の経路２において、このときの送信パケットにNATルータ４０６から割り当てられる送信元ポート番号をPC４０１に通知する。PC４０１では、受け取ったポート番号を宛先としたパケットを送信する。ここで注意すべきことは、このときPC４０１から送信されたパケットの送信元ポート番号には、「Symmetric NAT」の特性から、PC４０５との通信用ポート番号と異なる値が付与されていることである。このようなパケットをNATルータ４０６が受信すると、その送信元ポート番号とのマッピングテーブルはまだ作成されていないので、パケットを破棄してしまう。以上のことから、上述の方法では「Symmetric NAT」の場合には対応できない。
本発明の第５の実施の形態では、ＮＡＴルータがこのような「Symmetric NAT」の場合でも、パケットをやり取りするのに必要な情報を推定するために、以下のような処理を行う。
まず、前述の通知手段により、ＰＣ４０７は、ＰＣ４０１からＮＡＴルータ４０２のＩＰアドレスとポート番号を受け取ると、ＮＡＴルータ４０６のＩＰアドレスとNATルータ４０２との通信用ポート番号を推定する。
ここで行われる推定処理は、NATルータが「Restricted Cone NAT」、または「Port Restricted Cone NAT」の場合の動作と同じであり、既に説明しているため、説明を省略する。
ただし、このとき推定できるポート番号は、あくまで、NATルータ４０６において、NATルータ４０２のPC４０５との通信用ポート番号に対して割り当てられたポート番号である。
PC４０７では、このようにNATルータ４０６のIPアドレスとNATルータ４０２との通信用ポート番号を取得すると、次に、NATルータ４０６のポート番号の割り当て処理の規則性を調査する。非特許文献１には、「Symmetric NAT」の規則性について示されている。非特許文献１によると、「Symmetric NAT」の特性を持つNATルータは、その送信元ポート番号として、１ずつ増えるような値を割り当てることが多い。
本発明の第5の実施の形態では、この規則性を調査するために、PC４０７からグローバルIPアドレスの端末を宛先としたパケットを複数送信するとともに、第３の実施の形態に従って、NATルータ４０６において、その宛先毎に割り当てられた送信元ポート番号を推定する。以上のように推定された送信元ポート番号を元にして、PC４０７は、「Symmetric NAT」の規則性を把握し、NATルータ４０２との通信用に設定される「真」のポート番号を推定する。
PC４０７は、このように推測されたポート番号と、NATルータ４０６のIPアドレスをPC４０１に通知する。
一方、PC４０１では、このとき、PC４０７から受け取ったIPアドレスとポート番号を宛先としたパケットを送信するとともに、NATルータ４０２からそのパケットに割り当てられた送信元ポート番号を推定する。この推定処理は、第３の実施の形態と同じであるため、説明を省略する。PC４０１は、このように推定されたポート番号を、再度、PC４０７に通知する。
PC４０７は、このようにPC４０１から受け取ったポート番号を宛先としたパケットを送信する（宛先IPアドレスもPC４０１とする）。ここで、NATルータ４０６では、パケットの送信元ポート番号を、前述の「Symmetric NAT」の規則性から推定されているポート番号に変換するものとする。このように変換されたパケットが、NATルータ４０２に到達すると、NATルータ４０２では、前述のパケット送信処理によって既にマッピングテーブルが作成されているので、このパケットを破棄せずにPC４０１に転送する。
以上のように、ＰＣがＮＡＴルータに繋がれている場合でも、ＩＣＭＰパケットのチェックサムから推定されたＮＡＴルータのＩＰアドレスとポート番号を通信相手に通知し合うことにより、ＰＣ間でパケットをやり取りするのに必要な情報を推定できることが示された。
以上、NATルータの動作モードが「Symmetric NAT」と呼ばれるタイプの場合の動作について説明した。
一方、上記の説明では、本発明の第１〜第４の実施の形態の方法を用いることにより、NATルータのＩＰアドレスやポート番号を一意に絞り込めることを前提としていた。これに対して、上記の方法で、ＩＰアドレスやポート番号を一意に絞り込むことができず、複数の候補が残っている場合には、間違った通信相手から接続要求を受けてしまう可能性がある。
このような問題を回避するために、第５の実施の形態では、パケットの中にメールアドレスや識別子など、通信相手を特定する情報を付加しておくことにより、所望の相手以外からの接続要求を防止できる。
<効果>
続いて、本発明を実施するための第５の実施の形態の効果について説明する。
本発明を実施するための第５の実施の形態では、通信相手となるＰＣがＮＡＴルータの配下に設置されている場合でも、ＩＣＭＰパケットのチェックサムからＮＡＴルータのＩＰアドレスとポート番号を推定するとともに、お互いにその情報を通知しあうことにより、専用サーバをインターネット上に設置することなく、ＰＣ間でパケットをやり取りするのに必要な情報を推定でき、本発明の目的を達成することができる。
次に、本発明を実施するための第６の実施の形態について図面を参照して詳細に説明する。
<構成>
本発明の第１から第５の実施の形態では、ＮＡＴルータのＩＰアドレスとポート番号の推定方法について述べたが、本発明の第６の実施の形態では、ToSフィールドの変化を推定する方法について述べる。
図３４を参照すると、本発明の第６の実施の形態は、インターネットのようなネットワーク３４０４と、ユーザが操作するＰＣ３４０１と、インターネット上に設置されている任意のＰＣ３４０５と、パケットの経路制御を行うルータ３４０３とを含む。また、ネットワーク３４０４は、パケットの経路制御を行うルータ３４０８〜３４１１を含む。
ここで、ルータ３４０３では、特定のフローを優先的に取り扱うために、パケットのToSフィールドが変更されるものとする。
ＰＣ３４０１の内部構成を図３５に示す。
図３５に示されるように、ＰＣ３４０１の内部構成は、図２６のＰＣ４０１の内部構成と同じである。ただし、本発明の第６の実施の形態では、上記の問題を解決するために、図２６の解析部２６０６で実行する処理を変更している。
本発明の第５の実施の形態の解析部３５０６では、図２６の解析部２６０６の処理に加えて、パケット受信部２６０４から渡されるICMP Time Exceededメッセージから、ネットワーク内で行われたToSフィールドの変化を検出する処理を行う。
他の処理は、第３の実施の形態の図２６と同じであるため、説明を省略する。
<動作>
ＰＣ３４０１から、TTL値の小さなパケットを送信する処理については、第３の実施の形態と同じであるため、説明を省略する（図３６(a)）。
以降の動作説明では、第３の実施の形態と同様に、ＵＤＰパケットをＰＣ３４０１から送信することを想定しているが、ＵＤＰパケットの代わりにＴＣＰパケットを送信しても支障がないことは、本技術分野の当業者にとって明らかであろう。
ＰＣ３４０１から送信されたデータは、まず、図３４のルータ３４０３において、ＩＰヘッダのToSフィールドが変更される。この例では、ToSフィールドが0x00から0xc0に変更されたとする。また、これらの変更に伴い、ＩＰヘッダのチェックサムも再計算される。この例では、ＩＰヘッダのチェックサムが0x10から0x20に変更されたとする(図３６(b))。さらに、ルータ３４０３はＴＴＬを２から１に書き換える。
このように変更されたパケットは、つぎにルータ３４０８に届けられる。ルータ３４０８では、ＴＴＬを１から０に書き換えるが、ＴＴＬが０になったので、このパケットを破棄する。そして、ルータ３４０８はパケットの送信元であるＰＣ３４０１にICMP Time Exceededメッセージを送り返す。このICMP Time Exceededメッセージは、図３６（c）のようなパケットして送られるが、そのデータ部には先程ルータ３４０８が受信したパケットがそのまま付加される。
ＰＣ３４０１は、このＩＣＭＰパケットをルータ３４０８から受け取ると、第３の実施の形態と同じように、ＭＡＣ部３５０１から解析部３５０６まで吸い上げられる。
解析部３５０６は、パケット受信部３５０４からICMP Time Exceededメッセージのヘッダのデータ部を受け取ると、そのデータの状態から、ネットワークでToSフィールドが変換されかどうか検出できる。
具体的には、ICMP Time ExceededメッセージのToSフィールドをチェックし、ToSフィールドが０となっていない場合にはToSフィールドの書き換えが発生したと判断することにより、ネットワーク内における優先制御機能の稼動状況を検出できる（図３６(c)）。
以上の処理により、ICMP Time Exceededメッセージを利用することにより、ネットワーク内におけるToSフィールドの変化を推定できることが示された。
<効果>
続いて、本発明を実施するための第６の実施の形態の効果について説明する。
本発明を実施するための第６の実施の形態では、ルータから送り返されてくるICMPTime Exceededメッセージの情報を元にして、ネットワーク内におけるToSフィールドの変化を推定することにより、専用サーバをインターネット上に設置することなく、ネットワーク内で優先制御機能が働いていることを検出することができ、本発明の目的を達成することができる。
次に、本発明を実施するための第７の実施の形態について図面を参照して詳細に説明する。
<構成>
本発明の第６の実施の形態では、ToSフィールドの推定方法について述べたが、本発明の第７の実施の形態では、フラグメントが発生したかどうかを推定する方法について述べる。
図３７を参照すると、本発明の第７の実施の形態は、インターネットのようなネットワーク３７０４と、ユーザが操作するＰＣ３７０１と、インターネット上に設置されている任意のＰＣ３７０５と、パケットの経路制御を行うルータ３７０３とを含む。また、ネットワーク３７０４は、パケットの経路制御を行うルータ３７０８〜３７１１を含む。
ここで、ルータ３７０８では、データサイズが回線のＭＴＵを越えないように、パケットのフラグメントが行われるものとする。
ＰＣ３７０１の内部構成を図３８に示す。
図３８に示されるように、ＰＣ３７０１の内部構成は、図３５に示される本発明の第６の実施の形態のＰＣ３４０１の内部構成と同じである。ただし、本発明の第７の実施の形態では、上記の問題を解決するために、図３５の解析部３５０６で実行する処理を変更している。
本発明の第７の実施の形態の解析部３８０６では、図３５の解析部３５０６の処理に加えて、パケット受信部３８０４から渡されるICMP Time Exceededメッセージから、ネットワーク内で行われたフラグメントの発生を検出する。
他の内部構成は、第６の実施の形態の図３５と同じであるため、説明を省略する。
<動作>
ＰＣ３７０１から、TTL値の小さなパケットを送信する処理については、第６の実施の形態と同じであるため、説明を省略する（図３９(a)）。
以降の動作説明では、第３の実施の形態と同様に、ＵＤＰパケットをＰＣ３７０１から送信することを想定しているが、ＵＤＰパケットの代わりにＴＣＰパケットを送信しても支障がないことは、本技術分野の当業者にとって明らかであろう。
ＰＣ３７０１から送信されたパケットサイズが１３００byteであると仮定する（図３９(a)）。
ＰＣ３７０１から送信されたデータは、まず、図３７のルータ３７０８において、ＩＰパケットのフラグメントが行われる。この例では、パケットサイズが８００byteと５００byteの２つのパケットに分割されるものとする。フラグメントを行ったルータ３７０８は、パケットのフラグフィールドの第３ビットを１に設定するとともに、最終パケットのフラグフィールドに０を設定する。また、フラグメントオフセットフィールドにはデータのオフセット値を設定する。
また、これらの変更に伴い、ＩＰヘッダのチェックサムも再計算される(図３９(b)、図３９(c))。さらに、ルータ３７０８では、ＴＴＬを２から１に書き換える。
このように変更されたパケットは、つぎにルータ３７０９に届けられる。ルータ３７０９では、ＴＴＬを１から０に書き換えるが、ＴＴＬが０になったので、このパケットを破棄する。そして、ルータ３７０９はパケットの送信元であるＰＣ３７０１にICMP Time Exceededメッセージを送り返す。このICMP Time Exceededメッセージは、図３９（d）、図３９(e)ののようなパケットして送られるが、そのデータ部には先程ルータ３７０９が受信したパケットがそのまま付加される。
ＰＣ３７０１は、このＩＣＭＰパケットをルータ３７０９から受け取ると、第６の実施の形態と同じように、ＭＡＣ部３８０１から解析部３８０６まで吸い上げられる。
解析部３８０６は、パケット受信部３８０４からICMP Time Exceededメッセージのヘッダのデータ部を受け取ると、そのデータの状態から、ネットワークでフラグメントが発生したかどうか検出できる。
具体的には、ICMP Time Exceededメッセージのフラグメントフィールドとオフセットフィールドをチェックし、両方のフィールドが０となっていない場合にはフラグメントが発生したものと判断することにより、ネットワーク内におけるフラグメントの発生状況を検出できる（図３９(d)、図３９(e)）。
以上の処理により、ICMP Time Exceededメッセージを利用することにより、ネットワーク内におけるフラグメントの発生を検出できることが示された。
<効果>
続いて、本発明を実施するための第７の実施の形態の効果について説明する。
本発明を実施するための第７の実施の形態では、ルータから送り返されてくるICMPTime Exceededメッセージの情報を元にして、ネットワーク内におけるフラグメントの発生状況を推定することにより、専用サーバをインターネット上に設置することなく、ネットワーク内でフラグメントが発生したかどうかを検出することができ、本発明の目的を達成することができる。
続いて、本発明を実施するための第８の実施の形態について図面を参照して詳細に説明する。
<構成>
本発明の第５の実施の形態では、PC間でUDPパケットをやり取りするために必要な情報を把握する方法について述べたが、本発明の第８の実施の形態では、PC間でTCPパケットをやり取りするために必要な情報を把握するための方法について述べる。
具体的には、図４のPC４０１とPC４０７との間でTCPパケットをやり取りするのに必要な情報の推定方法について述べる。
本発明の第８の実施の形態の構成を図４０に示す。本発明の第８の実施の形態では、上記の問題を解決するために、図３１の解析部３１０６、パケット送信部３１０５、およびパケット受信部３１０４で実行する処理を変更するとともに、TCP部４００８を含む。
図４０の解析部４００６は、図３１の解析部３１０６の処理に加えて、TCPパケットのシーケンス番号を通信相手に通知する。また、相手からＮＡＴルータのＩＰアドレスとポート番号、およびシーケンス番号を受け取り、これらの情報を元にしたTCPパケットを送信するようにパケット送信部４１０５に命令する。
TCP部４００８は、パケット送信部から渡されたデータにTCPヘッダを追加した後、IP部４００２に渡す。また、IP部４００２から渡されたデータからTCPヘッダを外した後、パケット受信部４００４に渡す。
その他の構成は、第５の実施の形態と同じであるため、説明を省略する。
<動作>
続いて、図４０を参照して本発明を実施するための第８の実施の形態の動作について詳細に説明する。
第８の実施の形態では、まず、NATルータのIPアドレスとUDPパケット用のポート番号を推定するとともに、それらの情報を通信相手に通知することを行うが、これらの処理は第５の実施の形態とまったく同じであるため、説明を省略する。よって、以下の説明では、図４のPC４０１とPC４０７の間において、通信相手のNATルータのIPアドレスとUDPパケット用のポート番号を既に取得していることを前提にして話を進める。
次に、PC４０１とPC４０７の解析部４００６は、TTL値を小さく設定したTCPのSYNパケットを通信相手のNATルータに向けて送信するようにパケット送信部４００５に命令する。尚、このTTL値はネットワークの輻輳を考慮すると小さい値の方が良いが、PC407に届かない値にすれば良い。
パケット送信部４００５は、解析部４００６からSYNパケットの送信命令を受け取ると、指定された宛先に向けてSYNパケットの送信処理を行うために、データをTCP部４００８に渡す。
TCP部４００８は、このデータを受け取ると、宛先ポート番号が既に取得しているNATルータのポート番号となっているTCPヘッダを付与して、SYNパケットを生成する。このように、PC４０１とPC４０７の双方からSYNパケットを送信するが、この際、SYNパケットに付与されるTCPシーケンス番号を記録しておく。ここで、PC４０１が送信したSYNパケットのTCPシーケンス番号をXとし、PC４０７が送信したSYNパケットのTCPシーケンス番号をYとする。TCP部４００８は、このSYNパケットをIP部４００２に渡す。
IP部４００２は、TCP部４００８からSYNパケットを受け取ると、宛先IPアドレスがNATルータのIPアドレスとなっているIPヘッダを付与し、MAC部４００１に渡す。
MAC部４００１は、IP部４００２からパケットを受け取ると、MACヘッダを付与し、伝送路に送信する。
ただし、このように送信されたSYNパケットは、TTL値が小さいので、途中経路のルータにおいてパケットが破棄される。
次に、PC４０１とPC４０７の解析部４００６は、先ほど記録したTCPシーケンス番号を通信相手にメールで通知する。
PC４０１とPC４０７の解析部４００６は、通信相手からTCPシーケンス番号をメールで受け取ると、このTCPシーケンス番号を考慮したSYN＋ACKパケットを送信するように、パケット送信部４００５に命令する。
パケット送信部４００５は、解析部４００６からSYN＋ACKパケットの送信命令を受け取ると、指定された宛先に向けてSYN＋ACKパケットの送信処理を行うために、データをTCP部４００８に渡す。
TCP部４００８は、このデータを受け取ると、宛先ポート番号がNATルータのポート番号、TCPシーケンス番号とTCP確認応答番号に適切な値が設定されているTCPヘッダを付与して、SYN＋ACKパケットを生成する。ここで、PC４０１から送信するSYN+ACKパケットについて考えると、その宛先ポート番号にNATルータ４０６のポート番号、TCPシーケンス番号にX、TCP確認応答番号にY+1が設定される。一方、PC４０７から送信するSYN+ACKパケットについて考えると、その宛先ポート番号にNATルータ４０２のポート番号、TCPシーケンス番号にY、TCP確認応答番号にX+1が設定される。PC４０１とPC４０７のTCP部４００８は、このようなSYN+ACKパケットをIP部４００２に渡す。
IP部４００２は、TCP部４００８からSYN＋ACKパケットを受け取ると、宛先IPアドレスが通信相手のNATルータのIPアドレスとなっているIPヘッダを付与し、MAC部４００１に渡す。
MAC部４００１は、IP部４００２からパケットを受け取ると、MACヘッダを付与し、伝送路に送信する。
ここで注目すべき点として、SYN+ACKパケットを送信する前にあらかじめSYNパケットを送信しておくことにより、各NATルータにマッピングテーブルが作成されていることが挙げられる。これにより、PC４０１およびPC４０７から送信されたSYN+ACKパケットは、通信相手のNATルータで破棄されることなく、通信相手まで届けられる。
ここで、注意すべき点として、NATルータの種類によっては、NATルータがUDPパケット用に開けるポート番号とTCPパケット用に開けるポート番号が異なる可能性が挙げられる。たとえば、UDPパケット用のポート番号とTCPパケット用のポート番号に１程度のズレが生じることがある。このような場合に、上述のように、SYNパケットやSYN＋ACKパケットの宛先TCPポート番号にUDPパケット用のポート番号を設定していると、マッピングテーブルのポート番号と一致しないため、SYN＋ACKパケットがNATルータで破棄されてしまう。このような事態にも対応できるように、SYNパケットやSYN＋ACKパケットの宛先TCPポート番号にUDPパケット用のポート番号に１を足した値を設定するように変更することも可能である。
ただし、前述の宛先ポート番号の設定方法例は単なる例であることが理解されるべきである。本説明を再検討すれば、宛先ポート番号の設定方法が多種多様な方法で実施されることは、本技術分野の当業者にとって明らかであろう。
次に、PC４０１とPC４０７の解析部４００６は、通信相手からSYN+ACKパケットを受け取ると、ACKパケットを送信するように、パケット解析部４００５に命令する。
パケット送信部４００５は、解析部４００６からACKパケットの送信命令を受け取ると、指定された宛先に向けてACKパケットの送信処理を行うために、データをTCP部４００８に渡す。
TCP部４００８は、このデータを受け取ると、宛先ポート番号がNATルータのポート番号、TCP確認応答番号に適切な値が設定されているTCPヘッダを付与して、ACKパケットを生成する。ここで、PC４０１から送信するACKパケットについて考えると、その宛先ポート番号にNATルータ４０６のポート番号、TCP確認応答番号にY+1が設定される。一方、PC４０７から送信するACKパケットについて考えると、その宛先ポート番号にNATルータ４０２のポート番号、TCP確認応答番号にX+1が設定される。PC４０１とPC４０７のTCP部４００８は、このようなACKパケットをIP部４００２に渡す。
IP部４００２は、TCP部４００８からACKパケットを受け取ると、宛先IPアドレスが通信相手のNATルータのIPアドレスとなっているIPヘッダを付与し、MAC部４００１に渡す。
MAC部４００１は、IP部４００２からパケットを受け取ると、MACヘッダを付与し、伝送路に送信する。
これらのACKパケットは、通信相手のNATルータで破棄されることなく、通信相手まで届けられる。以上の処理により、TCPセッションの確立に必要な3 way handshake処理が完了した。
<効果>
続いて、本発明を実施するための第８の実施の形態の効果について説明する。
本発明を実施するための第８の実施の形態では、通信相手となるPCがNATルータの配下に設置されている場合でも、専用サーバをインターネット上に設置することなく、TCPパケットをやり取りするのに必要な情報を推定でき、本発明の目的を達成することができる。
ネットワークを説明するための図である。 パケットの各ヘッダを説明するための図である。 従来技術のネットワーク構成図である。 本発明の第１の実施の形態を説明するためのネットワーク構成図である。 本発明の第１の実施の形態の端末のブロック図である。 本発明の第１の実施の形態における解析部の送信動作を説明するためのフロー図である。 本発明の第１の実施の形態におけるパケット送信部の送信動作を説明するためのフロー図である。 本発明の第１の実施の形態におけるＵＤＰ部の送信動作を説明するためのフロー図である。 本発明の第１の実施の形態におけるＩＰ部の送信動作を説明するためのフロー図である。 本発明の第１の実施の形態におけるＭＡＣ部の送信動作を説明するためのフロー図である。 本発明の第１の実施の形態におけるパケットヘッダの変更を説明するための図である。 本発明の第１の実施の形態におけるＭＡＣ部の受信動作を説明するためのフロー図である。 本発明の第１の実施の形態におけるＩＰ部の受信動作を説明するためのフロー図である。 本発明の第１の実施の形態におけるパケット受信部の受信動作を説明するためのフロー図である。 本発明の第１の実施の形態における解析部の受信動作を説明するためのフロー図である。 本発明の第１の実施の形態における解析部のＩＰ推定処理の動作を説明するためのフロー図である。 本発明の第１の実施の形態における解析部のポート推定処理の動作を説明するためのフロー図である。 ＵＤＰの擬似ヘッダを説明するための動作である。 本発明の第２の実施の形態の端末のブロック図である。 本発明の第２の実施の形態における解析部の送信動作を説明するためのフロー図である。 本発明の第２の実施の形態におけるパケット送信部の送信動作を説明するためのフロー図である。 本発明の第２の実施の形態におけるＭＡＣ部の送信動作を説明するためのフロー図である。 本発明の第２の実施の形態におけるＭＡＣ部の受信動作を説明するためのフロー図である。 本発明の第２の実施の形態におけるパケット受信部の受信動作を説明するためのフロー図である。 本発明の第２の実施の形態における解析部の受信動作を説明するためのフロー図である。 本発明の第３の実施の形態の端末のブロック図である。 本発明の第３の実施の形態における解析部の送信動作を説明するためのフロー図である。 本発明の第３の実施の形態におけるパケット送信部の送信動作を説明するためのフロー図である。 本発明の第４の実施の形態の端末のブロック図である。 本発明の第４の実施の形態におけるパケットヘッダの変更を説明するための図である。 本発明の第５の実施の形態の端末のブロック図である。 本発明の第５の実施の形態におけるパケット送信部の送信動作を説明するためのフロー図である。 本発明の第５の実施の形態におけるヘッダ変換情報の交換を説明するためのフロー図である。 本発明の第６の実施の形態のネットワーク構成を説明するための図である。 本発明の第６の実施の形態の端末のブロック図である。 本発明の第６の実施の形態におけるパケットヘッダの変更を説明するための図である。 本発明の第７の実施の形態のネットワーク構成を説明するための図である。 本発明の第７の実施の形態におけるパケットヘッダの変更を説明するための図である。 本発明の第７の実施の形態におけるパケットヘッダの変更を説明するための図である。 本発明の第８の実施の形態の端末のブロック図である。
符号の説明
４０１,４０７ ＰＣ
４０２,４０６ ＮＡＴルータ

Claims (42)

  1. ネットワーク上の装置に関する情報を推定する推定システムであって、
    送信されて来た情報収集用のパケットに応答して制御用のメッセージを返信する返信手段と、
    前記返信手段からの制御用のメッセージに基づいて、前記ネットワーク上の装置に関する情報を推定する推定手段と
    を備えたことを特徴とする推定システム。
  2. 前記返信手段は、待ち受け状態となっていないポート番号を宛先とした情報収集用のパケットに応答して、到達不能を示す制御用のメッセージを返信する手段であることを特徴とする請求項１に記載の推定システム。
  3. 前記返信手段は、前記情報収集用のパケットをヘッダのデータ部に格納した制御用のメッセージを返信する手段であることを特徴とする請求項１又は請求項２に記載の推定システム。
  4. 前記返信手段は、前記情報収集用のパケットが通過できる装置の個数を示す情報が０である情報収集用のパケットに応答して、前記情報収集用のパケットを破棄したことを示す制御用のメッセージを返信する手段であることを特徴とする請求項１から請求項３のいずれかに記載の推定システム。
  5. 前記推定手段は、品質を示す情報に基づいて推定する手段であることを特徴とする請求項１から請求項４のいずれかに記載の推定システム。
  6. 前記推定手段は、前記情報収集用のパケットが分割されたことを示す情報に基づいて推定する手段であることを特徴とする請求項１から請求項４のいずれかに記載の推定システム。
  7. 前記推定手段は、チェックサム値に基づいて推定する手段であることを特徴とする請求項１から請求項４のいずれかに記載の推定システム。
  8. 前記推定手段は、ＩＰチェックサム値に基づいて、前記制御用のメッセージのデータ部の送信元ＩＰアドレスを変更した装置に関する情報を推定し、ＵＤＰチェックサム値またはＴＣＰチェックサム値に基づいて前記制御用のメッセージのデータ部の送信元ポート番号を変更した装置に関する情報を推定する手段であることを特徴とする請求項７に記載の推定システム。
  9. 前記推定手段は、ＵＤＰチェックサム値またはＴＣＰチェックサム値に基づいて、前記制御用のメッセージのデータ部の送信元ＩＰアドレスを変更した装置に関する情報を推定する手段であることを特徴とする請求項８に記載の推定システム
  10. 前記推定手段は、ネットワークの経路調査試験の結果を加味して、推定する手段であることを特徴とする請求項７から請求項９のいずれかに記載の推定システム。
  11. 前記経路調査試験は、通過できる装置の個数を示す情報の数値が互いに異なる複数の情報収集用のパケットを送信することによって行われる調査試験であることを特徴とする請求項１０に記載の推定システム。
  12. 前記経路調査試験は、以前推定された端末までに通過する装置の個数を調査する試験であることを特徴とする請求項１０又は請求項１１に記載の推定システム。
  13. 前記経路調査試験は、プライベートIPアドレスとグローバルIPアドレスとが切り替わる位置に設置されている装置までに通過した装置の個数を調査する試験であることを特徴とする請求項１０〜請求項１２に記載の推定システム。
  14. 前記推定手段は、推定結果を前記ネットワーク上の端末に通知する手段であることを特徴とする請求項１から請求項１３にいずれかに記載の推定システム。
  15. 前記推定手段は、前記ネットワーク上の他の端末から推定結果を受け取ると、その推定結果を記憶するように構成されていることを特徴とする請求項１４に記載の推定システム。
  16. 前記推定手段は、複数の推定結果に基づいて前記ネットワーク上のコンピュータのポート番号の割り当て処理の規則性を推定する手段であることを特徴とする請求項１４又は請求項１５に記載の推定システム。
  17. 前記推定手段は、前記推定結果をメールまたは電話を用いて通信相手に通知するように構成されていることを特徴とする請求項１４から請求項１６にいずれかに記載の推定システム。
  18. 前記推定手段は、前記情報収集用のパケットが通過できる装置の個数を示す情報を前記推定結果に基づいて取得した宛先に届かない値に設定して、この宛先にSYNパケットを送信し、このSYNパケットのシーケンス番号を前記宛先に通知する手段であることを特徴とする請求項１から請求項１７のいずれかに記載の推定システム。
  19. 前記推定手段は、前記送信されたSYNパケットのシーケンス番号を受け取ると、このシーケンス番号を考慮した応答確認パケットを送信する手段であることを特徴とする請求項１８に記載の推定システム。
  20. ネットワーク上の装置に関する情報を推定するシステムであって、
    通信用のプロトコルで定められているエラーメッセージ又は制御メッセージを用いて前記ネットワーク上の装置に関する情報を推定することを特徴とする推定システム。
  21. 端末であって、
    情報収集用のパケットを送信する手段と、
    前記情報収集用のパケットに応答して送信された制御用のメッセージに基づいて、ネットワーク上の装置に関する情報を推定する推定手段と、
    を有することを特徴とする端末。
  22. ネットワーク上の装置に関する情報を推定する推定方法であって、
    送信されて来た情報収集用のパケットに応答して制御用のメッセージを返信する返信ステップと、
    受信したメッセージが前記情報収集用のパケットに応答して返信された制御用のメッセージであるかを判断する判断ステップと、
    前記判断の結果、受信したメッセージが前記情報収集用のパケットに応答して返信された制御用のメッセージであると判断された場合、この制御用のメッセージに基づいて、前記ネットワーク上の装置に関する情報を推定する推定ステップと
    を備えたことを特徴とする推定方法。
  23. 前記返信ステップは、待ち受け状態となっていないポート番号を宛先とした情報収集用のパケットに応答して、到達不能を示す制御用のメッセージを返信するステップであることを特徴とする請求項２２に記載の推定方法。
  24. 前記返信ステップは、前記情報収集用のパケットをヘッダのデータ部に格納した制御用のメッセージを返信するステップであることを特徴とする請求項２２又は請求項２３に記載の推定方法。
  25. 前記返信ステップは、前記情報収集用のパケットが通過できる装置の個数を示す情報が０である情報収集用のパケットに応答して、前記情報収集用のパケットを破棄したことを示す制御用のメッセージを返信するステップであることを特徴とする請求項２２から請求項２４のいずれかに記載の推定方法。
  26. 前記推定ステップは、品質を示す情報に基づいて推定するステップであることを特徴とする請求項２２から請求項２５のいずれかに記載の推定方法。
  27. 前記推定ステップは、前記情報収集用のパケットが分割されたことを示す情報に基づいて推定するステップであることを特徴とする請求項２２から請求項２５のいずれかに記載の推定方法。
  28. 前記推定ステップは、チェックサム値に基づいて推定するステップであることを特徴とする請求項２２から請求項２５のいずれかに記載の推定方法。
  29. 前記推定ステップは、
    ＩＰチェックサム値に基づいて、前記制御用のメッセージのデータ部の送信元ＩＰアドレスを変更した装置に関する情報を推定するステップと、
    ＵＤＰチェックサム値またはＴＣＰチェックサム値に基づいて前記制御用のメッセージのデータ部の送信元ポート番号、若しくはＩＰアドレスを変更した装置に関する情報を推定するステップと
    を有することを特徴とする請求項２８に記載の推定方法。
  30. 前記推定ステップは、
    ネットワークの経路調査試験を実行する経路調査実行ステップと、
    前記実行結果を加味して装置に関する情報を推定する詳細情報推定ステップと
    を有することを特徴とする請求項２８又は請求項２９に記載の推定方法。
  31. 前記経路調査実行ステップは、通過できる装置の個数を示す情報の数値が互いに異なる複数の情報収集用のパケットを送信するステップであることを特徴とする請求項３０に記載の推定方法。
  32. 前記経路調査実行ステップは、以前推定された装置までに通過する装置の個数を調査するステップであることを特徴とする請求項３０又は請求項３１に記載の推定方法。
  33. 前記経路調査実行ステップは、プライベートIPアドレスとグローバルIPアドレスとが切り替わる位置に設置されている装置までに通過した装置の個数を調査するステップであることを特徴とする請求項３０〜請求項３２に記載の推定方法。
  34. 前記推定ステップは、推定結果を前記ネットワーク上の端末に通知するステップを有することを特徴とする請求項２２から請求項３３のいずれかに記載の推定方法。
  35. 前記推定ステップは、前記ネットワーク上の他の端末から推定結果を受け取ると、その推定結果を記憶するステップを有することを特徴とする請求項３４に記載の推定方法。
  36. 前記推定ステップは、複数の推定結果に基づいて前記ネットワーク上のコンピュータのポート番号の割り当て処理の規則性を推定するステップであることを特徴とする請求項３４又は請求項３５に記載の推定方法。
  37. 前記推定ステップは、前記推定結果をメールまたは電話を用いて通信相手である端末に通知する推定ステップを有することを特徴とする請求項３４から請求項３６にいずれかに記載の推定方法。
  38. 前記推定ステップは、前記情報収集用のパケットが通過できる装置の個数を示す情報を前記推定結果に基づいて取得した宛先に届かない値に設定して、この宛先にSYNパケットを送信し、このSYNパケットのシーケンス番号を前記宛先に通知するステップを有することを特徴とする請求項２２から請求項３７のいずれかに記載の推定方法。
  39. 前記推定ステップは、
    前記送信されたSYNパケットのシーケンス番号を受け取る受取ステップと、
    前記受け取ったシーケンス番号を考慮した応答確認パケットを送信するステップと
    を有することを特徴とする請求項３８に記載の推定方法。
  40. ネットワーク上の装置に関する情報を推定する推定システムのプログラムであって、前記プログラムは前記システムを、
    送信されて来た情報収集用のパケットに応答して制御用のメッセージを返信する返信手段と、
    前記返信手段からの制御用のメッセージに基づいて、前記ネットワーク上の装置に関する情報を推定する推定手段と
    して機能させることを特徴とするプログラム。
  41. 端末のプログラムであって、前記プログラムは前記端末を、
    受信したメッセージが情報収集用のパケットに応答して返信された制御用のメッセージであるかを判断する判断手段と、
    前記判断の結果、受信したメッセージが前記情報収集用のパケットに応答して返信された制御用のメッセージであると判断された場合、この制御用のメッセージに基づいて、前記ネットワーク上の装置に関する情報を推定する推定手段
    として機能させることを特徴とするプログラム。
  42. ネットワーク上の装置に関する情報を推定するシステムのプログラムであって、前記プログラムは前記システムを、
    通信用のプロトコルで定められているエラーメッセージ又は制御メッセージを用いて前記ネットワーク上の装置に関する情報を推定する手段として機能させることを特徴とするプログラム。
JP2006014472A 2006-01-23 2006-01-23 推定システム、端末、推定方法、およびプログラム Pending JP2007201564A (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
JP2006014472A JP2007201564A (ja) 2006-01-23 2006-01-23 推定システム、端末、推定方法、およびプログラム
US11/625,687 US20070171836A1 (en) 2006-01-23 2007-01-22 Estimating system, terminal, estimating method, and program

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2006014472A JP2007201564A (ja) 2006-01-23 2006-01-23 推定システム、端末、推定方法、およびプログラム

Publications (1)

Publication Number Publication Date
JP2007201564A true JP2007201564A (ja) 2007-08-09

Family

ID=38285459

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2006014472A Pending JP2007201564A (ja) 2006-01-23 2006-01-23 推定システム、端末、推定方法、およびプログラム

Country Status (2)

Country Link
US (1) US20070171836A1 (ja)
JP (1) JP2007201564A (ja)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2011176383A (ja) * 2010-02-23 2011-09-08 Brother Industries Ltd 通信装置、通信システム、通信方法、及び通信プログラム。
JP2018110392A (ja) * 2017-01-02 2018-07-12 株式会社パイオリンクPiolink, Inc. Ｎａｔ装置を探知するための方法及び装置

Families Citing this family (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
TWI343732B (en) * 2007-07-09 2011-06-11 Arcadyan Technology Corp Testing method for network device
US8107388B2 (en) * 2008-04-24 2012-01-31 Avaya Inc. Route tracing program configured to detect particular network element making type of service modification
US8228861B1 (en) * 2008-09-12 2012-07-24 Nix John A Efficient handover of media communications in heterogeneous IP networks using handover procedure rules and media handover relays
WO2012138971A2 (en) * 2011-04-06 2012-10-11 Sejent Corporation Measuring instantaneous bit rate in a network connection
TW201328387A (zh) * 2011-12-20 2013-07-01 Acer Inc 網際協定分割之方法及相關無線網路系統
CN106301832B (zh) * 2015-05-21 2020-04-03 中兴通讯股份有限公司 一种处理系统日志报文的方法和装置
KR101779327B1 (ko) * 2016-11-22 2017-10-10 한국인터넷진흥원 룰 기반 핑거프린트 생성 방법 및 그 장치
CN108259261B (zh) * 2017-03-31 2020-02-11 新华三技术有限公司 路径探测方法和装置

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2002501332A (ja) * 1997-12-31 2002-01-15 アスアスホー コミュニケーションズ セキュリティ オサケユイチア ネットワーク・アドレス変換とプロトコル変換が存在する場合のパケット認証の方法
JP2005102196A (ja) * 2004-09-03 2005-04-14 Matsushita Electric Ind Co Ltd 情報処理システム
JP2005525751A (ja) * 2002-05-13 2005-08-25 ソニー・コンピュータ・エンタテインメント・アメリカ・インク ネットワークアドレス変換（ｎａｔ）によるピアツーピアネットワーク通信

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5742587A (en) * 1997-02-28 1998-04-21 Lanart Corporation Load balancing port switching hub
US5926463A (en) * 1997-10-06 1999-07-20 3Com Corporation Method and apparatus for viewing and managing a configuration of a computer network
US7937470B2 (en) * 2000-12-21 2011-05-03 Oracle International Corp. Methods of determining communications protocol latency
US20020087623A1 (en) * 2000-12-30 2002-07-04 Eatough David A. Method and apparatus for determining network topology and/or managing network related tasks
US7069438B2 (en) * 2002-08-19 2006-06-27 Sowl Associates, Inc. Establishing authenticated network connections
KR20050030288A (ko) * 2003-09-25 2005-03-30 삼성전자주식회사 Ｉｐ 패킷의 버전을 변환하는 장치 및 방법

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2002501332A (ja) * 1997-12-31 2002-01-15 アスアスホー コミュニケーションズ セキュリティ オサケユイチア ネットワーク・アドレス変換とプロトコル変換が存在する場合のパケット認証の方法
JP2005525751A (ja) * 2002-05-13 2005-08-25 ソニー・コンピュータ・エンタテインメント・アメリカ・インク ネットワークアドレス変換（ｎａｔ）によるピアツーピアネットワーク通信
JP2005102196A (ja) * 2004-09-03 2005-04-14 Matsushita Electric Ind Co Ltd 情報処理システム

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2011176383A (ja) * 2010-02-23 2011-09-08 Brother Industries Ltd 通信装置、通信システム、通信方法、及び通信プログラム。
JP2018110392A (ja) * 2017-01-02 2018-07-12 株式会社パイオリンクPiolink, Inc. Ｎａｔ装置を探知するための方法及び装置

Also Published As

Publication number Publication date
US20070171836A1 (en) 2007-07-26

Similar Documents

Publication Publication Date Title
JP2007201564A (ja) 推定システム、端末、推定方法、およびプログラム
Duke et al. A roadmap for transmission control protocol (TCP) specification documents
Eggert et al. Unicast UDP usage guidelines for application designers
Eggert et al. UDP usage guidelines
US7639625B2 (en) Tracing connection paths through transparent proxies
US8458338B2 (en) Address translation device and address translation method
EP2764662B1 (en) Test traffic interceptor in a data network
US8059641B1 (en) Encapsulation method discovery protocol for network address translation gateway traversal
US20080244086A1 (en) Identifying network path including network proxies
EP2088717A1 (en) A method of transferring fragmentation message, a system of communication and a tunnel device
US7969894B2 (en) System and method for dead gateway detection
US20080151764A1 (en) Traceroute using address request messages
Shi et al. NDNLP: A link protocol for NDN
WO2009071030A1 (fr) Procédé pour rapporter des informations de dispositif, système et dispositif pour obtenir des informations de dispositif
US20080175162A1 (en) Triggering flow analysis at intermediary devices
Barré Implementation and assessment of modern host-based multipath solutions.
US7304959B1 (en) Utility based filtering mechanism for PMTU probing
EP2896160A1 (en) Bandwidth probing messages
Simpson TCP cookie transactions (TCPCT)
WO2011103820A2 (zh) 一种网络地址转换方法及装置
JP2006203575A (ja) 通信方法
Bernardo et al. A conceptual approach against next generation security threats: Securing a high speed network protocol-UDT
Shaharuddin et al. Performance comparison of multimedia applications over IPv4 and IPv6 Dual stack technology
Eggert et al. RFC 8085: UDP Usage Guidelines
Cisco Commands: debug ip pim atm through debug ip wccp packets

Legal Events

Date Code Title Description
A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20090604

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20090617

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20090814

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20100210

A02 Decision of refusal

Free format text: JAPANESE INTERMEDIATE CODE: A02

Effective date: 20100609