第1の発明は、第1のネットワークと第2のネットワークとの間のデータ通信を中継する通信装置であって、第1のネットワーク接続用のインターフェースを有し、第1のネットワークに接続された端末からのパケットを受信する受信手段と、受信手段で受信したパケット情報を記憶する記憶手段と、受信手段で受信したパケットが未知の端末からのものである場合、以後当該端末からの複数のパケットを記憶手段に記憶させ、記憶手段に記憶されたパケット内容に基づいて当該端末のデフォルトゲートウェイIPアドレスを決定し、当該アドレス値を第1のネットワーク接続用のインターフェースに対応したIPアドレスとして設定する制御手段と、を有する構成とした。
これにより、第1のネットワークを介して通信を行う際の接続設定に関するネットワーク接続設定情報が未知の端末が接続されると、当該端末から受信するパケットに基づいて当該端末のデフォルトゲートウェイIPアドレスが得られ、端末が接続されるインターフェースに設定することができる。
第2の発明は、第1の発明において、制御手段は、未知の端末からの最初のパケットを受信後、所定の時間に受信したパケット、または所定の数受信したパケットの少なくとも一方に基づいて、当該端末のデフォルトゲートウェイIPアドレスを決定する構成とした。
これにより、未知のIPアドレスを設定された端末から送信されるパケットの受信量を適切に制御することができる。
第3の発明は、第1の発明において、制御手段が記憶手段に記憶させるパケットは、端末が通信を行う際に送信するアドレス解決を行なうためのアドレス解決パケットを含む構成とした。
これにより、デフォルトゲートウェイIPアドレスを含むパケットを受信する確率を高めることができる。
第4の発明は、第1の発明において、制御手段は、送信元が未知のパケットが示す宛先IPアドレスはデフォルトゲートウェイIPアドレスではないものとし、送信元が未知のパケットが示す宛先IPアドレス以外のIPアドレスをデフォルトゲートウェイIPアドレスであるとする構成とした。
これにより、正確に未知の静的に設定された端末のデフォルトゲートウェイIPアドレスを求めることができる。
第5の発明は、第4の発明において、第1のネットワークに接続する端末に、所定の外部アドレスへアクセスさせてデフォルトゲートウェイIPアドレスへのアドレス解決パケットを送信させる第2の制御手段を備える構成とした。
これにより、確実に未知の静的に設定された端末のデフォルトゲートウェイIPアドレスを求めることができる。
第6の発明は、第1の発明において、制御手段は、送信元が未知のパケットが示すプロトコルおよびポート番号が既知の所定のサービスである場合、プロトコルおよびポート番号が既知のパケットが示す宛先IPアドレスをデフォルトゲートウェイIPアドレスではないと推定し、プロトコルおよびポート番号が既知のパケットが示す宛先IPアドレス以外のIPアドレスを端末のデフォルトゲートウェイIPアドレスであるとする構成とした。
これにより、正確に未知の静的に設定された端末のデフォルトゲートウェイIPアドレスを求めることができる。
第7の発明は、第1の発明において、制御手段は、所定のサービスに用いられるパケットの宛先IPアドレスをデフォルトゲートウェイIPアドレスとする構成とした。
これにより、正確に未知の静的に設定された端末のデフォルトゲートウェイIPアドレスを求めることができる。
第8の発明は、第7の発明において、所定のサービスを示すプロトコルは、UPnPプロトコルである構成とした。
これにより、正確に未知の静的に設定された端末のデフォルトゲートウェイIPアドレスを求めることができる。
第9の発明は、第1の発明において、所定のサービスを示すプロトコルおよびポート番号を使用するパケットの宛先IPアドレスをデフォルトゲートウェイIPアドレスであるとする構成とした。
これにより、正確に未知の静的に設定された端末のデフォルトゲートウェイIPアドレスを求めることができる。
第10の発明は、第9の発明において、所定のサービスを示すプロトコルは、DNSプロトコルである構成とした。
これにより、正確に未知の静的に設定された端末のデフォルトゲートウェイIPアドレスを求めることができる。
第11の発明は、第1の発明において、制御手段は、複数のデフォルトゲートウェイIPアドレスが候補となった場合、他のIPアドレスと比べて特異な値を示すIPアドレスをデフォルトゲートウェイIPアドレスであるとする構成とした。
これにより、正確に未知の静的に設定された端末のデフォルトゲートウェイIPアドレスを求めることができる。
第12の発明は、第1の発明において、制御手段は、複数のデフォルトゲートウェイIPアドレスが候補となった場合、ネットワーク中継装置のアドレスとして用いられる最大値または最小値を使用しているIPアドレスをデフォルトゲートウェイIPアドレスであるとする構成とした。
これにより、正確に未知の静的に設定された端末のデフォルトゲートウェイIPアドレスを求めることができる。
第13の発明は、第1の発明において、制御手段は、複数のデフォルトゲートウェイIPアドレスが候補となった場合、候補となった全てのIPアドレスをデフォルトゲートウェイIPアドレスであるとする構成とした。
これにより、デフォルトゲートウェイIPアドレスの候補を絞ることができない場合でも、未知の端末からの通信を滞りなく受信し転送することができる。
第14の発明は、第1の発明において、制御手段により決定されたデフォルトゲートウェイIPアドレスを端末に通知する通知手段を備える構成とした。
これにより、通信装置で設定されるデフォルトゲートウェイIPアドレスの値を端末側で確認することが可能となる。
第15の発明は、第1の発明において、制御手段がデフォルトゲートウェイIPアドレスを決定するまで、第1のネットワークと第2のネットワークを、プロキシまたはルーティングによって接続するよう制御する第3の制御手段を備える構成とした。
これにより、通信装置がデフォルトゲートウェイIPアドレスを求める処理を行っている間も、IPアドレスが未知の端末は第2のネットワークおよびその先のネットワークと通信することが可能となる。
以下、本発明の各実施の形態について説明する。これらの実施の形態は関連する範囲で相互に利用可能である。
(実施の形態1)
図1は、本発明の実施の形態1における通信装置を適用したネットワークシステムの構成図である。
図1において、102は異なるネットワーク間に設けられ、両ネットワーク間のデータ通信を中継するルータ等の通信装置である。101は、通信装置102に接続される例えばインターネットなどの第2のネットワークである。103は、通信装置102に接続される例えばローカルエリアネットワーク(LAN)などの第1のネットワークである。104〜106は、第1のネットワーク103に接続してインターネット(第2のネットワーク101)へアクセスする端末である。
端末には、DHCP(Dynamic Host Configuration Protocol)を用いて自端末のネットワーク情報(ネットワーク接続に必要な設定情報)の取得を試みる端末105、端末106や、あらかじめ自端末のネットワーク情報が端末内に静的に設定されている端末104が存在している。
実施の形態1では、通信装置102が、静的にネットワーク情報が設定されている端末104から送信されるパケットに基づいて、端末104のデフォルトゲートウェイIPアドレスを推定し、推定したIPアドレスを通信装置102のネットワークインタフェースのIPアドレスとして設定する点について説明する。
図2、図3は、本発明の実施の形態1における通信装置の外観斜視図であり、図2は前面を図3は背面をそれぞれ示している。
図2に示す通信装置102はルータである。通信装置102は、筐体11を有しており、筐体11の前面には、LED(Light Emitting Diode)などの表示部12が設けられている。
筐体11の背面には、図3に示すように、DC(Direct Current)電源コネクタ13、RJ45などLAN(Local Area Network)用モジュラージャック14、及びWAN(Wide Area Network)用モジュラージャック15が設けられている。DC電源コネクタ13には、平行ケーブルなどの電力線16が接続される。モジュラージャック14、15には、Ethenetケーブル17が接続される。
なお、通信装置102の一例としてルータを示したが、通信装置102としては、ルータの機能を備えた機器(例えばパーソナルコンピューターや、冷蔵庫などの家電機器)であってもよい。
図4は、本発明の実施の形態1における通信装置のハードウェア構成図である。
図4において、通信装置102は、破線で示す筐体11内に、回路モジュール50を有している。回路モジュール50には、メインIC(Integrated Circuit)51が実装されている。
メインIC51は、CPU(Central Proccessing Unit)51aと、メインバス51fやローカルバス51gなどのバスと、バス上のデータの流れを制御するBCU(Bus Control Unit)51bと、Ethernet(登録商標)のMAC(Media Access Control)層を制御するMACブロック(EMAC)51c、51dと、PCI(Peripheral Components Interconnect)バスを制御するPCIU51eとを有している。
メインIC51内のCPU51a及びBCU51bは、メインバス51fを介して、SDRAM(Synchronous Dynamic Random Access Memory)54と、Flash ROM(Flash Read Only Memory)55とに接続されている。
また、CPU51a及びBCU51bは、ローカルバス51gを介して、メインIC51にクロックを供給する発振器52と、LEDなどの表示部12と、メインIC51に初期化信号を出力するリセットIC53とに接続されている。ローカルバス51gには、CPU51a、BCU51b、EMAC51c、51d、PCIU51e、発振器52、表示部12、リセットIC53が接続されている。
メインIC51内のMACブロック51c、51dはそれぞれ、Ethernet(登録商標)の物理層を制御するPHY(PHYsical layer)・ICであるEPHY56、57に接続されており、EPHY56、57はそれぞれ、LAN用モジュラージャック14、WAN用モジュラージャック15に接続されている。また、メインIC51は、DC−DC(Direct Current to Direct Current)変換器58を介して、DC電源コネクタ13に接続されている。DC−DC変換器58は、DC電源コネクタ13から供給されるDC電圧をメインIC51で必要なDC電圧に変換する。
図5は、本発明の実施の形態1における通信装置の機能構成図である。
図5に示すように、通信装置102において、202はLAN(第1のネットワーク103)側の端末104などからのパケットを受信するパケット受信手段、204はパケット受信手段202が受信したパケットを解析するパケット解析手段、206はパケット受信手段202が受信したパケットの数を管理するカウント手段、205はパケット受信手段202が受信したパケットが示すターゲットとなるIPアドレス(パケット情報)を記憶するターゲット記憶手段、207はパケット受信手段202が受信したパケットの情報に基づいてデフォルトゲートウェイIPアドレスを推定するアドレス推定手段、208はアドレス推定手段207が推定したIPアドレスを通信装置102のネットワークインタフェースに設定する設定手段、203は端末104などから受信したARP要求パケットに対する応答などを生成するパケット生成手段、201はパケット生成手段203が生成したパケットを送信するパケット送信手段である。
ここで、通信装置102のハードウェア構成(図4)と機能構成(図5)との関係について説明する。
図4及び図5において、パケット送信手段201は、SDRAM54上に構成されたパケットをLAN側インターフェースに送信するため、CPU51aによって、EMAC51c、EPHY56、LAN用モジュラージャック14のハードウェア経路にて送信することで実現される。
パケット受信手段202は、LAN側インターフェースより、LAN用モジュラージャック14、EPHY56、EMAC51cのハードウェア経路にて受信したパケットを、CPU51aによって、SDRAM54上に格納することで実現される。
パケット生成手段203、パケット解析手段204、ターゲット記憶手段205、カウント手段206、アドレス推定手段207、設定手段208は、いずれも、CPU51aがSDRAM54に記憶された各種の制御プログラムを読み出して実行すると共に、SDRAM54のデータ記憶領域に対してデータを記憶や読出を行う、あるいは記憶されたデータの解析などを行うことにより実現される。
なお、実施の形態1では、通信装置102としてルータという専用装置を示しているが、CPU51aにより実行される各種の制御プログラムは、汎用コンピュータ等で実行させることでも実現可能である。その際、各種の制御プログラムは、コンピュータのROMやHDD等の内蔵メモリに記憶されているものでも良いし、CDやDVD等の各種のデータを記憶するメディアに記憶されているものでも良い。
図6は、本発明の実施の形態1における通信装置の動作フローチャートであり、通信装置102が、ネットワークの設定情報が静的に設定された端末104からパケットを受信した際の処理について説明する。
図6において、通信装置102と端末104がLANケーブル等で接続された後、通信装置102のパケット受信手段202は、LAN側の端末104からのパケットを受信すると(ステップ301)、パケット解析手段204は受信したパケットの送信元IPアドレスをチェックし記憶しておく(ステップ302)。
ステップ302でチェックした送信元IPアドレスが、DHCPで配布したIPアドレスではなく、また、受信したパケットがこれまで受信したことのないIPアドレスであれば、パケット解析手段204は、このパケットの送信元である端末104を未知の端末(ネットワーク情報が未知の端末104)であると判断する。
このとき、通信装置102のCPU51aが実行する処理によって、未知の端末104よりできるだけ多くのデフォルトゲートウェイ宛のパケットを送信させるため、第2のネットワーク101に存在するような所定の外部アドレスへのアクセスを端末104に促すことを行ってもよい。なお、未知の端末とは、通信装置102が割り当てたIPアドレスを使用していない端末であり、未知の受信パケットとは当該未知の端末が発したパケットのことを示す。
ステップ302で、通信装置102が受信したパケットが未知の端末104からのパケットでなければ、このパケットに対する処理は終了する。
ステップ302で、通信装置102が受信したパケットが未知の端末104からのパケットであれば、パケット解析手段204は、受信したパケットがその端末104からの最初のパケットであるか否かを判別する(ステップ303)。
ステップ303において、送信元IPアドレスからの最初のパケットであれば、カウント手段206は、その送信元IPアドレスからのパケットのカウントを開始するため、その旨をSDRAM54に書き込む(ステップ304a)。
カウント手段206によるパケットのカウント処理は、デフォルトゲートウェイIPアドレスを推定するため、どれくらいの数のパケットを受信するかを決める閾値とするものであり、ステップ303で最初のパケットでないと判断した場合は、パケットを受信する毎にカウンタを1ずつ増やすため、SDRAM54のカウンタ情報を更新する(ステップ304b)、所定のカウント値に達するまでパケットの受信と受信したパケットの解析などを継続する。
次に、パケット解析手段204は、受信したパケットのヘッダ情報から端末104から受信したパケットがARPパケットであるか否かを判断する(ステップ305)。
ステップ305において、端末104から受信したパケットがARPパケットの場合、ARPパケット中のターゲットIPアドレス(ARPプロトコルにおいて通信装置102のハードウェアアドレスを知ろうとする端末104のIPアドレス)をターゲット記憶手段205に登録する(ステップ306)。ARPパケット中のターゲットIPアドレスをターゲット記憶手段205に登録する際、端末104からのパケットをARPパケットのターゲットIPアドレスとして受信したことを示すために、ターゲット記憶手段205のARP受信フラグをONにする。
そして、これに続くパケットを受信するために、ハードウェアアドレスが通信装置102となるARP代理応答パケットを端末104へ送信する(ステップ307)。パケット生成手段203がARP代理応答パケットを生成し、生成したARP代理応答パケットをパケット送信手段201が端末104に送信する。
この後、デフォルトゲートウェイIPアドレスを推定できるまで、通信装置102のCPU51aの処理によって、未知の端末104のパケットをプロキシまたはルーティングすることによって、第2のネットワーク101へ転送してもよい。この場合、通信装置102は、デフォルトゲートウェイIPアドレスが確定した時点で、未知の端末104からのパケットのプロキシまたはルーティングによる転送を中止する。
一方、ステップ305において、端末104から受信したパケットがARPパケットでない場合、パケット解析手段204は、端末104から受信したパケットがIPパケットであるか否かを判定する(ステップ308)。
ステップ308において、端末104から受信したパケットがIPパケットである場合、この宛先IPアドレスをターゲット記憶手段205に登録する(ステップ309)。このとき、IPアドレスが宛先IPアドレスとして使われたことを示すため、ターゲット記憶手段205の宛先IPアドレスフラグをONにする。
なお、ターゲット記憶手段205内のIPアドレスのエントリは、IPアドレスがARPのターゲットIPアドレスに設定されたパケット、IPアドレスが宛先IPアドレスに設定されたパケットの何れが先に到着した場合であっても、パケットが到着した際に作成される。そして、先に到着したパケットに対応するフラグ(ARP受信フラグまたは宛先IPアドレスフラグ)をONにする。その後、もう一方の種類のパケットが到着した場合、既にIPアドレスのエントリは存在することとなるが、フラグの状態は先に到着した種類のフラグしか操作(ON)されていないので、もう一方のフラグ操作(ON)を追加で行う。
例えば、IPアドレスが宛先IPアドレスに設定されたパケットが先に到着した場合、ターゲット記憶手段205内のIPアドレスのエントリにおいて宛先IPアドレスフラグをONにし、その後、IPアドレスがARPのターゲットIPアドレスに設定されたパケットが到着した際、ARP受信フラグをターゲット記憶手段205内のIPアドレスのエントリに設定する。
ステップ307、ステップ309の処理の後、カウント手段206は、パケット受信カウンタが所定の値に到達したか否かを確認する(ステップ310)。なお、カウンタの所定の値とは、予め決められている回数という意味である。
カウント手段206のパケット受信カウンタが所定の値に到達していない場合は、パケット受信とその後の処理(ステップ301〜310)を、パケット受信カウンタが所定の値に到達するまで繰り返す。
パケット受信カウンタが所定の値に到達すると、アドレス推定手段207は、ターゲット記憶手段205に登録した情報を用いて端末104のデフォルトゲートウェイIPアドレスの推定処理を行う(ステップ311)。
図7、図8は、本発明の実施の形態1におけるターゲット記憶手段の状態を示す図であり、ステップ311の時点におけるターゲット記憶手段205に登録されている情報を示したものである。
図7において、IPアドレス「10.2.2.1」のエントリは、端末104からのパケットをARP要求パケットのターゲットIPアドレスとして受信したことを示し(ARP受信フラグON)、宛先IPアドレスとして設定されたパケットは受信しなかったこと(宛先IPアドレスフラグOFF)を示している。
また、IPアドレス「10.2.2.12」のエントリは、端末104からのパケットをARP要求パケットのターゲットIPアドレスとして受信したことを示し、宛先IPアドレスとして設定されたパケットを受信したことを示している。
また、IPアドレス「210.1.2.3」エントリは、端末104からのパケットをARP要求パケットのターゲットIPアドレスとして受信しなかったことを示し、宛先IPアドレスとして設定されたパケットのみを受信したことを示している。
パケット解析手段204は、ARP受信フラグがONで、宛先IPアドレスフラグがOFFのエントリをデフォルトゲートウェイIPアドレスの候補として選択(推定)する。これは、端末104からデフォルトゲートウェイにIPパケットを直接送信することは稀であり、宛先IPアドレスとしてデフォルトゲートウェイがあらわれにくいことに基づくものである。
図7に示すケースでは、IPアドレス「10.2.2.1」がデフォルトゲートウェイIPアドレスの候補として選択されることとなる。
設定手段208は、パケット解析手段204が選択したIPアドレスを通信装置102のLAN側ネットワークインタフェースのIPアドレスとして設定するため、SDRAM54に記憶されているLAN用モジュラージャック14に対応するIPアドレスの情報を書き換える処理を行う(ステップ312)。そして、カウント手段206は、送信元IPアドレスからのパケットのカウントを停止する(ステップ313)。
これ以後、通信装置102は、端末104からデフォルトゲートウェイIPアドレス宛のパケットを受信して中継することができるので、デフォルトゲートウェイとしての処理のみを行えば良く、通信装置102は本来受信し中継すべきパケットのみを受信可能となる。
以上のように実施の形態1によれば、通信装置102に静的なネットワーク情報が設定された(未知の)端末104が接続し、ネットワークが開始された際、端末104のデフォルトゲートウェイIPアドレスを推定し、通信装置102のネットワークインタフェースのIPアドレスとして設定できるようになる。よって、端末104側のネットワーク設定を変更せずに、端末104は通信装置102を第1のネットワーク103上のデフォルトゲートウェイとして利用することがでる。そして、通信装置102は、端末104からの不要なパケットを受信することなく効率良くパケットの転送を行うことができる。
なお、実施の形態1では、パケット解析の開始条件をパケットのカウント数に基づいて設定することとしたが、パケット解析の開始条件はこの設定条件に限定されるものではない。すなわち、端末104から最初のパケットを受信してからの経過時間に基づいてパケット解析の開始条件を設定しても良いし、パケット数と経過時間の組み合わせに基づいてパケット解析の開始条件を設定してもよい。
また、実施の形態1において、デフォルトゲートウェイIPアドレスを、ARP受信フラグがONで宛先IPアドレスフラグがOFFのエントリという条件で推定した結果、候補となるIPアドレスが複数となった場合(例えば、図8ケース)には、ゲートウェイとしてよく用いられる特異なIPアドレス(例えば、IPアドレスの最下位バイトが最小値である1、または最大値である254であるもの)を選択する条件を追加してデフォルトゲートウェイIPアドレスを推定し、デフォルトゲートウェイIPアドレスの候補を絞ることとしても良い。この場合も、デフォルトゲートウェイIPアドレスを、ARP受信フラグがONで宛先IPアドレスフラグがOFFのエントリという条件で推定した場合(図7に示すケース)と同様の効果が得られる。
また、複数のデフォルトゲートウェイIPアドレスの候補が出た場合、設定手段208により全ての候補を通信装置102のネットワークインタフェースに設定することによっても、1つのデフォルトゲートウェイIPアドレスの候補を通信装置102のネットワークインタフェースに設定する場合と同様の効果が得られる。
さらに、通信装置102によって認識されたデフォルトゲートウェイIPアドレスを通信装置102に設けられたWEBサーバ機能によって、WEB画面などを通じてユーザ(端末104)に通知し、通信装置102に認識され設定されたデフォルトゲートウェイIPアドレスを端末104のユーザが確認できるようにしても良い。
(実施の形態2)
以下、実施の形態2について説明する。
通信装置102の装置構成については実施の形態1と同様である。
図9は、本発明の実施の形態2における通信装置の動作フローチャートである。
図9において、ステップ501〜507は、図6に示すステップ301〜307とそれぞれ同様であり、説明を省略する。
ステップ505において、端末104から受信したパケットがARPパケットでない場合(ステップ505、No)、パケット解析手段204は、端末104から受信したパケットがTCPパケットやUDPパケットであるか否かを判定する(ステップ508)。
端末104から受信したパケットがTCPパケットまたはUDPパケットである場合、パケット解析手段204は、宛先ポート番号が所定のアプリケーションのポート番号であるか否かを判定する(ステップ509)。所定のアプリケーションとは、例えばデフォルトゲートウェイでは動作させることのないアプリケーションを想定しており、このアプリケーション宛のパケットはデフォルトゲートウェイIPアドレス推定の対象外とする。
図10は、本発明の実施の形態2における対象外とするアプリケーションに対応するポート番号を示す図であり、実施の形態2では図10に示すように、アプリケーションのプロトコルとポート番号を用いる。
パケット解析手段204は、受信したパケットが図10に示すような所定のアプリケーションのものであった場合、このパケットの宛先IPアドレスとポート番号をターゲット記憶手段205に登録する(ステップ510)。
ステップ507、ステップ510の処理の後、カウント手段206は、パケット受信カウンタが所定の値に到達したか否かを確認する(ステップ511)。
カウント手段206が、パケット受信カウンタが所定の値に到達していない場合、パケット受信とその後の処理(ステップ501〜511)を、パケット受信カウンタが所定の値に到達するまで繰り返す。
パケット受信カウンタが所定の値に到達すると、アドレス推定手段207は、ターゲット記憶手段205に登録した情報を用いて端末104のデフォルトゲートウェイIPアドレスの推定処理を行う(ステップ512)。
図11〜図14は、本発明の実施の形態2におけるターゲット記憶手段の状態を示す図であり、ステップ512の時点で、ターゲット記憶手段205に登録されている情報を示している。
図11において、IPアドレス「10.2.2.1」のエントリは、端末104からのパケットをARP要求パケットのターゲットIPアドレスとして受信したことを示し(ARP受信フラグON)、その後TCPパケットやUDPのパケットを受信しなかったこと(ポート番号に登録なし)を示している。
また、IPアドレス「10.2.2.12」のエントリは、端末104からのパケットをARP要求パケットのターゲットIPアドレスとして受信したことを示し、DNS(Domain Name System)プロトコルのパケットであることを示すポート番号「53」宛のパケットを受信したことを示している。
また、IPアドレス「210.1.2.3」のエントリは、端末104からのパケットをARP要求パケットのターゲットIPアドレスとして受信しなかったことを示し、宛先ポート番号として「80」(HTTP)のパケットを受信したことを示している。
実施の形態1では、パケット解析手段204は、ARP受信フラグがONで、IPアドレス宛の通信が示すアプリケーションが特定のものでないエントリをデフォルトゲートウェイIPアドレスの候補として選択(推定)する例を示した。
これは、デフォルトゲートウェイでは特定のサービスを行っていることが稀であることに着目した推定である。実施の形態1の方法では図11のケースは、IPアドレス「10.2.2.1」がデフォルトゲートウェイIPアドレスの候補として選択されることとなる。
通信装置102の設定手段208は、パケット解析手段204が選択したIPアドレスをネットワークインタフェースのIPアドレスとして設定するため、SDRAM54に記憶されているLAN用モジュラージャック14に対応するIPアドレスの情報を書き換える処理を行う(ステップ513)。そして、カウント手段206は、送信元IPアドレスからのパケットのカウントを停止する(ステップ514)。
これにより、IPアドレスが静的に設定された端末104を、通信装置102に接続する場合や、既に稼動しているネットワークに通信装置102を接続する場合に、ユーザが通信装置102のネットワーク設定をマニュアル的に行う必要なく、ネットワーク接続することが可能となる。
以上のように実施の形態2によれば、静的にIPアドレスを設定された端末104のデフォルトゲートウェイIPアドレスを推定し、通信装置102のネットワークインタフェースIPアドレスとして設定するので、第1のネットワーク103における端末104のデフォルトゲートウェイとしてこの通信装置102は機能し、端末104からの不要なパケットを受信することなく効率良くパケットの転送を行うことができる。
なお、本実施の形態2では、デフォルトゲートウェイIPアドレスを推定する条件の1つとして、受信したパケットの宛先が所定のサービスを示すポート番号宛のものであるIPアドレスを除外するようにしたが、これとは逆に、例えば図12で示すように、デフォルトゲートウェイへのみ送信されるパケットを含む所定のサービスを示すプロトコルのパケットを検出できた場合(例えばUPnP(Universal Plug and Play)プロトコル)のゲートウェイを探索するパケットで、ポート番号が1900であることにより判別することができる)、その宛先IPアドレスである例えば「10.2.2.1」をデフォルトゲートウェイのIPアドレスであると推定することによっても、受信したパケットの宛先が所定のサービスを示すポート番号宛のものであるIPアドレスを除外した場合と同様の効果が得られる。
また、実施の形態2では、デフォルトゲートウェイIPアドレスを推定した結果、デフォルトゲートウェイIPアドレスの候補を1つに絞ることができたが、図13に示すように、候補となるIPアドレスが存在しなくなってしまった場合、デフォルトゲートウェイでサービスされることの多いアプリケーションのポート番号を持つものを候補選択のための条件として付加してもよい。例えば、DNSサービスは、ゲートウェイでプロキシさせて運用する場合多く、これをパケットの宛先ポート番号「53」であることにより判別する。ここでは、宛先IPアドレス「10.2.2.1」を選択することによって、デフォルトゲートウェイIPアドレスの候補が1つに絞られた場合と同様の効果が得られる。
さらに、図14のターゲット記憶手段205の状態で示すように、実施の形態2のアドレス推定手段207によって推定処理を行なうと、デフォルトゲートウェイの候補となるIPアドレスが複数存在する場合もある。このような場合、ゲートウェイとしてよく用いられる特異なIPアドレス(例えば、IPアドレスの最下位バイトが最小値である1、または最大値である254であるもの)を選択する条件を追加してデフォルトゲートウェイIPアドレスを推定してもよい。ここでは、デフォルトゲートウェイIPアドレスの候補を例えば「10.2.2.1」に絞ることによって、デフォルトゲートウェイの候補となるIPアドレスが1つしか存在しない場合と同様の効果が得られる。
(実施の形態3)
以下、実施の形態3について説明する。
ルータ等の通信装置では、通常、ネットワークを開始する際に少なくともIPアドレスとサブネットマスクを必要とするが、ネットワークに接続する端末には、IPアドレスやデフォルトゲートウェイIPアドレスやサブネットマスクが、通信機器の設定とは無関係に静的に設定されている場合がある。
このような端末を通信装置に接続した場合に、通信装置に設定されているサブネットマスクと端末に設定されているサブネットマスクとが異なっていることが原因で通信が不可能となる場合が発生する。
このような状況では、一般的には、ユーザが通信装置か端末の一方を他方の設定に合わせる操作が必要であり、ネットワークの設定に関する高度な知識が要求され、ユーザによっては非常に困難な作業である。
また、通信装置が端末のサブネットマスクの値を知る方法としては、RFC(Request For Comment)950に記載のICMP(Internet Control Message Protocol)のType17のアドレスマスク要求を使用することが考えられる。例えば、特表2005−513832号公報では、この方法をルータに応用し、ルータが端末にICMPアドレスマスク要求を送信して、端末からネットワークに接続するために必要なパラメータを取得している。ただし、端末に搭載されているOS(Operating System)によってはICMP要求に応答しない設定にされているものもあり、必ずユーザの手を煩わせずにサブネットマスク値を取得できるものではない。
実施の形態3の通信装置102を適用したネットワークシステムの構成は、実施の形態1の図1に示すものと同様である。
また、通信装置102のハードウェア構成についても、実施の形態1の図2〜図4に示したものと同様であり、説明を省略する。
図15は、本発明の実施の形態3における通信装置の機能構成図である。
図15において、151は、端末104からのパケットを受信する受信部である。152は、受信部151で受信したパケットのアドレス情報をもとに端末104と通信を試みて、通信が可能か否かにより、通信装置102に設定されているサブネットマスク値と、端末104に静的に設定されているサブネットマスク値が同一かどうかを判断する監視部である。
153は、通信装置102と端末104に静的に設定されているサブネットマスク値が異なっていた場合に、端末104に静的に設定されているサブネットマスク値を推定するため、端末104のサブネットマスク値の候補を算出し、サブネットマスク値の候補ごとに端末104からアクセスさせるための最大と最小のホストのIPアドレス(ホストアドレス)を算出するホストアドレス算出部である。
154は、ホストアドレス算出部153で作成したホストアドレスに端末104からアクセスがあった時の端末104から送信されるARPリクエストを監視し、また、その監視した情報から端末104に静的に設定されているサブネットマスク値を推定して通信装置102の設定に反映するサブネットマスク推定部である。
155は、推定したサブネットマスクをネットワーク機器に通知する等、通信装置102から端末104へパケットを送信する送信部である。156は、処理されるデータを記憶しておく記憶部である。
ここで、通信装置102のハードウェア構成(図4)と機能構成(図15)との対応関係について説明する。
図4及び図15において、受信部151は、LAN用モジュラージャック14、EPHY56、EMAC51cのハードウェア経路にて受信したパケットを、CPU51aによって、SDRAM54上に格納することで実現される。
送信部155は、SDRAM54上に構成されたパケットを、CPU51aによって、EMAC51c、EPHY56、LAN用モジュラージャック14のハードウェア経路にて送信することで実現される。
監視部152、ホストアドレス算出部153、サブネットマスク推定部154、記憶部156は、いずれも、CPU51aがSDRAM54に記憶された各種の制御プログラムを読み出して実行すると共に、SDRAM54のデータ記憶領域に対してデータを記憶や読出を行う、あるいは記憶されたデータの解析などを行うことにより実現される。
なお、実施の形態3において、CPU51aが実行する各種の制御プログラムは、汎用コンピュータ等でも利用可能であることは実施の形態1と同様である。
以上のように構成された通信装置の構成について、以下その動作を説明する。
図16は、本発明の実施の形態3における通信装置の動作フローチャートであり、通信装置102が端末104のサブネットマスク値を推定する動作を示している。
図16において、通信装置102が起動すると同時にステップ201よりフローを開始する。
ステップ202では、端末104からパケットが送信されてくるまで待機し、パケットを受信すると、そのパケットの情報から端末104のIPアドレスを取得する。
なお、通信装置102のLAN用モジュラージャック14には、実施の形態1、2で示したように、端末104に静的に設定されている情報を取得し、端末104のデフォルトゲートウェイIPアドレスを割り当てることが望ましいが、実施の形態3の場合は、デフォルトゲートウェイIPアドレスの設定については、その他の公知の方法であっても良いし、ユーザがマニュアル的にネットワークの設定を行うような場合でも、サブネットマスク値のユーザの設定ミスを修正できるという点で、実施の形態3は有効である。
また、次のような方法を使用してもよい。
通信装置102の受信部151にはDNS(Domain Name System)サーバ機能とWEBサーバ機能があり、接続しようとしている通信装置102と無関係に、すなわち静的なネットワーク情報の設定がなされている端末104をあるユーザが通信装置102に接続したとする。
この時、端末104のユーザは、ネットワークへ接続できないことを知るとドメイン名に基づき通信装置1のWEBサーバ上のコンテンツに対してアクセスを行う。
受信部151は、この時に送信されてくるパケットから端末104に静的に設定されているIPアドレスやデフォルトゲートウェイのIPアドレスの情報を取得する。受信部151は、ステップ202で受信したパケットの情報をもとに、通信装置102のIPアドレスを端末104に設定されているデフォルトゲートウェイのアドレスに設定する。
ステップ203で、監視部152は、ステップ202で取得した端末104のIPアドレスと通信機器102にあらかじめ設定されているサブネットマスク値をネットワーク情報として使用し、端末104に対して通信を試みてみる。通信が可能であればサブネットマスクの値は通信装置102と端末104で一致していると判断し、ステップ202で再度待機状態とする。
逆に、通信が不可能であった場合は、サブネットマスク値が通信装置102と端末104とで一致していないと判断し、ホストアドレス算出部153の処理へ移行する。
ここで、説明をわかりやすくするため、具体例を用いる。
端末104に設定されているIPアドレスが10.75.21.165、サブネットマスクが255.255.254.0、デフォルトゲートウェイのIPアドレスが10.75.20.1、通信装置102のIPアドレスは10.75.20.1(端末104のデフォルトゲートウェイのIPアドレスにあわせた後のIPアドレス)と仮定する。
通信装置102は、ステップ202の段階では、端末104に設定されているIPアドレスやデフォルトゲートウェイのIPアドレスの情報は取得できているが、サブネットマスク値は取得できていない。
そこで、ステップ202で取得した端末104のIPアドレスから図19に示すような、サブネットマスク値の使用ビット数とネットワークアドレス候補のリストを作成し、記憶部156に登録する。以下その様子について説明する。
ステップ204において、ホストアドレス算出部153は、ステップ202で取得した端末104のIPアドレスから、端末104がサブネットマスク値として撮り得る範囲を求める。図17は、サブネットマスク値の範囲推定ルーチンを示すものである。
図17に示すように、ステップ403、ステップ405、ステップ407において、ホストアドレス算出部153は、端末104のIPアドレスの先頭オクテットデータによる場合分けを行い、先頭オクテットデータが1〜127の場合は、クラスAであると判断し、ステップ404に進み最小マスク値(サブネットマスクの最小のビット数)を8ビットとする。
先頭オクテットデータが128〜191の場合は、クラスBであると判断し、ステップ406に進み最小マスク値を16ビットとする。
先頭オクテットデータが192〜223の場合は、クラスCであると判断し、ステップ408に進み最小マスク値を24ビットとする。
前述の具体例の場合、IPアドレスの先頭オクテットデータが10であるので、最小マスク値は8ビットであるとなる。
次に、ホストアドレス算出部153は、ステップ409で、最大マスク値を求める。
図18は、最大マスク値の推定ルーチンを示すものである。実施の形態3では、ステップ804で、最大マスク値は、固定値である30とする。なお、ステップ803〜805の処理は、実施の形態4で詳しく説明する。
実施の形態3で最大マスク値を30とする理由は、ネットワークを構成するためにはホストアドレスは最低2ビット必要であり、30(=32−2)としている。
以上から、前述の具体例の場合、ホストアドレス算出部153は、図17のステップ410で、サブネットマスク値のビット数の範囲は、8ビットから30ビットであることを確定する。
図16に戻り、ステップ205で、ホストアドレス算出部153は、ステップ410で確定した範囲のサブネットマスク値の各ビット数に対して、図19に示すようにネットワークアドレスを定義し、ステップ206において、各ネットワークアドレスに対して、同じく図19に示すようにホストアドレス1とホストアドレス2を定義し、記憶部156に記憶させる。
ホストアドレス1は、それぞれのネットワークアドレスに属するホストアドレスの最大値、つまり当該ネットワークアドレスをもつIPアドレスのホストアドレス部のビットがすべてFとなるアドレスから1を引いたアドレスとする。
ホストアドレス2は、それぞれのネットワークアドレスに属するホストアドレスの最小値、つまり当該ネットワークアドレスをもつIPアドレスのうちホストアドレス部のビットがすべて0のアドレスから1を足したアドレスとする。
作成されたホストアドレスのリスト(図19)から、通信装置102あるいは端末104のIPアドレスであるものを除外し、重複しているものは1つとみなすと、図21に示すホストアドレス候補が作成され、記憶部156に登録される。
ステップ207で、サブネットマスク推定部154は、端末104から図21に示す候補に対して(1)から順に、すなわちサブネットマスク値の使用ビット数が大きい方から順にアクセスさせるよう制御する。
なお、アクセス方法としては、通信装置102から端末104に対して自動実行するスクリプトを渡す方法や、通信装置102がWEBサーバ機能を備え、WEB上にHTML等により各候補に対するリンクを設定しておき、端末104のユーザが、画面表示をみながら操作させることにより、アクセスするという方法などが考えられる。
サブネットマスク値の大きい方からアクセスさせるため、上記の方法では、スクリプトで制御したり、ユーザにアクセスさせる場合には、ホストアドレス候補毎に表示したり、アクセス順序を併せて表示する等の処理を行う。
また、サブネットマスク値の大きい(1)からアクセスさせる理由としては、ARPリクエストが送信される可能性が高いものからアクセスを実施し、ARPリクエスト送信のタイムアウト時間まで待つケースを減らし、推定に要する時間を短くするためである。さらに、端末104からのARPリクエストを外部のネットワークに流出することを抑制することもできる。
例えば、サブネットマスク値の使用ビット数が30である(1)にアクセスさせると、サブネットマスク値の使用ビット数が29以下となるサブネットにも属するため、求めるべき実際のサブネットマスクの使用ビット数が29以上である場合にも、ARPリクエストが送信される。
逆に(24)からアクセスさせる(サブネットマスク値の使用ビット数が少ない順にアクセスさせる)と、そのIPアドレスよりサブネットマスク値の使用ビット数が大きい場合には、ARPリクエストの送信が無い可能性が高く、タイムアウト時間まで待つケースが多くなる。
次に、サブネットマスク推定部154は、ステップ208において、ステップ207で(1)から順にアクセスさせた各候補について、ARPリクエストのパケット到着の有無でその候補のIPアドレスが、端末104に設定されたサブネットの範囲であるかどうかの判定を行う。
ARPリクエストが受信される、つまり、端末104からARPリクエストが送信されるということは、端末104は、そのホストアドレス候補が端末104に静的に設定されているサブネットの範囲内であると判断していることがわかる。なお、端末104のARPテーブルは、本処理の開始前にはクリアされているものとする。図20に示すように、通信装置102において各ホストアドレス候補に対してARPリクエストやIPパケットの受信をリストとして記憶部156に保持するようにしてもよい。
前述の具体例の場合、図21に示すように、(9)の候補までは、端末104からARPリクエストが送信され通信装置102によってそれを受信できるが、(10)の候補では、ARPリクエストが端末104から送信されない。(10)の候補では、端末104に設定されているサブネットマスク値の範囲外となったため、端末104は他のネットワークに存在するホストであると判断し、ARPリクエストを送信せずにデフォルトゲートウェイに対してアクセスを試みるためである。
サブネットマスク推定部154は、ステップ208においてARPリクエストが未受信となると、ステップ209に進み、ステップ207のアクセスによって最後にホストアドレス1、ホストアドレス2ともにARPリクエストが送信されたのは(9)であるため、図20から、そのホストアドレスのマスク値ビット数、つまり23ビットが端末104に静的に設定されているサブネットマスク値であると推定する。
上記のようにサブネットマスク値の大きい方から順にアクセスする場合には、ホストアドレスに対してARPリクエストが送信されなくなった時のマスク値のビット数に1を加えた値が端末104に静的に設定されているマスク値のビット数であると推定する。
ステップ209でマスク値を推定後は、図16に示すようにステップ210に進む、つまり(10)以降の候補に関してはステップ207の端末104からのアクセスを実施しないようにしてもよい。
サブネットマスク推定部154は、このようにして推定したサブネットマスク値をステップ210において通信装置102のネットワーク設定に反映するため、SDRAM54に記憶されているサブネットマスク値を書き換える。これにより、端末104の設定を変更することなく、サブネットマスク値に起因する通信トラブルを回避し、通信を可能にすることができる。
ステップ211では、送信部105は、推定したサブネットマスクの値を端末104に通知する。これにより、端末104のユーザは、通信装置102のネットワーク設定が終了し、通信可能になったことを確認することができる。
なお、サブネットマスク値の推定に失敗した場合は、通信装置102で取得した端末104のIPアドレスの先頭オクテットデータが1から127の場合はマスク値を8ビット、128から191の場合はマスク値を16ビット、192から223の場合は24ビットと判断し、これらを推定値とする。
なお、実施の形態3では、サブネットマスク値の大きいホストアドレスもの、すなわち図21の(1)から順にステップ207の処理を行ったが、サブネットマスク値の小さいホストアドレスから順にステップ207の処理を行ってもサブネットマスク値の推定は可能である。
また、サブネットマスク値の大小を問わずランダムにアクセスし、ARPリクエストを受信できないものを検出した場合は、その前後のサブネットマスク値を調べ、ARPリクエストを受信できるマスク値と受信できないマスク値の境界を探してもよい。
また、ホストアドレス算出部153が、ステップ204で算出したサブネットマスク値の候補が1つであった場合には、ステップ205〜209の処理を行わずにステップ210以降を実行しても良い。
第1のネットワーク103で通信装置102と接続する端末として、当該端末が端末104のネットワーク設定と同一の設定であるときは、端末104について行われた上記の処理により、他の端末も通信装置102と通信可能になる。
また、第1のネットワーク103で通信装置102と接続する端末として、当該端末が端末104と異なる場合には、当該端末について、別の仮想LANを構築し、端末104に対するのと同様の手順で通信装置102のIPアドレス、サブネットマスクをそれぞれの仮想LANに設定する。
以上のように実施の形態3によれば、通信装置102が端末104に静的に設定してあるサブネットマスク値を推定することが可能となり、この推定値を通信装置102のネットワーク設定に反映することで、端末104の静的な設定を変更することなしに通信装置102と端末104との通信が可能となる。
(実施の形態4)
以下、本発明の実施の形態4について説明する。
実施の形態4が実施の形態3と相違する点は、ホストアドレス算出部153が、ステップ204において端末104のIPアドレスからサブネットマスクの範囲を求めるにあたって、最大マスク値をさらに絞り込む手法を取り入れた点である。
これにより、ホストアドレス算出部153で算出されるホストアドレスの候補数を減らすことが可能となり、端末104に静的に設定されているサブネットマスクの推定に要する時間を短縮できるだけでなく、推定が完了するまでに端末104から第1のネットワーク103に送信されるパケット数を減らすことが可能となる。
ここで、実施の形態3と同様に通信装置102のIPアドレスが10.75.20.1、端末104のIPアドレスが10.75.21.165であったと仮定する。
実施の形態4では、図18においてステップ804ではなく、ステップ803、ステップ805を実行する。
ステップ803において、ホストアドレス算出部153は、図22に示すように、通信装置102と端末104のIPアドレスの先頭からの共通部分を求める。
2つのIPアドレスから共通するビットが23ビットであるため、最低9ビットがホスト部として必要であることがわかる。つまり、23ビット以下の値が通信装置102および端末104がネットワークを構成するために必要なサブネットマスク値のビット数と推定できる。
これにより、実施の形態4の場合、図20の候補のうち、マスク値が24ビットから30ビットの候補に関しては除外できる。なお、このようにして算出されたマスク値が1つの場合は、その値を推定値とする。
以上のように実施の形態4によれば、通信装置102が端末104に静的に設定されているサブネットマスクの値を推定するにあたり、マスク値の推定範囲を絞ることで端末104に静的に設定されているサブネットマスク値を推定するまでに要する時間の短縮と、端末104から第1のネットワーク103に送信されるパケットを減らす効果が得られる。