JP5012207B2 - 通信装置、通信装置の制御方法及び通信装置の制御プログラム - Google Patents

Description

本発明は、ＬＡＮ等の第１のネットワークとインターネット等の第２のネットワークとの間に介在し、両ネットワーク間の通信を中継するルータ等の通信装置、通信装置の制御方法及び通信装置の制御プログラムに関するものである。

通信装置や端末のネットワーク設定は、互いが接続するネットワークのセグメント情報間で整合性を持ったアドレス等の情報を用いる必要がある。

これらのネットワーク設定の情報は、あらかじめ通信装置および端末にそれぞれ付与されているか、通信装置などから端末へ整合性の取れたネットワーク情報を自動的に付与することが一般的である。

ルータ等の通信装置は、通常、ネットワークを起動する際に少なくともＩＰアドレスとサブネットマスクを必要とするが、通信装置に接続される端末にはＩＰアドレスやデフォルトゲートウェイのＩＰアドレスやサブネットマスクが、通信機器の設定とは無関係に静的に設定されている場合がある。

そのような端末を通信装置に接続しても、ネットワーク情報の整合が取れないために、そのままでは互いに通信できない。一般的には、ユーザがマニュアル的に設定するが、ネットワーク知識の少ないユーザにとっては敷居の高いものである。

サブネットマスクの値を知る方法としては、ＲＦＣ（Ｒｅｑｕｅｓｔ Ｆｏｒ Ｃｏｍｍｅｎｔ）９５０に記載のＩＣＭＰ（Ｉｎｔｅｒｎｅｔ Ｃｏｎｔｒｏｌ Ｍｅｓｓａｇｅ Ｐｒｏｔｏｃｏｌ）のＴｙｐｅ１７のアドレスマスク要求を使用することが考えられる。下記（特許文献１）では、この方法をルータに応用し、ルータが端末にＩＣＭＰアドレスマスク要求を送信して、端末からネットワークに接続するために必要なパラメータを取得している。
特表２００５−５１３８３２号公報

しかしながら、上記手法では、端末に搭載されているＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）によってはＩＣＭＰ要求に応答しない設定にされているものもあるため、必ずしもサブネットマスクの値を取得できるとは限らないという問題点を有していた。

本発明は、通信装置に、通信装置とは無関係に設定された静的なネットワーク設定を持つ端末が接続された場合、確実に端末のサブネットマスク値を取得することができる通信装置、通信装置の制御方法及び通信装置の制御プログラムを提供することを目的とする。

本発明は、第１のネットワークと第２のネットワークとの間のデータ通信を中継する通信装置であって、第１のネットワーク接続用のインターフェースを有し、第１のネットワークに接続された端末からのパケットを受信する受信手段と、受信手段で受信したパケットから端末のＩＰアドレスを取得し、当該ＩＰアドレスに基づいて端末が取り得るサブネットマスク値の範囲を求めると共に、各サブネットマスク値に対応するホストアドレスの候補を求め、当該ホストアドレス候補を端末からアクセス可能に設定し、端末からのホストアドレス候補へ送信されるパケット状態に基づいて端末のサブネットマスク値の推定値を決定し、当該推定値を第１のネットワーク接続用のインターフェースに対応したサブネットマスク値として設定する制御手段と、を有し、制御手段は、端末からのホストアドレス候補へ送信されるパケット状態として、端末からのＡＲＰリクエストの送信の有無をチェックする構成とした。

この構成によれば、推定したサブネットマスク値と取得した端末のＩＰアドレスに基づき、端末の設定変更を行うことなく通信装置と端末間で通信が可能となる。また、推定したサブネットマスク値と取得した端末のＩＰアドレスに基づき、端末の設定変更を行うことなく通信装置と端末間で通信が可能となる。

本発明によれば、端末に静的に設定されているサブネットマスク値の設定が、通信装置のサブネットマスク値と異なっていた場合であっても、通信装置が端末の静的に設定されているサブネットマスク値を推定し、推定したサブネットマスク値と取得した端末のＩＰアドレスに基づき、端末の設定変更を行うことなく通信装置と端末間で通信が可能となり、ユーザへの負担が軽減される。

第１の発明は、第１のネットワークと第２のネットワークとの間のデータ通信を中継する通信装置であって、第１のネットワーク接続用のインターフェースを有し、第１のネットワークに接続された端末からのパケットを受信する受信手段と、受信手段で受信したパケットから端末のＩＰアドレスを取得し、当該ＩＰアドレスに基づいて端末が取り得るサブネットマスク値の範囲を求めると共に、各サブネットマスク値に対応するホストアドレスの候補を求め、当該ホストアドレス候補を端末からアクセス可能に設定し、端末からのホストアドレス候補へ送信されるパケット状態に基づいて端末のサブネットマスク値の推定値を決定し、当該推定値を第１のネットワーク接続用のインターフェースに対応したサブネットマスク値として設定する制御手段と、を有する構成とした。

これにより、推定したサブネットマスク値と取得した端末のＩＰアドレスに基づき、端末の設定変更を行うことなく通信装置と端末間で通信が可能となる。

第２の発明は、第１の発明において、制御手段は、サブネットマスク値に対応するホストアドレスの候補は、サブネットマスク値から定義されるネットワークアドレスに属する最大及び最小のホストアドレスとする構成とした。

これにより、推定したサブネットマスク値と取得した端末のＩＰアドレスに基づき、端末の設定変更を行うことなく通信装置と端末間で通信が可能となる。

第３の発明は、第１の発明において、制御手段は、端末からのホストアドレス候補へ送信されるパケット状態として、端末からのＡＲＰリクエストの送信の有無をチェックする構成とした。

これにより、推定したサブネットマスク値と取得した端末のＩＰアドレスに基づき、端末の設定変更を行うことなく通信装置と端末間で通信が可能となる。

第４の発明は、第３の発明において、制御手段は、ＡＲＰリクエストの送信のあったホストアドレスと、ＡＲＰリクエストの送信の無かったホストアドレスの境界を求め、その境界においてＡＲＰリクエストの送信があったホストアドレスのマスク値を推定値とする構成とした。

これにより、推定したサブネットマスク値と取得した端末のＩＰアドレスに基づき、端末の設定変更を行うことなく通信装置と端末間で通信が可能となる。

第５の発明は、第１の発明において、制御手段は、サブネットマスク値に対応するホストアドレスの候補に、端末からアクセス可能に設定する際、サブネットマスク値の使用ビット数が大きいものからアクセスさせる構成とした。

これにより、推定したサブネットマスク値と取得した端末のＩＰアドレスに基づき、端末の設定変更を行うことなく通信装置と端末間で通信が可能となる。

第６の発明は、第５の発明において、制御手段は、ホストアドレス候補のうち、ＡＲＰリクエストが送信されなくなったホストアドレスのマスク値に１加えたマスク値を推定値とする構成とした。

これにより、推定したサブネットマスク値と取得した端末のＩＰアドレスに基づき、端末の設定変更を行うことなく通信装置と端末間で通信が可能となる。

第７の発明は、第１の発明において、制御手段は、端末が取り得るサブネットマスク値の範囲を求める際、その最小値は、端末のＩＰアドレスの先頭オクテットデータに基づいて決定する構成とした。

これにより、サブネットマスクの推定に要する時間を短縮することができる。

第８の発明は、第１の発明において、制御手段は、端末が取り得るサブネットマスク値の範囲を求める際、その最大値は３０ビットとする構成とした。

これにより、サブネットマスクの推定に要する時間を短縮することができる。

第９の発明は、第１の発明において、制御手段は、端末が取り得るサブネットマスク値の範囲を求める際、その最大値は、端末のＩＰアドレスと自身に設定されているＩＰアドレスとの先頭からの共通ビット数とする構成とした。

これにより、サブネットマスクの推定に要する時間を短縮することができる。

第１０の発明は、第１の発明において、制御手段は、サブネットマスク値に対応するホストアドレスの候補から、重複したものは除外し、当該ホストアドレス候補を端末からアクセス可能に設定する構成とした。

これにより、サブネットマスクの推定に要する時間を短縮することができる。

第１１の発明は、第１の発明において、制御手段は、サブネットマスク値に対応するホストアドレスの候補から、自身と端末の有するＩＰアドレスと一致するものは除外し、当該ホストアドレス候補を端末からアクセス可能に設定する構成とした。

これにより、サブネットマスクの推定に要する時間を短縮することができる。

第１２の発明は、第１の発明において、制御手段は、端末が取り得るサブネットマスク値の範囲を求めた結果、１つであった場合、当該サブネットマスク値を、第１のネットワーク接続用のインターフェースに対応したサブネットマスク値として設定する構成とした。

これにより、迅速に通信を開始することが可能となる。

第１３の発明は、第１の発明において、制御手段は、サブネットマスク値が得られない場合、端末のＩＰアドレスの先頭オクテットデータが１〜１２７であれば８ビット、１２８〜１９１であれば１６ビット、１９２〜２２３であれば２４ビットとして、第１のネットワーク接続用のインターフェースに対応したサブネットマスク値として設定する構成とした。

これにより、推定できない場合でも通信が可能となる。

以下、本発明の各実施の形態について説明する。これらの実施の形態は関連する範囲で相互に利用可能である。

（実施の形態１）
図１は、本発明の実施の形態１における通信装置を適用したネットワークシステムの構成図である。

図１において、１０２は異なるネットワーク間に設けられ、両ネットワーク間のデータ通信を中継するルータ等の通信装置である。１０１は、通信装置１０２に接続される例えばインターネットなどの第２のネットワークである。１０３は、通信装置１０２に接続される例えばローカルエリアネットワーク（ＬＡＮ）などの第１のネットワークである。１０４〜１０６は、第１のネットワーク１０３に接続してインターネット（第２のネットワーク１０１）へアクセスする端末である。

端末には、ＤＨＣＰ（Ｄｙｎａｍｉｃ Ｈｏｓｔ Ｃｏｎｆｉｇｕｒａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）を用いて自端末のネットワーク情報（ネットワーク接続に必要な設定情報）の取得を試みる端末１０５、端末１０６や、あらかじめ自端末のネットワーク情報が端末内に静的に設定されている端末１０４が存在している。

実施の形態１では、通信装置１０２が、静的にネットワーク情報が設定されている端末１０４から送信されるパケットに基づいて、端末１０４のデフォルトゲートウェイＩＰアドレスを推定し、推定したＩＰアドレスを通信装置１０２のネットワークインタフェースのＩＰアドレスとして設定する点について説明する。

図２、図３は、本発明の実施の形態１における通信装置の外観斜視図であり、図２は前面を図３は背面をそれぞれ示している。

図２に示す通信装置１０２はルータである。通信装置１０２は、筐体１１を有しており、筐体１１の前面には、ＬＥＤ（Ｌｉｇｈｔ Ｅｍｉｔｔｉｎｇ Ｄｉｏｄｅ）などの表示部１２が設けられている。

筐体１１の背面には、図３に示すように、ＤＣ（Ｄｉｒｅｃｔ Ｃｕｒｒｅｎｔ）電源コネクタ１３、ＲＪ４５などＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）用モジュラージャック１４、及びＷＡＮ（Ｗｉｄｅ Ａｒｅａ Ｎｅｔｗｏｒｋ）用モジュラージャック１５が設けられている。ＤＣ電源コネクタ１３には、平行ケーブルなどの電力線１６が接続される。モジュラージャック１４、１５には、Ｅｔｈｅｎｅｔケーブル１７が接続される。

なお、通信装置１０２の一例としてルータを示したが、通信装置１０２としては、ルータの機能を備えた機器（例えばパーソナルコンピューターや、冷蔵庫などの家電機器）であってもよい。

図４は、本発明の実施の形態１における通信装置のハードウェア構成図である。

図４において、通信装置１０２は、破線で示す筐体１１内に、回路モジュール５０を有している。回路モジュール５０には、メインＩＣ（Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔ）５１が実装されている。

メインＩＣ５１は、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｃｅｓｓｉｎｇ Ｕｎｉｔ）５１ａと、メインバス５１ｆやローカルバス５１ｇなどのバスと、バス上のデータの流れを制御するＢＣＵ（Ｂｕｓ Ｃｏｎｔｒｏｌ Ｕｎｉｔ）５１ｂと、Ｅｔｈｅｒｎｅｔ（登録商標）のＭＡＣ（Ｍｅｄｉａ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ）層を制御するＭＡＣブロック（ＥＭＡＣ）５１ｃ、５１ｄと、ＰＣＩ（Ｐｅｒｉｐｈｅｒａｌ Ｃｏｍｐｏｎｅｎｔｓ Ｉｎｔｅｒｃｏｎｎｅｃｔ）バスを制御するＰＣＩＵ５１ｅとを有している。

メインＩＣ５１内のＣＰＵ５１ａ及びＢＣＵ５１ｂは、メインバス５１ｆを介して、ＳＤＲＡＭ（Ｓｙｎｃｈｒｏｎｏｕｓ Ｄｙｎａｍｉｃ Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）５４と、Ｆｌａｓｈ ＲＯＭ（Ｆｌａｓｈ Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）５５とに接続されている。

また、ＣＰＵ５１ａ及びＢＣＵ５１ｂは、ローカルバス５１ｇを介して、メインＩＣ５１にクロックを供給する発振器５２と、ＬＥＤなどの表示部１２と、メインＩＣ５１に初期化信号を出力するリセットＩＣ５３とに接続されている。ローカルバス５１ｇには、ＣＰＵ５１ａ、ＢＣＵ５１ｂ、ＥＭＡＣ５１ｃ、５１ｄ、ＰＣＩＵ５１ｅ、発振器５２、表示部１２、リセットＩＣ５３が接続されている。

メインＩＣ５１内のＭＡＣブロック５１ｃ、５１ｄはそれぞれ、Ｅｔｈｅｒｎｅｔ（登録商標）の物理層を制御するＰＨＹ（ＰＨＹｓｉｃａｌ ｌａｙｅｒ）・ＩＣであるＥＰＨＹ５６、５７に接続されており、ＥＰＨＹ５６、５７はそれぞれ、ＬＡＮ用モジュラージャック１４、ＷＡＮ用モジュラージャック１５に接続されている。また、メインＩＣ５１は、ＤＣ−ＤＣ（Ｄｉｒｅｃｔ Ｃｕｒｒｅｎｔ ｔｏ Ｄｉｒｅｃｔ Ｃｕｒｒｅｎｔ）変換器５８を介して、ＤＣ電源コネクタ１３に接続されている。ＤＣ−ＤＣ変換器５８は、ＤＣ電源コネクタ１３から供給されるＤＣ電圧をメインＩＣ５１で必要なＤＣ電圧に変換する。

図５は、本発明の実施の形態１における通信装置の機能構成図である。

図５に示すように、通信装置１０２において、２０２はＬＡＮ（第１のネットワーク１０３）側の端末１０４などからのパケットを受信するパケット受信手段、２０４はパケット受信手段２０２が受信したパケットを解析するパケット解析手段、２０６はパケット受信手段２０２が受信したパケットの数を管理するカウント手段、２０５はパケット受信手段２０２が受信したパケットが示すターゲットとなるＩＰアドレス（パケット情報）を記憶するターゲット記憶手段、２０７はパケット受信手段２０２が受信したパケットの情報に基づいてデフォルトゲートウェイＩＰアドレスを推定するアドレス推定手段、２０８はアドレス推定手段２０７が推定したＩＰアドレスを通信装置１０２のネットワークインタフェースに設定する設定手段、２０３は端末１０４などから受信したＡＲＰ要求パケットに対する応答などを生成するパケット生成手段、２０１はパケット生成手段２０３が生成したパケットを送信するパケット送信手段である。

ここで、通信装置１０２のハードウェア構成（図４）と機能構成（図５）との関係について説明する。

図４及び図５において、パケット送信手段２０１は、ＳＤＲＡＭ５４上に構成されたパケットをＬＡＮ側インターフェースに送信するため、ＣＰＵ５１ａによって、ＥＭＡＣ５１ｃ、ＥＰＨＹ５６、ＬＡＮ用モジュラージャック１４のハードウェア経路にて送信することで実現される。

パケット受信手段２０２は、ＬＡＮ側インターフェースより、ＬＡＮ用モジュラージャック１４、ＥＰＨＹ５６、ＥＭＡＣ５１ｃのハードウェア経路にて受信したパケットを、ＣＰＵ５１ａによって、ＳＤＲＡＭ５４上に格納することで実現される。

パケット生成手段２０３、パケット解析手段２０４、ターゲット記憶手段２０５、カウント手段２０６、アドレス推定手段２０７、設定手段２０８は、いずれも、ＣＰＵ５１ａがＳＤＲＡＭ５４に記憶された各種の制御プログラムを読み出して実行すると共に、ＳＤＲＡＭ５４のデータ記憶領域に対してデータを記憶や読出を行う、あるいは記憶されたデータの解析などを行うことにより実現される。

なお、実施の形態１では、通信装置１０２としてルータという専用装置を示しているが、ＣＰＵ５１ａにより実行される各種の制御プログラムは、汎用コンピュータ等で実行させることでも実現可能である。その際、各種の制御プログラムは、コンピュータのＲＯＭやＨＤＤ等の内蔵メモリに記憶されているものでも良いし、ＣＤやＤＶＤ等の各種のデータを記憶するメディアに記憶されているものでも良い。

図６は、本発明の実施の形態１における通信装置の動作フローチャートであり、通信装置１０２が、ネットワークの設定情報が静的に設定された端末１０４からパケットを受信した際の処理について説明する。

図６において、通信装置１０２と端末１０４がＬＡＮケーブル等で接続された後、通信装置１０２のパケット受信手段２０２は、ＬＡＮ側の端末１０４からのパケットを受信すると（ステップ３０１）、パケット解析手段２０４は受信したパケットの送信元ＩＰアドレスをチェックし記憶しておく（ステップ３０２）。

ステップ３０２でチェックした送信元ＩＰアドレスが、ＤＨＣＰで配布したＩＰアドレスではなく、また、受信したパケットがこれまで受信したことのないＩＰアドレスであれば、パケット解析手段２０４は、このパケットの送信元である端末１０４を未知の端末（ネットワーク情報が未知の端末１０４）であると判断する。

このとき、通信装置１０２のＣＰＵ５１ａが実行する処理によって、未知の端末１０４よりできるだけ多くのデフォルトゲートウェイ宛のパケットを送信させるため、第２のネットワーク１０１に存在するような所定の外部アドレスへのアクセスを端末１０４に促すことを行ってもよい。なお、未知の端末とは、通信装置１０２が割り当てたＩＰアドレスを使用していない端末であり、未知の受信パケットとは当該未知の端末が発したパケットのことを示す。

ステップ３０２で、通信装置１０２が受信したパケットが未知の端末１０４からのパケットでなければ、このパケットに対する処理は終了する。

ステップ３０２で、通信装置１０２が受信したパケットが未知の端末１０４からのパケットであれば、パケット解析手段２０４は、受信したパケットがその端末１０４からの最初のパケットであるか否かを判別する（ステップ３０３）。

ステップ３０３において、送信元ＩＰアドレスからの最初のパケットであれば、カウント手段２０６は、その送信元ＩＰアドレスからのパケットのカウントを開始するため、その旨をＳＤＲＡＭ５４に書き込む（ステップ３０４ａ）。

カウント手段２０６によるパケットのカウント処理は、デフォルトゲートウェイＩＰアドレスを推定するため、どれくらいの数のパケットを受信するかを決める閾値とするものであり、ステップ３０３で最初のパケットでないと判断した場合は、パケットを受信する毎にカウンタを１ずつ増やすため、ＳＤＲＡＭ５４のカウンタ情報を更新する（ステップ３０４ｂ）、所定のカウント値に達するまでパケットの受信と受信したパケットの解析などを継続する。

次に、パケット解析手段２０４は、受信したパケットのヘッダ情報から端末１０４から受信したパケットがＡＲＰパケットであるか否かを判断する（ステップ３０５）。

ステップ３０５において、端末１０４から受信したパケットがＡＲＰパケットの場合、ＡＲＰパケット中のターゲットＩＰアドレス（ＡＲＰプロトコルにおいて通信装置１０２のハードウェアアドレスを知ろうとする端末１０４のＩＰアドレス）をターゲット記憶手段２０５に登録する（ステップ３０６）。ＡＲＰパケット中のターゲットＩＰアドレスをターゲット記憶手段２０５に登録する際、端末１０４からのパケットをＡＲＰパケットのターゲットＩＰアドレスとして受信したことを示すために、ターゲット記憶手段２０５のＡＲＰ受信フラグをＯＮにする。

そして、これに続くパケットを受信するために、ハードウェアアドレスが通信装置１０２となるＡＲＰ代理応答パケットを端末１０４へ送信する（ステップ３０７）。パケット生成手段２０３がＡＲＰ代理応答パケットを生成し、生成したＡＲＰ代理応答パケットをパケット送信手段２０１が端末１０４に送信する。

この後、デフォルトゲートウェイＩＰアドレスを推定できるまで、通信装置１０２のＣＰＵ５１ａの処理によって、未知の端末１０４のパケットをプロキシまたはルーティングすることによって、第２のネットワーク１０１へ転送してもよい。この場合、通信装置１０２は、デフォルトゲートウェイＩＰアドレスが確定した時点で、未知の端末１０４からのパケットのプロキシまたはルーティングによる転送を中止する。

一方、ステップ３０５において、端末１０４から受信したパケットがＡＲＰパケットでない場合、パケット解析手段２０４は、端末１０４から受信したパケットがＩＰパケットであるか否かを判定する（ステップ３０８）。

ステップ３０８において、端末１０４から受信したパケットがＩＰパケットである場合、この宛先ＩＰアドレスをターゲット記憶手段２０５に登録する（ステップ３０９）。このとき、ＩＰアドレスが宛先ＩＰアドレスとして使われたことを示すため、ターゲット記憶手段２０５の宛先ＩＰアドレスフラグをＯＮにする。

なお、ターゲット記憶手段２０５内のＩＰアドレスのエントリは、ＩＰアドレスがＡＲＰのターゲットＩＰアドレスに設定されたパケット、ＩＰアドレスが宛先ＩＰアドレスに設定されたパケットの何れが先に到着した場合であっても、パケットが到着した際に作成される。そして、先に到着したパケットに対応するフラグ（ＡＲＰ受信フラグまたは宛先ＩＰアドレスフラグ）をＯＮにする。その後、もう一方の種類のパケットが到着した場合、既にＩＰアドレスのエントリは存在することとなるが、フラグの状態は先に到着した種類のフラグしか操作（ＯＮ）されていないので、もう一方のフラグ操作（ＯＮ）を追加で行う。

例えば、ＩＰアドレスが宛先ＩＰアドレスに設定されたパケットが先に到着した場合、ターゲット記憶手段２０５内のＩＰアドレスのエントリにおいて宛先ＩＰアドレスフラグをＯＮにし、その後、ＩＰアドレスがＡＲＰのターゲットＩＰアドレスに設定されたパケットが到着した際、ＡＲＰ受信フラグをターゲット記憶手段２０５内のＩＰアドレスのエントリに設定する。

ステップ３０７、ステップ３０９の処理の後、カウント手段２０６は、パケット受信カウンタが所定の値に到達したか否かを確認する（ステップ３１０）。なお、カウンタの所定の値とは、予め決められている回数という意味である。

カウント手段２０６のパケット受信カウンタが所定の値に到達していない場合は、パケット受信とその後の処理（ステップ３０１〜３１０）を、パケット受信カウンタが所定の値に到達するまで繰り返す。

パケット受信カウンタが所定の値に到達すると、アドレス推定手段２０７は、ターゲット記憶手段２０５に登録した情報を用いて端末１０４のデフォルトゲートウェイＩＰアドレスの推定処理を行う（ステップ３１１）。

図７、図８は、本発明の実施の形態１におけるターゲット記憶手段の状態を示す図であり、ステップ３１１の時点におけるターゲット記憶手段２０５に登録されている情報を示したものである。

図７において、ＩＰアドレス「１０．２．２．１」のエントリは、端末１０４からのパケットをＡＲＰ要求パケットのターゲットＩＰアドレスとして受信したことを示し（ＡＲＰ受信フラグＯＮ）、宛先ＩＰアドレスとして設定されたパケットは受信しなかったこと（宛先ＩＰアドレスフラグＯＦＦ）を示している。

また、ＩＰアドレス「１０．２．２．１２」のエントリは、端末１０４からのパケットをＡＲＰ要求パケットのターゲットＩＰアドレスとして受信したことを示し、宛先ＩＰアドレスとして設定されたパケットを受信したことを示している。

また、ＩＰアドレス「２１０．１．２．３」エントリは、端末１０４からのパケットをＡＲＰ要求パケットのターゲットＩＰアドレスとして受信しなかったことを示し、宛先ＩＰアドレスとして設定されたパケットのみを受信したことを示している。

パケット解析手段２０４は、ＡＲＰ受信フラグがＯＮで、宛先ＩＰアドレスフラグがＯＦＦのエントリをデフォルトゲートウェイＩＰアドレスの候補として選択（推定）する。これは、端末１０４からデフォルトゲートウェイにＩＰパケットを直接送信することは稀であり、宛先ＩＰアドレスとしてデフォルトゲートウェイがあらわれにくいことに基づくものである。

図７に示すケースでは、ＩＰアドレス「１０．２．２．１」がデフォルトゲートウェイＩＰアドレスの候補として選択されることとなる。

設定手段２０８は、パケット解析手段２０４が選択したＩＰアドレスを通信装置１０２のＬＡＮ側ネットワークインタフェースのＩＰアドレスとして設定するため、ＳＤＲＡＭ５４に記憶されているＬＡＮ用モジュラージャック１４に対応するＩＰアドレスの情報を書き換える処理を行う（ステップ３１２）。そして、カウント手段２０６は、送信元ＩＰアドレスからのパケットのカウントを停止する（ステップ３１３）。

これ以後、通信装置１０２は、端末１０４からデフォルトゲートウェイＩＰアドレス宛のパケットを受信して中継することができるので、デフォルトゲートウェイとしての処理のみを行えば良く、通信装置１０２は本来受信し中継すべきパケットのみを受信可能となる。

以上のように実施の形態１によれば、通信装置１０２に静的なネットワーク情報が設定された（未知の）端末１０４が接続し、ネットワークが開始された際、端末１０４のデフォルトゲートウェイＩＰアドレスを推定し、通信装置１０２のネットワークインタフェースのＩＰアドレスとして設定できるようになる。よって、端末１０４側のネットワーク設定を変更せずに、端末１０４は通信装置１０２を第１のネットワーク１０３上のデフォルトゲートウェイとして利用することがでる。そして、通信装置１０２は、端末１０４からの不要なパケットを受信することなく効率良くパケットの転送を行うことができる。

なお、実施の形態１では、パケット解析の開始条件をパケットのカウント数に基づいて設定することとしたが、パケット解析の開始条件はこの設定条件に限定されるものではない。すなわち、端末１０４から最初のパケットを受信してからの経過時間に基づいてパケット解析の開始条件を設定しても良いし、パケット数と経過時間の組み合わせに基づいてパケット解析の開始条件を設定してもよい。

また、実施の形態１において、デフォルトゲートウェイＩＰアドレスを、ＡＲＰ受信フラグがＯＮで宛先ＩＰアドレスフラグがＯＦＦのエントリという条件で推定した結果、候補となるＩＰアドレスが複数となった場合（例えば、図８ケース）には、ゲートウェイとしてよく用いられる特異なＩＰアドレス（例えば、ＩＰアドレスの最下位バイトが最小値である１、または最大値である２５４であるもの）を選択する条件を追加してデフォルトゲートウェイＩＰアドレスを推定し、デフォルトゲートウェイＩＰアドレスの候補を絞ることとしても良い。この場合も、デフォルトゲートウェイＩＰアドレスを、ＡＲＰ受信フラグがＯＮで宛先ＩＰアドレスフラグがＯＦＦのエントリという条件で推定した場合（図７に示すケース）と同様の効果が得られる。

また、複数のデフォルトゲートウェイＩＰアドレスの候補が出た場合、設定手段２０８により全ての候補を通信装置１０２のネットワークインタフェースに設定することによっても、１つのデフォルトゲートウェイＩＰアドレスの候補を通信装置１０２のネットワークインタフェースに設定する場合と同様の効果が得られる。

さらに、通信装置１０２によって認識されたデフォルトゲートウェイＩＰアドレスを通信装置１０２に設けられたＷＥＢサーバ機能によって、ＷＥＢ画面などを通じてユーザ（端末１０４）に通知し、通信装置１０２に認識され設定されたデフォルトゲートウェイＩＰアドレスを端末１０４のユーザが確認できるようにしても良い。

（実施の形態２）
以下、実施の形態２について説明する。

通信装置１０２の装置構成については実施の形態１と同様である。

図９は、本発明の実施の形態２における通信装置の動作フローチャートである。

図９において、ステップ５０１〜５０７は、図６に示すステップ３０１〜３０７とそれぞれ同様であり、説明を省略する。

ステップ５０５において、端末１０４から受信したパケットがＡＲＰパケットでない場合（ステップ５０５、Ｎｏ）、パケット解析手段２０４は、端末１０４から受信したパケットがＴＣＰパケットやＵＤＰパケットであるか否かを判定する（ステップ５０８）。

端末１０４から受信したパケットがＴＣＰパケットまたはＵＤＰパケットである場合、パケット解析手段２０４は、宛先ポート番号が所定のアプリケーションのポート番号であるか否かを判定する（ステップ５０９）。所定のアプリケーションとは、例えばデフォルトゲートウェイでは動作させることのないアプリケーションを想定しており、このアプリケーション宛のパケットはデフォルトゲートウェイＩＰアドレス推定の対象外とする。

図１０は、本発明の実施の形態２における対象外とするアプリケーションに対応するポート番号を示す図であり、実施の形態２では図１０に示すように、アプリケーションのプロトコルとポート番号を用いる。

パケット解析手段２０４は、受信したパケットが図１０に示すような所定のアプリケーションのものであった場合、このパケットの宛先ＩＰアドレスとポート番号をターゲット記憶手段２０５に登録する（ステップ５１０）。

ステップ５０７、ステップ５１０の処理の後、カウント手段２０６は、パケット受信カウンタが所定の値に到達したか否かを確認する（ステップ５１１）。

カウント手段２０６が、パケット受信カウンタが所定の値に到達していない場合、パケット受信とその後の処理（ステップ５０１〜５１１）を、パケット受信カウンタが所定の値に到達するまで繰り返す。

パケット受信カウンタが所定の値に到達すると、アドレス推定手段２０７は、ターゲット記憶手段２０５に登録した情報を用いて端末１０４のデフォルトゲートウェイＩＰアドレスの推定処理を行う（ステップ５１２）。

図１１〜図１４は、本発明の実施の形態２におけるターゲット記憶手段の状態を示す図であり、ステップ５１２の時点で、ターゲット記憶手段２０５に登録されている情報を示している。

図１１において、ＩＰアドレス「１０．２．２．１」のエントリは、端末１０４からのパケットをＡＲＰ要求パケットのターゲットＩＰアドレスとして受信したことを示し（ＡＲＰ受信フラグＯＮ）、その後ＴＣＰパケットやＵＤＰのパケットを受信しなかったこと（ポート番号に登録なし）を示している。

また、ＩＰアドレス「１０．２．２．１２」のエントリは、端末１０４からのパケットをＡＲＰ要求パケットのターゲットＩＰアドレスとして受信したことを示し、ＤＮＳ（Ｄｏｍａｉｎ Ｎａｍｅ Ｓｙｓｔｅｍ）プロトコルのパケットであることを示すポート番号「５３」宛のパケットを受信したことを示している。

また、ＩＰアドレス「２１０．１．２．３」のエントリは、端末１０４からのパケットをＡＲＰ要求パケットのターゲットＩＰアドレスとして受信しなかったことを示し、宛先ポート番号として「８０」（ＨＴＴＰ）のパケットを受信したことを示している。

実施の形態１では、パケット解析手段２０４は、ＡＲＰ受信フラグがＯＮで、ＩＰアドレス宛の通信が示すアプリケーションが特定のものでないエントリをデフォルトゲートウェイＩＰアドレスの候補として選択（推定）する例を示した。

これは、デフォルトゲートウェイでは特定のサービスを行っていることが稀であることに着目した推定である。実施の形態１の方法では図１１のケースは、ＩＰアドレス「１０．２．２．１」がデフォルトゲートウェイＩＰアドレスの候補として選択されることとなる。

通信装置１０２の設定手段２０８は、パケット解析手段２０４が選択したＩＰアドレスをネットワークインタフェースのＩＰアドレスとして設定するため、ＳＤＲＡＭ５４に記憶されているＬＡＮ用モジュラージャック１４に対応するＩＰアドレスの情報を書き換える処理を行う（ステップ５１３）。そして、カウント手段２０６は、送信元ＩＰアドレスからのパケットのカウントを停止する（ステップ５１４）。

これにより、ＩＰアドレスが静的に設定された端末１０４を、通信装置１０２に接続する場合や、既に稼動しているネットワークに通信装置１０２を接続する場合に、ユーザが通信装置１０２のネットワーク設定をマニュアル的に行う必要なく、ネットワーク接続することが可能となる。

以上のように実施の形態２によれば、静的にＩＰアドレスを設定された端末１０４のデフォルトゲートウェイＩＰアドレスを推定し、通信装置１０２のネットワークインタフェースＩＰアドレスとして設定するので、第１のネットワーク１０３における端末１０４のデフォルトゲートウェイとしてこの通信装置１０２は機能し、端末１０４からの不要なパケットを受信することなく効率良くパケットの転送を行うことができる。

なお、本実施の形態２では、デフォルトゲートウェイＩＰアドレスを推定する条件の１つとして、受信したパケットの宛先が所定のサービスを示すポート番号宛のものであるＩＰアドレスを除外するようにしたが、これとは逆に、例えば図１２で示すように、デフォルトゲートウェイへのみ送信されるパケットを含む所定のサービスを示すプロトコルのパケットを検出できた場合（例えばＵＰｎＰ（Ｕｎｉｖｅｒｓａｌ Ｐｌｕｇ ａｎｄ Ｐｌａｙ）プロトコル）のゲートウェイを探索するパケットで、ポート番号が１９００であることにより判別することができる）、その宛先ＩＰアドレスである例えば「１０．２．２．１」をデフォルトゲートウェイのＩＰアドレスであると推定することによっても、受信したパケットの宛先が所定のサービスを示すポート番号宛のものであるＩＰアドレスを除外した場合と同様の効果が得られる。

また、実施の形態２では、デフォルトゲートウェイＩＰアドレスを推定した結果、デフォルトゲートウェイＩＰアドレスの候補を１つに絞ることができたが、図１３に示すように、候補となるＩＰアドレスが存在しなくなってしまった場合、デフォルトゲートウェイでサービスされることの多いアプリケーションのポート番号を持つものを候補選択のための条件として付加してもよい。例えば、ＤＮＳサービスは、ゲートウェイでプロキシさせて運用する場合多く、これをパケットの宛先ポート番号「５３」であることにより判別する。ここでは、宛先ＩＰアドレス「１０．２．２．１」を選択することによって、デフォルトゲートウェイＩＰアドレスの候補が１つに絞られた場合と同様の効果が得られる。

さらに、図１４のターゲット記憶手段２０５の状態で示すように、実施の形態２のアドレス推定手段２０７によって推定処理を行うと、デフォルトゲートウェイの候補となるＩＰアドレスが複数存在する場合もある。このような場合、ゲートウェイとしてよく用いられる特異なＩＰアドレス（例えば、ＩＰアドレスの最下位バイトが最小値である１、または最大値である２５４であるもの）を選択する条件を追加してデフォルトゲートウェイＩＰアドレスを推定してもよい。ここでは、デフォルトゲートウェイＩＰアドレスの候補を例えば「１０．２．２．１」に絞ることによって、デフォルトゲートウェイの候補となるＩＰアドレスが１つしか存在しない場合と同様の効果が得られる。

（実施の形態３）
以下、実施の形態３について説明する。

ルータ等の通信装置では、通常、ネットワークを開始する際に少なくともＩＰアドレスとサブネットマスクを必要とするが、ネットワークに接続する端末には、ＩＰアドレスやデフォルトゲートウェイＩＰアドレスやサブネットマスクが、通信機器の設定とは無関係に静的に設定されている場合がある。

このような端末を通信装置に接続した場合に、通信装置に設定されているサブネットマスクと端末に設定されているサブネットマスクとが異なっていることが原因で通信が不可能となる場合が発生する。

このような状況では、一般的には、ユーザが通信装置か端末の一方を他方の設定に合わせる操作が必要であり、ネットワークの設定に関する高度な知識が要求され、ユーザによっては非常に困難な作業である。

また、通信装置が端末のサブネットマスクの値を知る方法としては、ＲＦＣ（Ｒｅｑｕｅｓｔ Ｆｏｒ Ｃｏｍｍｅｎｔ）９５０に記載のＩＣＭＰ（Ｉｎｔｅｒｎｅｔ Ｃｏｎｔｒｏｌ Ｍｅｓｓａｇｅ Ｐｒｏｔｏｃｏｌ）のＴｙｐｅ１７のアドレスマスク要求を使用することが考えられる。例えば、特表２００５−５１３８３２号公報では、この方法をルータに応用し、ルータが端末にＩＣＭＰアドレスマスク要求を送信して、端末からネットワークに接続するために必要なパラメータを取得している。ただし、端末に搭載されているＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）によってはＩＣＭＰ要求に応答しない設定にされているものもあり、必ずユーザの手を煩わせずにサブネットマスク値を取得できるものではない。

実施の形態３の通信装置１０２を適用したネットワークシステムの構成は、実施の形態１の図１に示すものと同様である。

また、通信装置１０２のハードウェア構成についても、実施の形態１の図２〜図４に示したものと同様であり、説明を省略する。

図１５は、本発明の実施の形態３における通信装置の機能構成図である。

図１５において、１５１は、端末１０４からのパケットを受信する受信部である。１５２は、受信部１５１で受信したパケットのアドレス情報をもとに端末１０４と通信を試みて、通信が可能か否かにより、通信装置１０２に設定されているサブネットマスク値と、端末１０４に静的に設定されているサブネットマスク値が同一かどうかを判断する監視部である。

１５３は、通信装置１０２と端末１０４に静的に設定されているサブネットマスク値が異なっていた場合に、端末１０４に静的に設定されているサブネットマスク値を推定するため、端末１０４のサブネットマスク値の候補を算出し、サブネットマスク値の候補ごとに端末１０４からアクセスさせるための最大と最小のホストのＩＰアドレス（ホストアドレス）を算出するホストアドレス算出部である。

１５４は、ホストアドレス算出部１５３で作成したホストアドレスに端末１０４からアクセスがあった時の端末１０４から送信されるＡＲＰリクエストを監視し、また、その監視した情報から端末１０４に静的に設定されているサブネットマスク値を推定して通信装置１０２の設定に反映するサブネットマスク推定部である。

１５５は、推定したサブネットマスクをネットワーク機器に通知する等、通信装置１０２から端末１０４へパケットを送信する送信部である。１５６は、処理されるデータを記憶しておく記憶部である。

ここで、通信装置１０２のハードウェア構成（図４）と機能構成（図１５）との対応関係について説明する。

図４及び図１５において、受信部１５１は、ＬＡＮ用モジュラージャック１４、ＥＰＨＹ５６、ＥＭＡＣ５１ｃのハードウェア経路にて受信したパケットを、ＣＰＵ５１ａによって、ＳＤＲＡＭ５４上に格納することで実現される。

送信部１５５は、ＳＤＲＡＭ５４上に構成されたパケットを、ＣＰＵ５１ａによって、ＥＭＡＣ５１ｃ、ＥＰＨＹ５６、ＬＡＮ用モジュラージャック１４のハードウェア経路にて送信することで実現される。

監視部１５２、ホストアドレス算出部１５３、サブネットマスク推定部１５４、記憶部１５６は、いずれも、ＣＰＵ５１ａがＳＤＲＡＭ５４に記憶された各種の制御プログラムを読み出して実行すると共に、ＳＤＲＡＭ５４のデータ記憶領域に対してデータを記憶や読出を行う、あるいは記憶されたデータの解析などを行うことにより実現される。

なお、実施の形態３において、ＣＰＵ５１ａが実行する各種の制御プログラムは、汎用コンピュータ等でも利用可能であることは実施の形態１と同様である。

以上のように構成された通信装置の構成について、以下その動作を説明する。

図１６は、本発明の実施の形態３における通信装置の動作フローチャートであり、通信装置１０２が端末１０４のサブネットマスク値を推定する動作を示している。

図１６において、通信装置１０２が起動すると同時にステップ２０１よりフローを開始する。

ステップ２０２では、端末１０４からパケットが送信されてくるまで待機し、パケットを受信すると、そのパケットの情報から端末１０４のＩＰアドレスを取得する。

なお、通信装置１０２のＬＡＮ用モジュラージャック１４には、実施の形態１、２で示したように、端末１０４に静的に設定されている情報を取得し、端末１０４のデフォルトゲートウェイＩＰアドレスを割り当てることが望ましいが、実施の形態３の場合は、デフォルトゲートウェイＩＰアドレスの設定については、その他の公知の方法であっても良いし、ユーザがマニュアル的にネットワークの設定を行うような場合でも、サブネットマスク値のユーザの設定ミスを修正できるという点で、実施の形態３は有効である。

また、次のような方法を使用してもよい。

通信装置１０２の受信部１５１にはＤＮＳ（Ｄｏｍａｉｎ Ｎａｍｅ Ｓｙｓｔｅｍ）サーバ機能とＷＥＢサーバ機能があり、接続しようとしている通信装置１０２と無関係に、すなわち静的なネットワーク情報の設定がなされている端末１０４をあるユーザが通信装置１０２に接続したとする。

この時、端末１０４のユーザは、ネットワークへ接続できないことを知るとドメイン名に基づき通信装置１のＷＥＢサーバ上のコンテンツに対してアクセスを行う。

受信部１５１は、この時に送信されてくるパケットから端末１０４に静的に設定されているＩＰアドレスやデフォルトゲートウェイのＩＰアドレスの情報を取得する。受信部１５１は、ステップ２０２で受信したパケットの情報をもとに、通信装置１０２のＩＰアドレスを端末１０４に設定されているデフォルトゲートウェイのアドレスに設定する。

ステップ２０３で、監視部１５２は、ステップ２０２で取得した端末１０４のＩＰアドレスと通信機器１０２にあらかじめ設定されているサブネットマスク値をネットワーク情報として使用し、端末１０４に対して通信を試みてみる。通信が可能であればサブネットマスクの値は通信装置１０２と端末１０４で一致していると判断し、ステップ２０２で再度待機状態とする。

逆に、通信が不可能であった場合は、サブネットマスク値が通信装置１０２と端末１０４とで一致していないと判断し、ホストアドレス算出部１５３の処理へ移行する。

ここで、説明をわかりやすくするため、具体例を用いる。

端末１０４に設定されているＩＰアドレスが１０．７５．２１．１６５、サブネットマスクが２５５．２５５．２５４．０、デフォルトゲートウェイのＩＰアドレスが１０．７５．２０．１、通信装置１０２のＩＰアドレスは１０．７５．２０．１（端末１０４のデフォルトゲートウェイのＩＰアドレスにあわせた後のＩＰアドレス）と仮定する。

通信装置１０２は、ステップ２０２の段階では、端末１０４に設定されているＩＰアドレスやデフォルトゲートウェイのＩＰアドレスの情報は取得できているが、サブネットマスク値は取得できていない。

そこで、ステップ２０２で取得した端末１０４のＩＰアドレスから図１９に示すような、サブネットマスク値の使用ビット数とネットワークアドレス候補のリストを作成し、記憶部１５６に登録する。以下その様子について説明する。

ステップ２０４において、ホストアドレス算出部１５３は、ステップ２０２で取得した端末１０４のＩＰアドレスから、端末１０４がサブネットマスク値として撮り得る範囲を求める。図１７は、サブネットマスク値の範囲推定ルーチンを示すものである。

図１７に示すように、ステップ４０３、ステップ４０５、ステップ４０７において、ホストアドレス算出部１５３は、端末１０４のＩＰアドレスの先頭オクテットデータによる場合分けを行い、先頭オクテットデータが１〜１２７の場合は、クラスＡであると判断し、ステップ４０４に進み最小マスク値（サブネットマスクの最小のビット数）を８ビットとする。

先頭オクテットデータが１２８〜１９１の場合は、クラスＢであると判断し、ステップ４０６に進み最小マスク値を１６ビットとする。

先頭オクテットデータが１９２〜２２３の場合は、クラスＣであると判断し、ステップ４０８に進み最小マスク値を２４ビットとする。

前述の具体例の場合、ＩＰアドレスの先頭オクテットデータが１０であるので、最小マスク値は８ビットであるとなる。

次に、ホストアドレス算出部１５３は、ステップ４０９で、最大マスク値を求める。

図１８は、最大マスク値の推定ルーチンを示すものである。実施の形態３では、ステップ８０４で、最大マスク値は、固定値である３０とする。なお、ステップ８０３〜８０５の処理は、実施の形態４で詳しく説明する。

実施の形態３で最大マスク値を３０とする理由は、ネットワークを構成するためにはホストアドレスは最低２ビット必要であり、３０（＝３２−２）としている。

以上から、前述の具体例の場合、ホストアドレス算出部１５３は、図１７のステップ４１０で、サブネットマスク値のビット数の範囲は、８ビットから３０ビットであることを確定する。

図１６に戻り、ステップ２０５で、ホストアドレス算出部１５３は、ステップ４１０で確定した範囲のサブネットマスク値の各ビット数に対して、図１９に示すようにネットワークアドレスを定義し、ステップ２０６において、各ネットワークアドレスに対して、同じく図１９に示すようにホストアドレス１とホストアドレス２を定義し、記憶部１５６に記憶させる。

ホストアドレス１は、それぞれのネットワークアドレスに属するホストアドレスの最大値、つまり当該ネットワークアドレスをもつＩＰアドレスのホストアドレス部のビットがすべてＦとなるアドレスから１を引いたアドレスとする。

ホストアドレス２は、それぞれのネットワークアドレスに属するホストアドレスの最小値、つまり当該ネットワークアドレスをもつＩＰアドレスのうちホストアドレス部のビットがすべて０のアドレスから１を足したアドレスとする。

作成されたホストアドレスのリスト（図１９）から、通信装置１０２あるいは端末１０４のＩＰアドレスであるものを除外し、重複しているものは１つとみなすと、図２１に示すホストアドレス候補が作成され、記憶部１５６に登録される。

ステップ２０７で、サブネットマスク推定部１５４は、端末１０４から図２１に示す候補に対して（１）から順に、すなわちサブネットマスク値の使用ビット数が大きい方から順にアクセスさせるよう制御する。

なお、アクセス方法としては、通信装置１０２から端末１０４に対して自動実行するスクリプトを渡す方法や、通信装置１０２がＷＥＢサーバ機能を備え、ＷＥＢ上にＨＴＭＬ等により各候補に対するリンクを設定しておき、端末１０４のユーザが、画面表示をみながら操作させることにより、アクセスするという方法などが考えられる。

サブネットマスク値の大きい方からアクセスさせるため、上記の方法では、スクリプトで制御したり、ユーザにアクセスさせる場合には、ホストアドレス候補毎に表示したり、アクセス順序を併せて表示する等の処理を行う。

また、サブネットマスク値の大きい（１）からアクセスさせる理由としては、ＡＲＰリクエストが送信される可能性が高いものからアクセスを実施し、ＡＲＰリクエスト送信のタイムアウト時間まで待つケースを減らし、推定に要する時間を短くするためである。さらに、端末１０４からのＡＲＰリクエストを外部のネットワークに流出することを抑制することもできる。

例えば、サブネットマスク値の使用ビット数が３０である（１）にアクセスさせると、サブネットマスク値の使用ビット数が２９以下となるサブネットにも属するため、求めるべき実際のサブネットマスクの使用ビット数が２９以上である場合にも、ＡＲＰリクエストが送信される。

逆に（２４）からアクセスさせる（サブネットマスク値の使用ビット数が少ない順にアクセスさせる）と、そのＩＰアドレスよりサブネットマスク値の使用ビット数が大きい場合には、ＡＲＰリクエストの送信が無い可能性が高く、タイムアウト時間まで待つケースが多くなる。

次に、サブネットマスク推定部１５４は、ステップ２０８において、ステップ２０７で（１）から順にアクセスさせた各候補について、ＡＲＰリクエストのパケット到着の有無でその候補のＩＰアドレスが、端末１０４に設定されたサブネットの範囲であるかどうかの判定を行う。

ＡＲＰリクエストが受信される、つまり、端末１０４からＡＲＰリクエストが送信されるということは、端末１０４は、そのホストアドレス候補が端末１０４に静的に設定されているサブネットの範囲内であると判断していることがわかる。なお、端末１０４のＡＲＰテーブルは、本処理の開始前にはクリアされているものとする。図２０に示すように、通信装置１０２において各ホストアドレス候補に対してＡＲＰリクエストやＩＰパケットの受信をリストとして記憶部１５６に保持するようにしてもよい。

前述の具体例の場合、図２１に示すように、（９）の候補までは、端末１０４からＡＲＰリクエストが送信され通信装置１０２によってそれを受信できるが、（１０）の候補では、ＡＲＰリクエストが端末１０４から送信されない。（１０）の候補では、端末１０４に設定されているサブネットマスク値の範囲外となったため、端末１０４は他のネットワークに存在するホストであると判断し、ＡＲＰリクエストを送信せずにデフォルトゲートウェイに対してアクセスを試みるためである。

サブネットマスク推定部１５４は、ステップ２０８においてＡＲＰリクエストが未受信となると、ステップ２０９に進み、ステップ２０７のアクセスによって最後にホストアドレス１、ホストアドレス２ともにＡＲＰリクエストが送信されたのは（９）であるため、図２０から、そのホストアドレスのマスク値ビット数、つまり２３ビットが端末１０４に静的に設定されているサブネットマスク値であると推定する。

上記のようにサブネットマスク値の大きい方から順にアクセスする場合には、ホストアドレスに対してＡＲＰリクエストが送信されなくなった時のマスク値のビット数に１を加えた値が端末１０４に静的に設定されているマスク値のビット数であると推定する。

ステップ２０９でマスク値を推定後は、図１６に示すようにステップ２１０に進む、つまり（１０）以降の候補に関してはステップ２０７の端末１０４からのアクセスを実施しないようにしてもよい。

サブネットマスク推定部１５４は、このようにして推定したサブネットマスク値をステップ２１０において通信装置１０２のネットワーク設定に反映するため、ＳＤＲＡＭ５４に記憶されているサブネットマスク値を書き換える。これにより、端末１０４の設定を変更することなく、サブネットマスク値に起因する通信トラブルを回避し、通信を可能にすることができる。

ステップ２１１では、送信部１０５は、推定したサブネットマスクの値を端末１０４に通知する。これにより、端末１０４のユーザは、通信装置１０２のネットワーク設定が終了し、通信可能になったことを確認することができる。

なお、サブネットマスク値の推定に失敗した場合は、通信装置１０２で取得した端末１０４のＩＰアドレスの先頭オクテットデータが１から１２７の場合はマスク値を８ビット、１２８から１９１の場合はマスク値を１６ビット、１９２から２２３の場合は２４ビットと判断し、これらを推定値とする。

なお、実施の形態３では、サブネットマスク値の大きいホストアドレスもの、すなわち図２１の（１）から順にステップ２０７の処理を行ったが、サブネットマスク値の小さいホストアドレスから順にステップ２０７の処理を行ってもサブネットマスク値の推定は可能である。

また、サブネットマスク値の大小を問わずランダムにアクセスし、ＡＲＰリクエストを受信できないものを検出した場合は、その前後のサブネットマスク値を調べ、ＡＲＰリクエストを受信できるマスク値と受信できないマスク値の境界を探してもよい。

また、１１ホストアドレス算出部１５３が、ステップ２０４で算出したサブネットマスク値の候補が１つであった場合には、ステップ２０５〜２０９の処理を行わずにステップ２１０以降を実行しても良い。

第１のネットワーク１０３で通信装置１０２と接続する端末として、当該端末が端末１０４のネットワーク設定と同一の設定であるときは、端末１０４について行われた上記の処理により、他の端末も通信装置１０２と通信可能になる。

また、第１のネットワーク１０３で通信装置１０２と接続する端末として、当該端末が端末１０４と異なる場合には、当該端末について、別の仮想ＬＡＮを構築し、端末１０４に対するのと同様の手順で通信装置１０２のＩＰアドレス、サブネットマスクをそれぞれの仮想ＬＡＮに設定する。

以上のように実施の形態３によれば、通信装置１０２が端末１０４に静的に設定してあるサブネットマスク値を推定することが可能となり、この推定値を通信装置１０２のネットワーク設定に反映することで、端末１０４の静的な設定を変更することなしに通信装置１０２と端末１０４との通信が可能となる。

（実施の形態４）
以下、本発明の実施の形態４について説明する。

実施の形態４が実施の形態３と相違する点は、ホストアドレス算出部１５３が、ステップ２０４において端末１０４のＩＰアドレスからサブネットマスクの範囲を求めるにあたって、最大マスク値をさらに絞り込む手法を取り入れた点である。

これにより、ホストアドレス算出部１５３で算出されるホストアドレスの候補数を減らすことが可能となり、端末１０４に静的に設定されているサブネットマスクの推定に要する時間を短縮できるだけでなく、推定が完了するまでに端末１０４から第１のネットワーク１０３に送信されるパケット数を減らすことが可能となる。

ここで、実施の形態３と同様に通信装置１０２のＩＰアドレスが１０．７５．２０．１、端末１０４のＩＰアドレスが１０．７５．２１．１６５であったと仮定する。

実施の形態４では、図１８においてステップ８０４ではなく、ステップ８０３、ステップ８０５を実行する。

ステップ８０３において、ホストアドレス算出部１５３は、図２２に示すように、通信装置１０２と端末１０４のＩＰアドレスの先頭からの共通部分を求める。

２つのＩＰアドレスから共通するビットが２３ビットであるため、最低９ビットがホスト部として必要であることがわかる。つまり、２３ビット以下の値が通信装置１０２および端末１０４がネットワークを構成するために必要なサブネットマスク値のビット数と推定できる。

これにより、実施の形態４の場合、図２０の候補のうち、マスク値が２４ビットから３０ビットの候補に関しては除外できる。なお、このようにして算出されたマスク値が１つの場合は、その値を推定値とする。

以上のように実施の形態４によれば、通信装置１０２が端末１０４に静的に設定されているサブネットマスクの値を推定するにあたり、マスク値の推定範囲を絞ることで端末１０４に静的に設定されているサブネットマスク値を推定するまでに要する時間の短縮と、端末１０４から第１のネットワーク１０３に送信されるパケットを減らす効果が得られる。

本発明に係る通信装置、通信装置の制御方法、及び通信装置の制御プログラムは、異なるネットワーク間の通信を中継するルータ、あるいはルータ機能を有する装置に利用可能である。

本発明の実施の形態１における通信装置を適用したネットワークシステムの構成図 本発明の実施の形態１における通信装置の外観斜視図 本発明の実施の形態１における通信装置の外観斜視図 本発明の実施の形態１における通信装置のハードウェア構成図 本発明の実施の形態１における通信装置の機能構成図 本発明の実施の形態１における通信装置の動作フローチャート 本発明の実施の形態１におけるターゲット記憶手段の状態を示す図 本発明の実施の形態１におけるターゲット記憶手段の状態を示す図 本発明の実施の形態２における通信装置の動作フローチャート 本発明の実施の形態２における対象外とするアプリケーションに対応するポート番号を示す図 本発明の実施の形態２におけるターゲット記憶手段の状態を示す図 本発明の実施の形態２におけるターゲット記憶手段の状態を示す図 本発明の実施の形態２におけるターゲット記憶手段の状態を示す図 本発明の実施の形態２におけるターゲット記憶手段の状態を示す図 本発明の実施の形態３における通信装置の機能構成図 本発明の実施の形態３における通信装置の動作フローチャート 本発明の実施の形態３における通信装置の動作フローチャート 本発明の実施の形態３における通信装置の動作フローチャート 本発明の実施の形態３における記憶部のテーブルを示す図 本発明の実施の形態３における記憶部のテーブルを示す図 本発明の実施の形態３における記憶部のテーブルを示す図 本発明の実施の形態４における最大マスク値に関する説明図

符号の説明

１０１ 第２のネットワーク
１０２ 通信装置
１０３ 第１のネットワーク
１０４、１０５、１０６ 端末
１５１ 受信部
１５２ 監視部
１５３ ホストアドレス算出部
１５４ サブネットマスク推定部
１５５ 送信部
１５６ 記憶部

Claims (14)

1. 第１のネットワークと第２のネットワークとの間のデータ通信を中継する通信装置であって、
   第１のネットワーク接続用のインターフェースを有し、第１のネットワークに接続された端末からのパケットを受信する受信手段と、
   前記受信手段で受信したパケットから端末のＩＰアドレスを取得し、当該ＩＰアドレスに基づいて端末が取り得るサブネットマスク値の範囲を求めると共に、各サブネットマスク値に対応するホストアドレスの候補を求め、当該ホストアドレス候補を端末からアクセス可能に設定し、端末からのホストアドレス候補へ送信されるパケット状態に基づいて端末のサブネットマスク値の推定値を決定し、当該推定値を第１のネットワーク接続用のインターフェースに対応したサブネットマスク値として設定する制御手段と、を有し、
   前記制御手段は、端末からのホストアドレス候補へ送信されるパケット状態として、端末からのＡＲＰリクエストの送信の有無をチェックする、ことを特徴とする通信装置。
2. 前記制御手段は、サブネットマスク値に対応するホストアドレスの候補は、サブネットマスク値から定義されるネットワークアドレスに属する最大及び最小のホストアドレスとする、ことを特徴とする請求項１記載の通信装置。
3. 前記制御手段は、ＡＲＰリクエストの送信のあったホストアドレスと、ＡＲＰリクエストの送信の無かったホストアドレスの境界を求め、その境界においてＡＲＰリクエストの送信があったホストアドレスのマスク値を推定値とする、ことを特徴とする請求項１記載の通信装置。
4. 前記制御手段は、サブネットマスク値に対応するホストアドレスの候補に、端末からアクセス可能に設定する際、サブネットマスク値の使用ビット数が大きいものからアクセスさせる、ことを特徴とする請求項１記載の通信装置。
5. 前記制御手段は、ホストアドレス候補のうち、ＡＲＰリクエストが送信されなくなったホストアドレスのマスク値に１加えたマスク値を推定値とする、ことを特徴とする請求項４記載の通信装置。
6. 前記制御手段は、端末が取り得るサブネットマスク値の範囲を求める際、その最小値は、端末のＩＰアドレスの先頭オクテットデータに基づいて決定する、ことを特徴とする請求項１記載の通信装置。
7. 前記制御手段は、端末が取り得るサブネットマスク値の範囲を求める際、その最大値は３０ビットとする、ことを特徴とする請求項１記載の通信装置。
8. 前記制御手段は、端末が取り得るサブネットマスク値の範囲を求める際、その最大値は、端末のＩＰアドレスと自身に設定されているＩＰアドレスとの先頭からの共通ビット数とする、ことを特徴とする請求項１記載の通信装置。
9. 前記制御手段は、サブネットマスク値に対応するホストアドレスの候補から、重複したものは除外し、当該ホストアドレス候補を端末からアクセス可能に設定する、ことを特徴とする請求項１記載の通信装置。
10. 前記制御手段は、サブネットマスク値に対応するホストアドレスの候補から、自身と端末の有するＩＰアドレスと一致するものは除外し、当該ホストアドレス候補を端末からアクセス可能に設定する、ことを特徴とする請求項１記載の通信装置。
11. 前記制御手段は、端末が取り得るサブネットマスク値の範囲を求めた結果、１つであった場合、当該サブネットマスク値を、第１のネットワーク接続用のインターフェースに対応したサブネットマスク値として設定する、ことを特徴とする請求項１記載の通信装置。
12. 前記制御手段は、サブネットマスク値が得られない場合、端末のＩＰアドレスの先頭オクテットデータが１〜１２７であれば８ビット、１２８〜１９１であれば１６ビット、１９２〜２２３であれば２４ビットとして、第１のネットワーク接続用のインターフェースに対応したサブネットマスク値として設定する、ことを特徴とする請求項１記載の通信装置。
13. 第１のネットワークと第２のネットワークとの間のデータ通信を中継する通信装置の制御方法であって、
    第１のネットワークに接続された端末からのパケットを受信するステップと、
    前記受信したパケットから端末のＩＰアドレスを取得し、当該ＩＰアドレスに基づいて端末が取り得るサブネットマスク値の範囲を求めると共に、各サブネットマスク値に対応するホストアドレスの候補を求めるステップと、
    当該ホストアドレス候補を端末からアクセス可能に設定し、端末からのホストアドレス候補へ送信されるパケット状態に基づいて端末のサブネットマスク値の推定値を決定するステップと、
    当該推定値を第１のネットワーク接続用のインターフェースに対応したサブネットマスク値として設定するステップと、を有し、
    前記設定するステップにおいて、端末からのホストアドレス候補へ送信されるパケット状態として、端末からのＡＲＰリクエストの送信の有無をチェックする、ことを特徴とする通信装置の制御方法。
14. 第１のネットワークと第２のネットワークとの間のデータ通信を中継する通信装置の制御プログラムであって、
    第１のネットワークに接続された端末からのパケットを受信するステップと、
    前記受信したパケットから端末のＩＰアドレスを取得し、当該ＩＰアドレスに基づいて端末が取り得るサブネットマスク値の範囲を求めると共に、各サブネットマスク値に対応するホストアドレスの候補を求めるステップと、
    当該ホストアドレス候補を端末からアクセス可能に設定し、端末からのホストアドレス候補へ送信されるパケット状態に基づいて端末のサブネットマスク値の推定値を決定するステップと、
    当該推定値を第１のネットワーク接続用のインターフェースに対応したサブネットマスク値として設定するステップと、を有し、
    前記設定するステップにおいて、端末からのホストアドレス候補へ送信されるパケット状態として、端末からのＡＲＰリクエストの送信の有無をチェックする、ことを特徴とする通信装置の制御プログラム。

Images