JP5805575B2 - 中継装置、中継方法及び中継プログラム - Google Patents

Description

本発明の実施形態は、中継装置、中継方法及び中継プログラムに関する。

一般に、インターネットプロトコルを用いたネットワーク（ＩＰ網）は、様々な物理的なネットワーク媒体の上に構築可能なように設計されている。この物理的なネットワーク媒体には、例えば、ケーブルや無線などがある。ＩＰ網を特定のネットワーク媒体の伝送方式に依存しない形態で構築可能とするために、物理的なネットワーク媒体は、「リンク層」と呼ばれる概念で抽象化されたインタフェースを介して上位のＩＰ層から利用できるようにモデル化される。インターネットプロトコルのプロトコルモデルは、下位層にリンク層が位置づけられ、そのリンク層の上にＩＰ層が位置付けられる概念で表される。

このようなＩＰ網において、データは、ＩＰパケットと呼ばれるデータの塊としてノード間を送受信される。所定のノードが大きなデータを送る場合には、必要に応じてデータは複数のＩＰパケットに分割されて送受信される。所定のネットワーク媒体上のＩＰ網に接続された２つのノード間でＩＰパケットが送受信される場合、これらの２つのノード間は、概念的な「リンク」によって結ばれる。一般に、かかるリンクには、１つのＩＰパケット相当で送信することができるデータの塊の最大サイズが定められる。かかるデータの最大サイズは、ネットワーク媒体（リンク層）で用いる通信プロトコルのパラメータとして表現可能である。このようなリンクが許容可能なデータの最大サイズは、一般にＭＴＵ（Maximum Transfer Unit）値と呼ばれる。

ところで、複数のＩＰ網は、ルータにより相互接続される。ルータはケーブルや無線など様々なネットワーク媒体のリンクを介して複数のＩＰ網に接続し、ＩＰパケットをＩＰ網間で中継するノードの一種である。このようにルータによって相互接続されたＩＰ網の集合体は、インターネットと呼ばれる。

ここで、所定のネットワーク媒体上に構築されたＩＰ網に接続しているノードＡが、別のネットワーク媒体上に構築されたＩＰ網に接続しているノードＢと通信する場合について検討する。例えば、ノードＡ及びＢのそれぞれが接続する２つのＩＰ網が同一の１つのルータに接続している場合には、かかるルータは、ノードＡからノードＢ宛に送信されたＩＰパケットを中継することができる。また、ノードＡが接続するＩＰ網とノードＢが接続するＩＰ網の間に複数のルータと、かかる複数のルータ間を結ぶ複数のリンクが存在する場合にも、ノードＡからノードＢまでの経路上に存在する各ルータがＩＰパケットを中継することにより、ノードＡとノードＢとの間における通信が可能となる。

上記例において、ノードＡからノードＢへ到達する経路上にある複数のリンクには、それぞれのネットワーク媒体で用いる通信プロトコルに関係付けられたＭＴＵ値が定められている。そのため、ノードＡからノードＢへＩＰパケットを転送する場合、かかるＩＰパケットのサイズは、ノードＡからノードＢまでの経路上に存在する各リンクのＭＴＵ値のいずれも超えないことが求められる。すなわち、ノードＡは、ノードＢにＩＰパケットを送信する場合に、ノードＡからノードＢまでの経路を構成するリンク全体の中で、最も小さいＭＴＵ値以下のサイズでＩＰパケットを送信することが求められる。このような所定の経路上の全リンクにおける最小のＭＴＵ値は、その経路に対する「経路ＭＴＵ値」と呼ばれる。

インターネットプロトコルでは、所定の宛先ノードへの経路ＭＴＵ値を発見するための手順が経路ＭＴＵ探索（Path MTU Discovery）として標準的に定められている。インターネットプロトコル・バージョン４（IPv4）における経路ＭＴＵ探索はＲＦＣ（Request for Comments）１１９１に定義されており、インターネットプロトコル・バージョン６（IPv6）の経路ＭＴＵ探索はＲＦＣ１９８１に定義されている。なお、ＲＦＣ１９８１は、ＲＦＣ１１９１から派生したものである。

ＩＰｖ６の経路ＭＴＵ探索における手順の概略を説明すると、ＩＰパケットの送信元ノードは、かかるノード自身が接続しているネットワーク媒体（リンク）のＭＴＵ値を初期の経路ＭＴＵ値と仮定してＩＰパケットを送信する。このＩＰパケットは、宛先ノードに届くまでに経路上のルータとリンクを経由する。このとき、経路の途中のあるリンクのＭＴＵ値がＩＰパケットのサイズよりも小さい場合、すなわちＩＰパケットのデータサイズがリンクのＭＴＵ値を超過した場合には、かかるリンクに接続するルータは、ＩＰパケットを破棄し、送信元ノードに対してパケット過大メッセージ（Packet Too Big messages）を返送する。このようなパケット過大メッセージのフォーマットと通信手順については、ＲＦＣ４４４３に定義されている。

パケット過大メッセージには、ＩＰパケットのサイズが超過したＭＴＵ値であって、メッセージを送出するルータが接続しているリンクのＭＴＵ値が含まれる。パケット過大メッセージが送信元ノードまで転送されることにより、かかる送信元ノードは、宛先ノードまでの経路の途中に初期に仮定した経路ＭＴＵ値よりも小さいＭＴＵ値が定められているリンクが存在することを識別できる。さらに、送信元ノードは、パケット過大メッセージに含まれるＭＴＵ値にＩＰパケットのサイズを変更して再送信することにより、少なくともパケット過大メッセージを返送したルータがかかるリンクを介して接続する次のノードまでＩＰパケットを到達させることができる。送信元ノードは、このような処理を繰り返すことにより、最終的には宛先ノードにＩＰパケットを到達させることができる。

ＲＦＣ１９８１には、ＩＰｖ６を使用するノードは経路ＭＴＵ探索を実装すべきであると記載されているが、必須要件ではない。また、ＲＦＣ１９８１には、経路ＭＴＵ探索を実装しないノードはＩＰｖ６の到達保障されている最小ＭＴＵ値を経路ＭＴＵ値として用いると記載されている。一方、ＲＦＣ２４６０のＩＰｖ６仕様では、ＩＰｖ６を使用するノードは最小のＭＴＵ値を１２８０オクテット（Octets）とするように定められている。そのため、経路ＭＴＵ探索を実装しないノードは常に経路ＭＴＵ値を１２８０オクテットとしてＩＰパケットを送信することになる。

以上述べたような経路ＭＴＵ探索の手順が存在する一方で、ＲＦＣ４８６１には、ルータが、ルータ自身が接続しているリンクと同一リンクに接続するノード全てに対して、かかるリンクのＭＴＵ値を広告する仕組みが記載されている。ＲＦＣ４８６１はＩＰｖ６の近隣発見プロトコル（Neighbor Discovery Protocol）に関する標準であり、あるノードが同一ネットワーク媒体（リンク）に接続している他ノード群を発見し、他ノードに関する情報を収集して通信可能にするための手順について定義したものである。

かかるＲＦＣ４８６１には、近隣発見プロトコルに関して、ルータがルータ自身の存在や通信設定に関する情報を同一リンクに接続しているノードに対して広告するためのルータ広告メッセージの仕様が定められており、そのメッセージのオプションとしてリンクのＭＴＵ値を含めることができると記載されている。ルータは、ＭＴＵオプションを用いることにより、同一リンクに接続する他ノードによって使用されることが推奨されるＭＴＵ値を指定することができる。したがって、ルータ広告メッセージのＭＴＵオプションを使用した場合、同一リンクに接続している各ノード間においては、各ノードが経路ＭＴＵ探索を行うことなく、ルータによって指定されたＭＴＵ値によりＩＰパケットを送信することが可能である。

なお、ＲＦＣ４８６１には、近隣発見プロトコルを実施する際に、ＩＰｖ６のノードに搭載されることが考えられる概念的な機能について記載されている。それらの機能のうち経路ＭＴＵ探索に関するものとして、近隣キャッシュ（Neighbor Cache）と宛先キャッシュ（Destination Cache）がある。近隣キャッシュは、所定のノードが直接接続しているリンク毎に、かかるリンク上に接続している他ノードに関する情報を一時的に蓄えておくためのキャッシュである。宛先キャッシュは、所定のノードが最近通信した宛先ノードに関する情報を一時的に蓄えておくためのキャッシュである。ＲＦＣ４８６１では、宛先キャッシュに宛先ごとの経路ＭＴＵ値を含めることも可能であると記載されている。

また、ＲＦＣ１１９１の経路ＭＴＵ探索の仕組みを用いて発見した経路ＭＴＵ値を宛先ノード毎にキャッシュしておき、その後に同一の宛先ノードへの通信が発生した際に、キャッシュ情報を用いることで、経路ＭＴＵ探索を行うことなく宛先ノードまでＩＰパケットを到達させる技術については、一般に知られている。

特開２００７−１８０６８６号公報 特開平１１−１６８４９２号公報

J.Mogul et al, "Path MTU Discovery", Network Working Group, RFC1191, November 1990, ［online］,［平成２３年１１月７日検索］、インターネット＜http://tools.ietf.org/html/rfc1191＞ J.McCann et al, "Path MTU Discovery for IP version 6", Network Working Group, RFC1981, August 1996, ［online］,［平成２３年１１月７日検索］、インターネット＜http://tools.ietf.org/html/rfc1981＞ S.Deering et al, "Internet Protocol, Version 6 (IPv6) Specification", Network Working Group, RFC2460, December 1998, ［online］,［平成２３年１１月７日検索］、インターネット＜http://tools.ietf.org/html/rfc2460＞ A.Conta et al, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", Network Working Group, RFC4443, March 2006, ［online］,［平成２３年１１月７日検索］、インターネット＜http://tools.ietf.org/html/rfc4443＞ T.Narten et al, "Neighbor Discovery for IP version 6 (IPv6)", Network Working Group, RFC4861, September 2007, ［online］,［平成２３年１１月７日検索］、インターネット＜http://tools.ietf.org/html/rfc4861＞

しかしながら、上記の従来技術には、各ノードが適切な経路ＭＴＵ値を用いて通信を行えない場合があった。具体的には、経路ＭＴＵ探索において、ルータによって返送されるパケット過大メッセージは、送信元ノードに到達しない場合がある。例えば、ルータが経路ＭＴＵ探索の仕組みを具備していない場合や、ルータと送信元ノードとの間における途中のルータが経路ＭＴＵ探索の仕組みを具備していない場合や、ファイアフォール等の関係でパケット過大メッセージが途中のルータに到達しない場合などに、パケット過大メッセージは、送信元ノードに到達しない場合がある。このような場合には、送信元ノードは、宛先ノードに対する適切な経路ＭＴＵ値を取得することができないので、適切な経路ＭＴＵ値を用いて宛先ノードとの間で通信することができないという問題があり、ＭＴＵブラックホール問題、パスＭＴＵブラックホール問題などと呼ばれている（以下、このような問題を「ブラックホール問題（またはＢＨ問題）」という）。

なお、上記の通り、ＩＰｖ６では、経路ＭＴＵ探索では検知不能なパケット過大による通信不能を回避するために、送信元ノードが予めＩＰｖ６の最小ＭＴＵ値である１２８０オクテットをデフォルトの経路ＭＴＵ値として使用することも考えられる。しかし、全ての宛先ノードに対して最小ＭＴＵ値である１２８０オクテットをデフォルトとして適用することは、実際には経路ＭＴＵ値が１２８０オクテットよりも大きい宛先ノードに対しても１２８０オクテットであるＩＰパケットのサイズでデータを送信することになるので、通信効率が悪くなるという問題が発生する。

また、送信元ノードが、上記の宛先キャッシュを使用した場合には、既に通信が成功している宛先ノードに対して、経路ＭＴＵ探索の仕組みを使うことなく適切な経路ＭＴＵ値を選択することが可能になるとも考えられる。しかし、宛先キャッシュを用いた従来技術であっても、通信が成功するまでは各ノードが経路ＭＴＵ探索を用いることになるので、パケット過大メッセージが送信元ノードに到達しないことで各ノードが適切な経路ＭＴＵ（またはＰａｔｈ ＭＴＵ、ＰＭＴＵ）値を用いて宛先ノードとの間で通信を行えないという問題を解消することができない。

また、送信元装置から通信を受けたＬＡＮ側の中継装置が、宛先装置と通信する前に、宛先装置に対して事前確認通信を試みて適当なＰＭＴＵを確認して、送信元端末にこのＰＭＴＵの値で通信させる技術がある。しかし、宛先毎に適当なＰＭＴＵを確認する処理などが必要であり、送信データサイズを変えて事前確認通信を繰り返すため、適当なＰＭＴＵを特定するまでに相当の時間を要し、通信効率が悪くなるという問題が発生する。

また、インターネット上のルータ間で、経路情報の交換とともに、ルータが把握している宛先となり得る宛先装置までのＰＭＴＵ情報を交換して、宛先装置までの最適なＰＭＴＵを送信元装置に通知する技術がある。しかし、対処できるのは通知を受けた所定の宛先装置との通信のみであり、かつ、既存のインターネット上の各ルータの構成に手を加えなければならないという問題が発生する。

本願の開示する技術は、上記に鑑みてなされたものであって、適切に通信を行うことができる経路ＭＴＵ値で、効率的に通信を行うことができる中継装置、中継方法及び中継プログラムを提供することを目的とする。

実施形態に係る中継装置は、広域通信網とローカル通信網との間で通信を中継する中継装置であって、前記ローカル通信網側の端末から前記広域通信網側の端末へのデータ送信に対する応答を監視する監視部と、前記監視部による監視に基づいて所定の時間以内に応答が返ってきたかを判定する判定部と、前記判定部によって所定の時間以内に応答がないと判定された場合には、予め記憶された１回に転送可能なデータ容量であって前記データ送信時のデータ容量よりも小さいデータ容量である転送可能容量を指示するメッセージを生成し、該メッセージを前記ローカル通信網側の端末に通知する通知部とを有することを特徴とする中継装置。

実施形態に係る中継装置、中継方法及び中継プログラムは、適切に通信を行うことができる経路ＭＴＵ値で、効率的に通信を行うことができるという効果を奏する。

図１は、第一の実施の形態に係るネットワークシステムの構成例を示す図である。 図２は、第一の実施の形態に係るゲートウェイの構成例を示す図である。 図３は、第一の実施の形態における記憶部に記憶されたデータの一例を示す図である。 図４は、第一の実施の形態における記憶部に記憶されたデータの一例を示す図である。 図５は、第一の実施の形態における記憶部に記憶されたデータの一例を示す図である。 図６は、第一の実施の形態に係るネットワークシステムによる処理手順を示すシーケンス図である。 図７は、第一の実施の形態に係るゲートウェイによる処理手順を示すフローチャートである。 図８は、第一の実施の形態に係るゲートウェイによる処理手順を示すフローチャートである。 図９は、第二の実施の形態に係るゲートウェイの構成例を示す図である。 図１０は、第二の実施の形態における記憶部に記憶されたデータの一例を示す図である。 図１１は、第二の実施の形態における記憶部に記憶されたデータの一例を示す図である。 図１２は、第二の実施の形態に係るネットワークシステムによる処理手順を示すシーケンス図である。 図１３は、第二の実施の形態に係るゲートウェイによる処理手順を示すフローチャートである。 図１４は、第三の実施の形態に係るネットワークシステムによる処理手順を示すシーケンス図である。 図１５は、第三の実施の形態に係るゲートウェイによる処理手順を示すフローチャートである。 図１６は、その他のゲートウェイによる処理手順を示すフローチャートである。 図１７は、中継プログラムを実行するコンピュータを示す図である。

以下に、本願に係る中継装置、中継方法及び中継プログラムの実施例を図面に基づいて詳細に説明する。なお、この実施例により本願に係る中継装置、中継方法及び中継プログラムが限定されるものではない。

［第一の実施の形態に係るネットワークシステムの構成］
まず、図１を用いて、第一の実施の形態に係るネットワークシステムについて説明する。図１は、第一の実施の形態に係るネットワークシステムの構成例を示す図である。

図１に例示するように、第一の実施の形態に係るネットワークシステム１００には、端末２０Ａ、２０Ｂ等を含むＬＡＮ（Local Area Network）４０と、端末２０Ｃやルータ３０を含むＷＡＮ（Wide Area Network）５０とが存在し、ＬＡＮ４０とＷＡＮ５０との間には通信を中継するゲートウェイ１０が存在する。なお、以下の説明では、イーサネット（登録商標）上のＩＰｖ６通信を前提とするが、本発明はこれに限定されるものではない。また、レイヤ３は例えばＩＰｖ４でもよく、レイヤ２はイーサネットに限るものではない。

ゲートウェイ１０は、ＬＡＮ側の端末２０Ａ、２０ＢをＷＡＮ側の端末３０と通信可能な状態にするために、ＬＡＮ４０およびＷＡＮ５０に接続される自宅に備えられたホームゲートウェイ等である。また、ゲートウェイ１０は、ＬＡＮ側の端末２０Ａ、２０Ｂによって送信されたＩＰパケットを中継する中継装置である。

ＬＡＮ側の端末２０Ａ、２０Ｂは、ゲートウェイ１０に接続され、ゲートウェイ１０経由でインターネット上のまたは、インターネット経由でアクセス可能な端末２０Ｃに対して、ＩＰｖ６通信を行うものとする。ルータ３０は、ゲートウェイ１０、端末２０Ｃによって送信されるＩＰパケットを中継する中継装置である。なお、図１では、３台の端末と１台のルータ、１台のゲートウェイを例示したが、ネットワークシステム１００には、２台以下の端末や、４台以上の端末や、２台以上のルータやゲートウェイが含まれてもよい。また、端末、ルータ及びゲートウェイの接続関係は、図１に示した例に限られない。

［ゲートウェイの構成］
次に、図２を用いて、図１に示したゲートウェイ１０の構成を説明する。図２は、第一の実施の形態に係るゲートウェイの構成例を示す図である。図２に示すように、ゲートウェイ１０は、通信部１１、通信部１２、記憶部１３、疎通監視部１４、ＰＭＴＵ通知判定部１５、および、ＰＭＴＵ通知部１６を有し、ＬＡＮ側の端末２０Ａと接続される。以下にこれらの各部の処理を説明する。

通信部１１および通信部１２は、接続される端末およびルータとの間でやり取りする各種情報に関する通信を制御する。例えば、通信部１１は、ＬＡＮ側の端末２０ＡからＷＡＮ側の端末２０Ｃに対するＩＰパケットを受信し、ＬＡＮ側の端末２０ＡへＰＭＴＵ値を送信する。また、例えば、通信部１２は、ＬＡＮ側の端末２０ＡからＷＡＮ側の端末２０ＣへのＩＰパケットを送信する。

記憶部１３は、各種処理に必要なデータおよびプログラムを格納するが、特に本発明に密接に関連するものとしては、後述する疎通監視部１４が使用する監視時間（図３）、後述するＰＭＴＵ通知部１６がＬＡＮ側端末２０Ａに通知するＰＭＴＵの値（図４）、ＬＡＮ側の端末のアドレスに関する情報（図５）などを記憶する。

例えば、記憶部１３は、図３に例示するように、疎通監視部１４が使用する監視時間として、「６０」秒を記憶している。この監視時間は、全通信プロトコル共通の「６０」秒として設定されているが、通信プロトコル毎に設定されていてもよく、通信プロトコルとポート番号の組毎に設定されてもよい。設定された監視時間に応じて、疎通監視部１４がパケットの中身を確認して応答待ちの監視時間を特定する。また、上記した監視時間は、通信するアプリケーションのタイムアウト時間よりも短い方が望ましい。

また、記憶部１３は、図４に例示するように、ＰＭＴＵ通知部１６がＬＡＮ側端末２０Ａに通知するＰＭＴＵの値として、ＬＡＮ側端末ＰＭＴＵ値「１２８０」ｂｙｔｅを記憶する。このＬＡＮ側端末ＰＭＴＵ値については、標準仕様などで保障される最低値（イーサネット上でのＩＰｖ６の場合は１２８０ｂｙｔｅ）であることが望ましい。また、ＬＡＮ側端末ＰＭＴＵ値は、宛先毎、宛先アドレス範囲毎、ＷＡＮ側全宛先に対して記憶してもよい。

また、記憶部１３は、図５に例示するように、ＬＡＮ側の端末のアドレスに関する情報として、ＬＡＮ側の機器「端末Ａ」のＭＡＣアドレス「ＡＡ：ＢＢ：ＣＣ：ＤＤ：ＥＥ：ＦＦ」とＩＰアドレス「ｆｅ８０：：１００１」（またはグローバルユニキャストアドレス）とを対応付けて記憶する。なお、記憶部１３は、ＩＰｖ４であればＬＡＮ側に割当てることができるプライベートアドレス帯、割当てたアドレスなどを記憶し、ＩＰｖ６であればＬＡＮ側に割当てられたプレフィックスやユニキャストアドレスなどを記憶する。

疎通監視部１４は、ＬＡＮ側の端末２０ＡからＷＡＮ側の端末２０Ｃへのパケット送信に対する応答が返ってくる応答時間を監視する。具体的には、疎通監視部１４は、ＬＡＮ内通信は監視対象とせず、ＬＡＮ側からＷＡＮ側への通信のみを監視対象とし、どのＬＡＮ側アドレスからどのＷＡＮ側アドレスへパケット送信が開始されたのかを監視し、通信開始を検知した時点から時間を計測しつつ、一時記憶する。そして、疎通監視部１４は、記憶部１３に記憶された監視時間（図３参照）内に宛先から応答があった場合は監視対象から除く、すなわち一時記憶から計測時間を削除する。なお、ＷＡＮ側の経路の途中の通信機器からのエラーメッセージなどを受けた場合もブラックホール問題とは別の問題となるため、監視対象から除くこととしてもよい。

ＰＭＴＵ通知判定部１５は、疎通監視部１４によって所定時間内に応答を受けたか否かを判定する。具体的には、ＰＭＴＵ通知判定部１５は、疎通監視部１４が監視を行った結果、監視時間を経過しても応答がなかった通信を要処理、すなわち、ＬＡＮ側端末２０ＡのＰＭＴＵ値を再設定する処理が必要であると判断する。

ＰＭＴＵ通知部１６は、ＰＭＴＵ通知判定部の判断結果に基づいて、記憶部１３が記憶しているＰＭＴＵの値をＷＡＮ側へ通信開始した送信元端末２０Ａに通知する。例えば、ＰＭＴＵ通知部１６は、ＬＡＮ側端末からＷＡＮ側端末へのパケット送信に対する、ＩＣＭＰｖ６(Internet Control Message Protocol for IPv6)メッセージのパケット過大（Packet Too Big）メッセージによる応答を生成して、この応答にＰＭＴＵの値を含めてもよい。

このパケット過大メッセージの中で、その宛先に対して最小のＰＭＴＵの値（例えば、１２８０ｂｙｔｅ）を指定する。さらに、全ＷＡＮ側宛先に対して最小のＰＭＴＵが設定されるよう通知してもよい。また、通知先は、ＷＡＮ側へ通信開始した送信元端末だけではなく、ＬＡＮ側全端末としてもよく、ＲＡ（Router Advertisement）メッセージで新たなオプションを定義したメッセージでＰＭＴＵの値を各端末に通知してもよい。なお、通知する契機や条件等は記憶部１３に記憶されているものとする。

また、図２に示すように、端末２０Ａは、通信部２１およびＰＭＴＵ設定部２２を有する。通信部２１は、接続されるゲートウェイ１０等との間でやり取りする各種情報に関する通信を制御する。例えば、通信部２１は、ゲートウェイ１０からＰＭＴＵの値が設定されたパケット過大メッセージを受信する。

ＰＭＴＵ設定部２２は、ゲートウェイ１０から受信したＰＭＴＵの値に基づき、該ＰＭＴＵの単位でＷＡＮ側の端末１０Ｃへパケット送信するように設定する。具体的には、ゲートウェイ１０から受信したパケット過大メッセージからＰＭＴＵの値を抽出し、所定のアドレス（当初の宛先など）または、アドレス範囲（ＬＡＮ側以外、つまりＷＡＮ側の全宛先等）に対して所定のＰＭＴＵの値を設定する。

［ネットワークシステムによる処理手順］
次に、図６を用いて、第一の実施の形態に係るネットワークシステム１００による処理の流れについて説明する。図６は、第一の実施の形態に係るネットワークシステム１００による処理手順を示すシーケンス図である。なお、図６では、ネットワークシステム１００には、ゲートウェイ１０と、ＬＡＮ側の端末２０Ａ、２０Ｂ、ＷＡＮ側の端末２０Ｃ及びルータ３０とが含まれるものとする。また、図６では、ルータ３０（ブラックホールルータ）が原因でブラックホール問題が起きているものとする。

図６の例において、ゲートウェイ１０は、ＬＡＮ側のネットワークのＭＴＵについて、端末２０Ａと接続しているゲートウェイ１０のＬＡＮ側のインタフェースのリンクＭＴＵの値を予め記憶しており、この値をＲＡ（Router Advertisement）のＭＴＵオプションを利用して、ＬＡＮ側の端末２０ＡにリンクＭＴＵとして通知する。なお、端末からＲＳ（Router Solicitation）を受けたことを契機にＲＡを通知してもよい。または、端末２０Ａが自らリンクＭＴＵを設定するものであってもよい。

そして、端末２０Ａは、リンクＭＴＵの値を自端末の通信インタフェースのリンクＭＴＵとして設定する。なお、ＬＡＮ側端末間のデフォルトのリンクＭＴＵが調整されている場合には、上記のリンクＭＴＵを設定する処理は不要である。

その後、端末２０Ａは、設定したリンクＭＴＵで、ＷＡＮ側の端末２０Ｃに対して通信を開始する。そして、ゲートウェイ１０は、端末２０Ａと端末２０Ｃとの間でパケットを中継しつつ通信を監視し、パケットの疎通確認を行う。具体的には、ゲートウェイ１０は、ＬＡＮ側からＷＡＮ側への通信開始を検知して、送信元と宛先のアドレスの組を一時記憶し、宛先から監視時間内に応答を受けるか否かを監視する。この結果、監視時間内に応答を受けた場合は、一時記憶した情報を削除する。

一方、ゲートウェイ１０は、監視時間内に応答を受けなかった場合には、宛先到達不能と判断、すなわちブラックホール問題に遭ったと判断し、予め記憶しているＬＡＮ側端末ＰＭＴＵ値（図４の例では、１２８０ｂｙｔｅ）をＬＡＮ側の端末２０Ａへ通知する。例えばゲートウェイ１０は、ＲＦＣ４４４３で定義されているＩＣＭＰｖ６のｔｙｐｅ=２のパケット過大メッセージを生成して、端末２０Ａへ送信する。そして、通知を受けた端末２０Ａは、宛先に対するＰＭＴＵとして通知された値を設定して再度端末２０Ｃと通信を行う。

［ゲートウェイによる処理手順］
次に、図７および図８を用いて、第一の実施の形態に係るゲートウェイ１０による処理の手順について説明する。図７および図８は、第一の実施の形態に係るゲートウェイによる処理手順を示すフローチャートである。

図７に示すように、ゲートウェイ１０の通信部１１は、ＬＡＮ側の端末からパケットを受信すると（ステップＳ１０１）、宛先がＷＡＮ側の端末であるか否かを判定する（ステップＳ１０２）。例えば、通信部１１は、記憶部１３に記憶されたＬＡＮ側の端末のアドレスに関する情報（図５参照）を参照し、宛先アドレスがＬＡＮ側の端末のアドレスに該当するか否かを判定することで、宛先がＷＡＮ側の端末であるか否かを判定する。なお、この判定は、完全一致の判定でもよく、部分一致の判定でもよい。または、ゲートウェイ１０がスイッチの機能を有する場合は、宛先のＭＡＣアドレスに基づいて判定してもよい。

この結果、通信部１１は、宛先がＷＡＮ側の端末でない場合（ステップＳ１０２否定）、すなわち宛先がＬＡＮ内の端末であると判定した場合には、そのまま宛先へパケットを転送し（ステップＳ１０３）、処理を終了する。また、宛先がＷＡＮ側の端末である場合には（ステップＳ１０２肯定）、ＷＡＮ側端末の宛先へパケットを転送し（ステップＳ１０４）、ＰＭＴＵ通知判定部１５は、ブラックホール問題に遭遇したか否かを判定する判定処理（後に図８を用いて詳述）を実行する（ステップＳ１０５）。

この結果、ＰＭＴＵ通知判定部１５がブラックホール問題に遭遇していないと判定した場合には（ステップＳ１０５否定）、そのまま処理を終了する。また、ＰＭＴＵ通知判定部１５がブラックホール問題に遭遇したと判定した場合には（ステップＳ１０５肯定）、予め記憶しているＰＭＴＵを送信元端末へ通知し（ステップＳ１０６）、処理を終了する。その後、通知を受けた送信元端末は、宛先に対するＰＭＴＵとして通知された値を設定して再度送信先端末と通信を行う。

次に、図８を用いて、ステップＳ１０５の判定処理について詳しく説明する。図８に示すように、ゲートウェイ１０の疎通監視部１４は、送信元と宛先のアドレスの組を一時記憶する（ステップＳ２０１）。そして、ＰＭＴＵ通知判定部１５は、監視時間（例えば、６０秒）以内に宛先から送信元宛の応答があるか否かを判定する（ステップＳ２０２）。

この結果、ＰＭＴＵ通知判定部１５が監視時間内に宛先から送信元宛の応答があると判定した場合には（ステップＳ２０２肯定）、ブラックホール問題に遭遇していないものと判断して、疎通監視部１４は、送信元と宛先のアドレスの組の一時記憶を削除し（ステップＳ２０３）、処理を終了する。また、ＰＭＴＵ通知判定部１５は、監視時間内に宛先から送信元宛の応答がないと判定した場合には（ステップＳ２０２否定）、ブラックホール問題であると判断し（ステップＳ２０４）、処理を終了する。

[第一の実施の形態の効果]
上述してきたように、ゲートウェイ１０は、ＬＡＮ側の端末２０ＡからＷＡＮ側の端末２０Ｃへのパケット送信に対する応答が返ってくる応答時間を監視し、監視された応答時間が所定の時間以内であるか否かを判定し、応答が所定の時間以内にないと判定された場合には、１回に転送可能なデータ容量であるＰＭＴＵの値をＬＡＮ側の端末２０Ａに通知する。そして、ＬＡＮ側の端末１０Ａは、ゲートウェイ１０から受信したＰＭＴＵの値に基づき、該ＰＭＴＵでＷＡＮ側の端末２０Ｃへパケット送信するように設定する。これにより、最適なＰＭＴＵによる通信と比較すると通信効率は劣る場合があるが、ＷＡＮ側の通信機器に手を入れることなく、ブラックホール問題を回避できる。また、全ての通信に対して宛先までの経路の適当なＰＭＴＵを事前調査するものではない点において、宛先装置との通信が実際に開始されるまで遅れを低減できる。この結果、適切に通信を行うことができるＭＴＵの値で、効率的に通信を行うことが可能である。

また、第一の実施の形態によれば、ＬＡＮ内で端末２０Ａと端末２０Ｂとの間で通信する場合には、通信インタフェースのリンクＭＴＵの値のままで通信できる状態を維持しつつ、ＷＡＮ側の端末と通信する場合は、ブラックホール問題を回避するＭＴＵの値で通信することができる。

また、第一の実施の形態によれば、ＩＰｖ４で通信する場合に、パケット内にフラグメント処理を禁止するビットが設定されている場合は、ＩＰｖ６の通信と同様に有効である。ＩＰｖ４でフラグメントを禁止していない場合、通信のＭＴＵが過大である場合は経路上の各ルータが適宜フラグメント処理をするが、ファイアウォール等によっては、フラグメント化されたパケットは受け取らないように設定されていることもある。また、そうでない場合も、フラグメント処理はルータにかかる負荷が大きくなるため通信効率に影響する。本発明によれば、ＩＰｖ４通信でも有効な場合がある。

また、第一の実施の形態によれば、ＬＡＮ内の端末を含む通信機器の通信インタフェースにイーサネットのジャンボ・フレームが適用されている場合には、ジャンボ・フレームの仕様によるが、例えば８０００〜１５００００ｂｙｔｅ程度のフレームサイズで通信することが可能となる（イーサネットのＭＴＵは１５００ｂｙｔｅ）。この場合、ＭＴＵの値も大きく通信効率が良くなる。

（第二の実施の形態）
ところで、上記の第一の実施の形態では、監視時間内に宛先から送信元宛の応答がないか判定し、応答がないと判定した場合にはブラックホール問題に遭遇していると判断する場合を説明したが、本発明はこれに限定されるものではなく、ＰＭＴＵの値が原因で通信ができないことを確認するための処理を行うようにしてもよい。

そこで、以下の第二の実施の形態では、ＰＭＴＵの値が原因で通信ができないことを確認するために、監視時間内に応答が無い場合には、同じ宛先に小サイズ（例えば、ＰＭＴＵの最小値）のパケットを送信し、所定時間内に応答があるか否かを判定し、所定時間内に応答がある場合には、ブラックホール問題に遭遇していると判断する。以下では、図１０〜図１３を用いて、第二の実施の形態に係るゲートウェイ１０Ａの構成および処理について説明する。なお、以下の説明では、第一の実施の形態と共通する構成及び処理については説明を省略する。

図１０に示すように、第二の実施の形態に係るゲートウェイ１０Ａは、疎通確認部１７を新たに有する点が、図２に示した第一の実施の形態に係るゲートウェイ１０と相違する。また、ゲートウェイ１０Ａの記憶部１３は、疎通確認部１７が使用する疎通確認時間と、疎通確認部１７が使用する疎通確認時のパケットのサイズとを記憶する点が、図２に示した第一の実施の形態に係るゲートウェイ１０と相違する。

例えば、記憶部１３は、図１０に例示するように、疎通確認部１７が使用する疎通確認時間として、「４」秒を記憶する。なお、疎通確認部１７が使用する疎通確認時間としては、ＩＣＭＰｖ６のＰｉｎｇ等でも用いられる短い時間でもよい。

また、記憶部１３は、図１１に例示するように、疎通確認部１７が使用する疎通確認時のパケットのサイズとして、「１２８０」ｂｙｔｅを記憶する。なお、疎通確認部１７が使用する疎通確認時のパケットのサイズは、ＰＭＴＵ通知部１６がＬＡＮ側の端末２０Ａに通知するＰＭＴＵの値と同じであることが望ましい。

疎通確認部１７は、ＰＭＴＵ通知判定部１５によって応答が所定の時間以内にないと判定された場合には、ＬＡＮ側の端末２０ＡからＷＡＮ側の端末２０Ｃへのパケット送信時よりも小さいサイズのパケットをＷＡＮ側の端末２０Ｃへ送信し、疎通確認時間以内に該送信に対する応答があったか否かを確認する。疎通確認部１７は、疎通確認のために送信する小さいサイズのパケットとして、例えば、端末２０Ａに通知する予定のＰＭＴＵのサイズでもよく、より小さいサイズ、例えばイーサネットであれば保障されているＭＴＵの最小値でもよい。

つまり、第一の実施形態では、端末２０Ａからの通信に対して、宛先から所定時間内に応答がないことでブラックホール問題に遭遇したものと判断したが、例えば、宛先端末がダウンしている等、ブラックホール問題とは別の原因で疎通が取れないこともあり得る。そこで、第二の実施形態では、疎通確認部１７が、さらに、通信に用いたＰＭＴＵの値が原因で疎通が取れていないことを確認するため、小さいサイズのパケットを送信して疎通を確認する。これにより、ブラックホール問題が原因で応答が返ってこないのか否かを適切に判断することが可能である。

次に、図１２を用いて、第二の実施の形態に係るネットワークシステムによる処理の流れについて説明する。図１２は、第二の実施の形態に係るネットワークシステムによる処理手順を示すシーケンス図である。図１２に示すように、端末２０Ａは、リンクＭＴＵで、ＷＡＮ側の端末２０Ｃに対して通信を開始する。そして、ゲートウェイ１０は、端末２０Ａと端末２０Ｃとの間でパケットを中継しつつ通信を監視し、パケットの疎通確認を行う。

そして、ゲートウェイ１０は、疎通監視の結果、所定時間内に応答がなかった場合には、同じ宛先に小サイズのパケットによる通信（ＩＰｖ６であればＩＣＭＰｖ６のｐｉｎｇなど）を行い、疎通確認時間内（例えば、ＷＡＮとの通信のＲｏｕｎｄ Ｔｒｉｐ Ｔｉｍｅを適宜計測しておく等して、さらには統計処理等をして算出した時間を利用してもよい）に宛先から応答があった場合はブラックホール問題によるものと判断し、要処理と判断する。

一方、応答がない場合は別の原因によるものであるため、端末２０ＡにＰＭＴＵの通知はしない。この場合、代わりに別の原因により不通となっている趣旨のメッセージを端末２０Ａへ通知してもよい。なお、この疎通確認は最適なＰＭＴＵを特定しようとするものではなく、ＩＰパケットが宛先に到達可能であることを確認するものであり、短時間で応答の有無を確認できるものである。

そして、ゲートウェイ１０は、ブラックホール問題によるものと判断した場合には、予め記憶しているＬＡＮ側端末ＰＭＴＵ値（図４の例では、１２８０ｂｙｔｅ）をＬＡＮ側の端末２０Ａへ通知する。そして、通知を受けた端末２０Ａは、宛先に対するＰＭＴＵとして通知された値を設定する。

次に、図１３を用いて、第二の実施の形態に係るゲートウェイ１０Ａによる判定処理の処理手順について説明する。図１３は、第二の実施の形態に係るゲートウェイによる処理手順を示すフローチャートである。

図１３に示すように、ゲートウェイ１０Ａの疎通監視部１４は、送信元と宛先のアドレスの組を一時記憶する（ステップＳ３０１）。そして、ＰＭＴＵ通知判定部１５は、監視時間（例えば、６０秒）以内に宛先から送信元宛の応答があるか否かを判定する（ステップＳ３０２）。

この結果、ＰＭＴＵ通知判定部１５が監視時間内に宛先から送信元宛の応答があると判定した場合には（ステップＳ３０２肯定）、ブラックホール問題に遭遇していないものと判断して、疎通監視部１４は、送信元と宛先のアドレスの組の一時記憶を削除し（ステップＳ３０３）、処理を終了する。

また、ＰＭＴＵ通知判定部１５が監視時間時間内に宛先から送信元宛の応答がないと判定した場合には（ステップＳ３０２否定）、疎通確認部１７は、宛先であるＷＡＮ側の端末へより小サイズのパケット送信（ＩＰｖ６であればＩＣＭＰｖ６のｐｉｎｇなど）を行い（ステップＳ３０４）、所定時間内に応答があるか否かを判定する（ステップＳ３０５）。

この結果、疎通確認部１７は、所定時間内に応答がないと判定した場合には（ステップＳ３０５否定）、ブラックホール問題とは別の問題であると判断して（ステップＳ３０６）、処理を終了する。また、疎通確認部１７は、所定時間内に応答があったと判定した場合には（ステップＳ３０５肯定）、ブラックホール問題であると判断し（ステップＳ３０７）、処理を終了する。

このように第二の実施の形態によれば、ゲートウェイ１０Ａは、応答が監視のための所定の時間以内にないと判定された場合には、ＬＡＮ側の端末からＷＡＮ側の端末へのパケット送信時よりも小さいデータ容量のパケットをＷＡＮ側の端末へ送信し、該送信に対する応答が所定の時間以内にあるか否かを確認する。そして、ゲートウェイ１０Ａは、応答が疎通確認のための所定の時間以内あると確認された場合には、ＰＭＴＵの値をＬＡＮ側の端末に通知する。このため、これにより、ブラックホール問題が原因で応答が返ってこないのか否かを適切に判断することが可能となる。

（第三の実施の形態）
ところで、本発明では、ゲートウェイが、ＷＡＮ側の端末における宛先情報と、該ＷＡＮ側の端末とデータ通信を行う際のＰＭＴＵとを対応付けて記憶するようにしてもよい。

そこで、以下の第三の実施の形態の説明では、ゲートウェイが、ＷＡＮ側の宛先のアドレスもしくはアドレス範囲（ＷＡＮ側全体宛を示す範囲でもよい）と、その宛先に適用するＰＭＴＵの組を管理する管理テーブルを記憶する場合について説明する。以下では、図１４〜図１６を用いて、第三の実施の形態に係るゲートウェイの処理について説明する。

まず、図１４を用いて、第三の実施の形態に係るネットワークシステムによる処理の流れについて説明する。図１４は、第三の実施の形態に係るネットワークシステムによる処理手順を示すシーケンス図である。図１４に例示するように、ゲートウェイ１０は、宛先のアドレスと、その宛先に適用するＰＭＴＵとが対応付けられた管理テーブルを記憶する。なお、図１４の例では、処理が開始される前の状態において、管理テーブルには、未だ何も記憶されていない初期状態であるものとする。

図１４に示すように、端末２０Ａは、リンクＭＴＵ（例えば、１５００ｂｙｔｅ）で、ＷＡＮ側の端末２０Ｃに対して通信を開始する。そして、ゲートウェイ１０は、ＬＡＮ側端末からＷＡＮ側端末宛への通信を受けると、その通信のパケットの宛先とＭＴＵを特定し、管理テーブル内の宛先と照合する。なお、この照合は、完全一致の照合でもよく、部分一致の照合でもよい。

ゲートウェイ１０は、照合した結果、該当する宛先がなければ、そのままＷＡＮ側端末宛へパケットを転送する。一方、ゲートウェイ１０は、照合した結果、該当する宛先であれば、パケットのＭＴＵがその宛先に対応づけて記憶されているＰＭＴＵの値より大きい場合（または異なる場合には）、宛先へ転送せずに、管理テーブル内のその宛先に対応するＰＭＴＵの情報を用いて、ＩＣＭＰｖ６メッセージを生成して送信元の端末へ返す。なお、このメッセージは、通常のＰＭＴＵ探索が機能した場合に送信元の端末が受けるＩＣＭＰｖ６のパケット過大メッセージの仕様と同じものであり、通常であれば適切なＰＭＴＵの値が含まれるメッセージであるが、本発明は、このＰＭＴＵ探索が機能せず、このメッセージが返ってこないことを考慮しているため、ゲートウェイ１０が生成するこのメッセージに含めるＰＭＴＵの値は、管理テーブル内の該当する宛先に対応するＰＭＴＵの値を埋め込んだものである。

図１４の例では、管理テーブルには、未だ何も記憶されていない初期状態であるため、ゲートウェイ１０は、照合した結果、該当する宛先がないものとし、そのままＷＡＮ側端末２０Ｃ宛へパケットを転送し、端末２０Ａと端末２０Ｃとの間でパケットを中継しつつ通信を監視し、パケットの疎通確認を行う。

そして、ゲートウェイ１０は、疎通監視の結果、所定時間内に応答がなかった場合には、同じ宛先に小サイズのパケットのデータ通信を行い、疎通確認時間内に宛先から応答があった場合はブラックホール問題によるものと判断し、端末２０ＡにＰＭＴＵの通知を行うとともに、管理テーブルに反映する。つまり、ゲートウェイ１０は、端末Ｃの宛先と、到達保証されているＰＭＴＵの値（例えば、疎通確認において端末２０Ｃに到達した際のＰＭＴＵの値）を対応付けて記憶部１３に記憶させる。

その後、通知を受けた端末２０Ａは、宛先に対するＰＭＴＵとして通知された値を設定し、設定されたＰＭＴＵの値でＷＡＮ側の端末２０Ｃに再度送信する。

次に、図１５を用いて、第三の実施の形態に係るゲートウェイによる処理手順について説明する。図１５は、第三の実施の形態に係るゲートウェイによる処理手順を示すフローチャートである。

図１５に示すように、ゲートウェイ１０の通信部１１は、ＬＡＮ側の端末からパケットを受信すると（ステップＳ４０１）、宛先がＷＡＮ側の端末であるか否かを判定する（ステップＳ４０２）。

この結果、通信部１１は、宛先がＷＡＮ側の端末でない場合（ステップＳ４０２否定）、すなわち宛先がＬＡＮ内の端末であると判定した場合には、そのまま宛先へパケットを転送し（ステップＳ４０３）、処理を終了する。また、宛先がＷＡＮ側の端末である場合には（ステップＳ４０２肯定）、疎通監視部１４は、パケットの宛先が管理テーブル内の宛先情報に該当するものがあるか照合する（ステップＳ４０４）。

この結果、疎通監視部１４は、ＬＡＮ側の端末から受信したパケットが管理テーブルに記憶されている宛先情報に該当するパケットである場合には（ステップＳ４０５肯定）、宛先情報に対応付けて記憶されたＰＭＴＵ以下のパケットであるか判定する（ステップＳ４０９）。この結果、疎通監視部１４がＰＭＴＵ以下のパケットであると判定した場合には（ステップＳ４０９肯定）、通信部１２は、ＷＡＮ側の端末へパケットを転送して（ステップＳ４１０）、処理を終了する。また、疎通監視部１４がＰＭＴＵ以下のパケットでないと判定した場合には（ステップＳ４０９否定）、予め記憶しているＰＭＴＵを送信元端末へ通知し（ステップＳ４１１）、処理を終了する。

また、ステップＳ４０５の説明に戻って、疎通監視部１４は、ＬＡＮ側の端末から受信したパケットが管理テーブルに記憶されている宛先情報に該当するパケットでない場合には（ステップＳ４０５否定）、ＷＡＮ側端末の宛先へパケットを転送し（ステップＳ４０６）、ＰＭＴＵ通知判定部１５は、ブラックホール問題に遭遇したか否かを判定する判定処理（例えば、前述した図８、図１３の判定処理）を実行する（ステップＳ４０７）。

この結果、ＰＭＴＵ通知判定部１５がブラックホール問題に遭遇していないと判定した場合には（ステップＳ４０７否定）、そのまま処理を終了する。または、送信元端末にこの旨を通知する。また、ＰＭＴＵ通知判定部１５がブラックホール問題に遭遇したと判定した場合には（ステップＳ４０７肯定）、管理テーブルに宛先を追記し、ＰＭＴＵと合わせて記憶させるとともに（ステップＳ４０８）、予め記憶しているＰＭＴＵ（つまり宛先と対応付けて記憶させたＰＭＴＵ）を送信元端末へ通知し（ステップＳ４１１）、処理を終了する。その後、通知を受けた送信元端末は、宛先に対するＰＭＴＵとして通知された値を設定して再度送信先端末と通信を行う。

つまり、ゲートウェイ１０は、ＷＡＮ側宛先と到達可能なＰＭＴＵとを対応付けて管理テーブルに記憶していることで、ＬＡＮ側端末が宛先までのＰＭＴＵを記憶していない場合であっても、ゲートウェイとの間の一往復の通信で、ゲートウェイが生成するパケット過大メッセージを受けることで宛先へ到達可能なＰＭＴＵを取得でき、そのＰＭＴＵで宛先と通信を行うことができる。

このように第三の実施の形態によれば、ゲートウェイ１０は、ＷＡＮ側の端末における宛先情報と、該ＷＡＮ側の端末とデータ通信を行う際のＰＭＴＵ値とを対応付けて記憶する。そして、ゲートウェイは、ＬＡＮ側の端末からＷＡＮ側の端末へのデータ通信が行われる際に、該ＷＡＮ側の端末の宛先情報に該当する宛先情報が記憶部に記憶されている場合には、該宛先情報に対応付けて記憶されているＰＭＴＵ値よりもデータ通信におけるＰＭＴＵ値が大きいか否かを監視する。そして、宛先情報に対応付けて記憶されているＰＭＴＵ値よりもデータ通信におけるＰＭＴＵ値が大きい場合には、ＷＡＮ側の端末へのデータ通信を中止し、つまり、ゲートウェイ１０は通信の宛先であるＷＡＮ側の端末へ転送せずに、宛先情報に対応付けて記憶されているＰＭＴＵ値をＬＡＮ側の端末にパケット過大メッセージなどによって通知する。つまり、ＬＡＮ側の所定の端末によるＷＡＮ側との通信の経験で得たＰＭＴＵ値をゲートウェイ１０が管理テーブルに記憶することで、その宛先に初めてパケットを送る別の端末に管理テーブルに記憶されたＰＭＴＵ値を適用させることができる。このため、管理テーブルに記憶されたＰＭＴＵ値を用いて、適切に通信を行うことができるＰＭＴＵ値で、より効率的に通信を行うことがすることが可能となる。このように管理テーブルの情報をＬＡＮ側の全端末で共有してもよいし、端末毎に管理テーブルを保持する構成であってもよい。また、ＷＡＮ側のすべての宛先に対して同一のＰＭＴＵ値を適用する場合は、管理テーブルに宛先情報とＰＭＴＵ値を対応付けて記憶させることは必須ではなく、宛先情報と適用するＰＭＴＵ値を分けて管理してもよい。

また、本発明では、所定の時間以内に異なる宛先に対してブラックホール問題が発生した回数が所定の回数以上となった場合には、ＷＡＮ側の全ての端末について、所定値（例えば、最小ＭＴＵ値）を取るように管理テーブルに設定するようにしてもよい。

このような処理について、図１６を用いて、ゲートウェイによる判定処理の処理手順について説明する。図１６に示すように、ゲートウェイによる判定処理は、図１３に示した判定処理と比較して、ブラックホール問題と判断された後に（ステップＳ５０７）、所定の時間内に、ブラックホール問題と判断した回数が閾値を超えたか否かを判定する処理（ステップＳ５０８）が新しく追加されている。

この処理の結果、ブラックホール問題と判断をした回数が閾値を超えた場合には、ＷＡＮ側全端末に対するＰＭＴＵの値として所定値（例えば、最小ＭＴＵ値）を取るように管理テーブルに設定する（ステップＳ５０９）。

すなわち、一定期間内に異なる宛先に対して複数回ブラックホール問題が発生したということは、つまり、ゲートウェイ１０のすぐ外の経路に問題があり、ゲートウェイ１０の接続先にそもそもの問題があるものとみなして、ＷＡＮ側への任意の通信については、ブラックホール問題を回避できる所定のＰＭＴＵ値を一律に適用する。このように、上記の処理では、所定の時間内にブラックホール問題と判断をした回数が所定の回数以上となった場合には、ＷＡＮ側の全ての端末について、最小のＭＴＵを対応付けて記憶し、ＬＡＮ側の端末に通知する。このため、ブラックホール問題を確実に回避することが可能である。

このように、ゲートウェイ１０がＷＡＮ側宛先と到達可能なＰＭＴＵ値とを対応付けて管理テーブルに記憶していることで、ＬＡＮ側端末が宛先までのＰＭＴＵ値を記憶していない場合であっても、ゲートウェイ１０との間の一往復の通信で、ゲートウェイ１０が生成するパケット過大メッセージを受けることで宛先へ到達可能なＰＭＴＵ値を取得でき、そのＰＭＴＵ値で宛先と通信を行うことができる。

ここで、ＷＡＮ側全宛先のＰＭＴＵ値を一定値とするパターンについて、ゲートウェイ１０のＬＡＮ側の通信インタフェースのリンクＭＴＵ値を絞らず（例えば、リンクＭＴＵ値＝１５００ｂｙｔｅ）にＷＡＮ側の通信インタフェースのリンクＭＴＵ値を絞った（例えば、リンクＭＴＵ値＝１２８０ｂｙｔｅ）場合は、上記した第三の実施の形態の構成を採らなくてもゲートウェイ１０よりＷＡＮ側に転送される前にＰＭＴＵ探索によりＰＭＴＵ値（例えば、ＰＭＴＵ値＝１２８０ｂｙｔｅ）がＬＡＮ側の送信元に通知されるが、ＷＡＮ側の通信インタフェースのリンクＭＴＵ値を絞った場合と第三の実施の形態の構成との差分について説明する。

ゲートウェイ１０のＬＡＮ側に公開サーバなどを設置してＷＡＮ側から公開サーバにアクセスがあるような環境では、ＷＡＮ側からこの公開サーバへの通信を受けたとき、この通信におけるＭＴＵ値が１５００ｂｙｔｅによるものである場合には、ゲートウェイ１０のＷＡＮ側のリンクＭＴＵを絞った状態（例えば、リンクＭＴＵ値＝１２８０ｂｙｔｅ）であるため、ゲートウェイ１０はその通信がＷＡＮ側のリンクＭＴＵに調整するようにＰＭＴＵ探索に基づいて、ＷＡＮ側の送信元にＰＭＴＵとして「１２８０ｂｙｔｅ」を返すことになり、ＷＡＮ側の送信元からゲートウェイ１０の直前まではＭＴＵ値が１５００ｂｙｔｅで通信できるパスであってもＭＴＵ値が１２８０ｂｙｔｅで通信させることになり非効率である。一方、上記の第三の実施の形態の構成では、ゲートウェイ１０のＷＡＮ側のリンクＭＴＵを絞る必要がないので、このような環境でも有効に機能する。

（第四の実施の形態）
ところで、本発明では、所定の宛先だけでなく、所定のアドレス範囲（例えばＷＡＮ側前宛先）に対して適用するＰＭＴＵの通知を行ってもよい。

そこで、以下の第四の実施の形態の説明では、所定のアドレス範囲（例えばＷＡＮ側前宛先）に対して適用するＰＭＴＵの通知を行う場合について説明する。ここで、所定のアドレス範囲（例えばＷＡＮ側全宛先）に対して適用するＰＭＴＵの通知を行う場合には、通知するゲートウェイと通知を受けるＬＡＮ側端末との間で利用される新たなメッセージを定義する必要がある。ここでは２つのメッセージについて例を説明する。

ここで、ＩＣＭＰｖ６のパケット過大メッセージは、タイプ＝２、コード＝０で定義されている。例えば、タイプ＝２のまま未定義のコード＝１や、未定義の新たなタイプを仕様の範囲内で定義してもよい。新たに定義されたメッセージを受けた端末は、少なくともこのメッセージに含まれる情報に基づいて処理するが、ここでは４通り（１）〜（４）の説明をする。

新しく定義されるメッセージには、「宛先」とその宛先に適用する「ＰＭＴＵ」との組「宛先：ＰＭＴＵ」が含まれる。このメッセージの通知を受けたＬＡＮ側端末は、この「宛先」に対して、この「ＰＭＴＵ」の値で通信する。

例えば、新しく定義されるメッセージに「宛先「Ａ」：ＰＭＴＵ「Ｘ」」の組（１）が含まれている場合には、メッセージの通知を受けたＬＡＮ側端末は、所定のアドレスＡ宛（通信の宛先）の通信に対してＰＭＴＵの値としてＸを適用する。

また、新しく定義されるメッセージに「宛先「｛Ｒ｝」：ＰＭＴＵ「Ｙ」」の組（２）が含まれている場合には、メッセージの通知を受けたＬＡＮ側端末は、アドレス範囲｛Ｒ｝に含まれるアドレスを宛先とする通信に対してＰＭＴＵの値としてＹを適用する。なお、アドレス、アドレス範囲は２以上設定されてもよく、アドレス範囲を表記できるフィールドを設けることになる。

また、新しく定義されるメッセージに「宛先「¬｛Ｒ｝」：ＰＭＴＵ「Ｙ」」の組（３）が含まれている場合には、例えば、アドレス範囲｛Ｒ｝にＬＡＮ側のＮＷアドレスが指定されていれば、このＬＡＮ側以外の宛先、つまりＷＡＮ側宛との通信にはＰＭＴＵ＝Ｙを適用する。上記（２）の宛先に関する否定表現である。アドレスまたはアドレス範囲に対する論理的否定ＮＯＴを表記できるフィールドを設けることになる。

また、新しく定義されるメッセージに「宛先「¬Ｔ」：ＰＭＴＵ「Ｚ」」の組（４）が含まれている場合には、メッセージの通知を受けたＬＡＮ側端末は、自身が参加しているＮＷドメインのアドレス情報を取得して、このアドレス（範囲）以外の宛先のＰＭＴＵをＺとみなして通信する。アドレス情報とは、例えば、ＩＰｖ４の場合はＩＰアドレス、サブネットマスク等から計算して取得し、ＩＰｖ６の場合はネットワークのプレフィックスやプレフィックス長を取得する。上記（３）と異なる点は、ゲートウェイが明示的にアドレス範囲を通知するのではなく、端末側でアドレス範囲を特定する点にある。なお、上記した４通りである（１）〜（４）における「宛先」とその宛先に適用する「ＰＭＴＵ」との組「宛先：ＰＭＴＵ」の情報は、ゲートウェイ１０が記憶しているものである。

また、端末が新しく定義されるメッセージの通知を受けるタイミングは、２通りある。まず、ＷＡＮ側宛先への通信の送信元である端末がＩＣＭＰｖ６メッセージでＰＭＴＵの通知を受ける場合である。この場合には、宛先へ通信を試みる過程でゲートウェイからＰＭＴＵの通知を受けることができる。

また、これ以外のタイミングで通知を受ける場合として、ゲートウェイが広告するルータ広告（Router Advertisement）の新たなオプションのメッセージとして端末に通知して、通知を受けた端末はそのメッセージに従って自端末にＰＭＴＵを設定してもよい。メッセージの内容や処理は、上記（１）〜（４）と同様である。その際はＲＡにおいて、未定義のオプションで新たな定義をすることになる。ＲＡであれば、端末からＲＳを受けたことを契機としてその端末に通知するだけでなく、ゲートウェイが所定時間間隔で自発的に通知もするので、ＷＡＮ側に関するＰＭＴＵの通知をＬＡＮ側端末が受取ることができる。

なお、これまで本発明の実施の形態について説明したが、本発明は上述した実施の形態以外にも、種々の異なる形態にて実施されてよいものである。

［ブラックホール問題の判定処理］
例えば、ブラックホール問題に遭ったのか否かを判断する処理について、種々の異なる処理方法を行ってもよい。ところで、ＴＣＰ（Transmission Control Protocol）の場合、最初に送信元と宛先の間で３ウェイハンドシェイクにより、互いのＭＳＳを交換してから小さい方のサイズに調整したＭＳＳ（Maximum Segment Size）で送信元から通信を行うが、この最初の通信はパケットサイズが小さいため通るが、その後の調整したＭＳＳのパケットサイズが大きくて通信が通らない場合がある。

このような場合の対処として、通信開始からまたは３ウェイハンドシェイク以降、所定回数往復分のパケットを監視対象として、その中で所定時間応答がない場合要処理と判断してもよい。

または、送信したパケットのＴＣＰのシーケンス番号を記憶しておき、そのシーケンス番号に対するＡＣＫ（ACKnowledgement）が所定時間内に返ってきたか否かを監視対象に含めてもよい。さらに、ＴＣＰには再送制御が備わっているので、この再送制御によって所定回数送信したパケットの同じシーケンス番号対応するＡＣＫが返ってこなかった場合は、要処理と判断してもよい。

または、調整したＭＳＳのサイズのパケット応答が所定時間内にない場合、または、このＭＳＳのサイズ未満のパケットが所定期間内に所定数以上の応答があった場合（例えば、Ｗｅｂサイトの場合、送信元端末上でテキストファイルだけ表示されて、表示されるべき画像ファイルや再生されるべき動画が表示されない状況を示すものである場合）、ブラックホール問題に遭ったと判断してもよい。

または、ブラックホール問題に限っては、標準仕様で規定されている最小のＭＴＵのサイズのパケットが通るので、最小ＭＴＵ以上のサイズのパケットのみを監視対象としてもよい。または、標準仕様で規定されている最小のＭＴＵ以上のサイズのパケットを送受信、送信、受信できたことを確認した時点で監視対象から外すと判断してもよい。

ところで、ブラックホール問題に遭うことなく正常な通信であるが、ＬＡＮ側からの通信に対してＷＡＮ側から応答がない場合もある。この場合には、ＵＤＰの場合は宛先からの応答の有無はＵＤＰ（User Datagram Protocol）を使用している送信元／宛先のアプリケーションに依存する。そこで、パケット監視をしてＴＣＰ／ＵＤＰを識別して、ＴＣＰであればＷＡＮ側からの戻りがあると判断できるので応答の有無を確認し、ＵＤＰの場合は戻りのないＵＤＰ通信であることが事前に分かっているアプリケーションプロトコルについては、ゲートウェイで予めプロトコルとポート番号、メッセージのうちのいずれか１以上からなる組などを記憶しておくことで、監視対象から除外するとしてもよい。また、このような記憶はＴＣＰにも適用してもよい。なお、ＵＤＰで戻りのあるものは、例えばＤＮＳ、ＤＨＣＰ、ＮＴＰの問合せに対する応答などがあげられる。また、監視対象のパケットは標準仕様で規定されている最小のサイズ以上のものであってもよい。

また、各端末は、ゲートウェイから通知されたＰＭＴＵを使い続けてＷＡＮ側と通信してもよいが、所定時間経過後にこのＰＭＴＵをリフレッシュ（削除）してもよい。この所定時間は、ゲートウェイからの通知に含まれていてもよく、個々の端末の中で管理されているものであってもよい。また、ゲートウェイ自身も保持している管理テーブルの中身を同様に所定時間経過後にリフレッシュさせてもよい。これは、インターネット上の経路は動的に変化するため、同じ宛先に対して常に同じＰＭＴＵであるとは限らないためである。

管理テーブルには、ＰＭＴＵを通知すべきＷＡＮ側宛先を記憶するのではなく、ＬＡＮ側の端末にＰＭＴＵを通知しなくてよいＷＡＮ側宛先を記憶させて、管理テーブル内に記憶されていないＷＡＮ側宛先宛のパケットを受けたら、ＰＭＴＵを通知することとしてもよい。また、管理テーブルが扱う送信元や宛先の情報はアドレスではなく、ＤＮＳ（Domain Name System）から得た名前情報でもよい。また、ゲートウェイはモバイルルータのような可搬媒体であってもよい。

また、イーサネット上のＩＰｖ６の場合であっても、経路上にトンネルが張られている場合は、トンネルのためのヘッダサイズを考慮する必要があり、このトンネルのためのオーバヘッドとなるサイズも含めてＭＴＵ＝１２８０となるような所定のＰＭＴＵの値を設定してもよい。また、ＰＭＴＵ探索で適切なＰＭＴＵを取得できる宛先については、あえてゲートウェイが記憶して通信を管理する必要はなく、ブラックホール問題に遭う宛先についてのみ記憶するようにしてもよい。

［システム構成等］
また、図示した各装置の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散・統合の具体的形態は図示のものに限られず、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。例えば、キャッシュ検索部１３ａとディスク負荷判定部１３ｂを統合してもよい。さらに、各装置にて行なわれる各処理機能は、その全部または任意の一部が、ＣＰＵおよび当該ＣＰＵにて解析実行されるプログラムにて実現され、あるいは、ワイヤードロジックによるハードウェアとして実現され得る。

また、本実施例において説明した各処理のうち、自動的におこなわれるものとして説明した処理の全部または一部を手動的におこなうこともでき、あるいは、手動的におこなわれるものとして説明した処理の全部または一部を公知の方法で自動的におこなうこともできる。この他、上記文書中や図面中で示した処理手順、制御手順、具体的名称、各種のデータやパラメータを含む情報については、特記する場合を除いて任意に変更することができる。

［プログラム］
また、上記実施例において説明したゲートウェイ１０が実行する処理をコンピュータが実行可能な言語で記述したプログラムを作成することもできる。例えば、ゲートウェイ１０が実行する処理をコンピュータが実行可能な言語で記述した中継プログラムを作成することもできる。この場合、コンピュータが中継プログラムを実行することにより、上記実施例と同様の効果を得ることができる。さらに、かかる中継プログラムをコンピュータ読み取り可能な記録媒体に記録して、この記録媒体に記録された中継プログラムをコンピュータに読み込ませて実行することにより上記実施例と同様の処理を実現してもよい。以下に、図２に示したゲートウェイ１０と同様の機能を実現する中継プログラムを実行するコンピュータの一例を説明する。

図１７は、中継プログラムを実行するコンピュータ１０００を示す図である。図１７に例示するように、コンピュータ１０００は、例えば、メモリ１０１０と、ＣＰＵ１０２０と、ハードディスクドライブインタフェース１０３０と、ディスクドライブインタフェース１０４０と、シリアルポートインタフェース１０５０と、ビデオアダプタ１０６０と、ネットワークインタフェース１０７０とを有し、これらの各部はバス１０８０によって接続される。

メモリ１０１０は、図１７に例示するように、ＲＯＭ（Read Only Memory）１０１１及びＲＡＭ１０１２を含む。ＲＯＭ１０１１は、例えば、ＢＩＯＳ（Basic Input Output System）等のブートプログラムを記憶する。ハードディスクドライブインタフェース１０３０は、図１７に例示するように、ハードディスクドライブ１０３１に接続される。ディスクドライブインタフェース１０４０は、図１７に例示するように、ディスクドライブ１０４１に接続される。例えば磁気ディスクや光ディスク等の着脱可能な記憶媒体が、ディスクドライブに挿入される。シリアルポートインタフェース１０５０は、図１７に例示するように、例えばマウス１０５１、キーボード１０５２に接続される。ビデオアダプタ１０６０は、図１７に例示するように、例えばディスプレイ１０６１に接続される。

ここで、図１７に例示するように、ハードディスクドライブ１０３１は、例えば、ＯＳ１０９１、アプリケーションプログラム１０９２、プログラムモジュール１０９３、プログラムデータ１０９４を記憶する。すなわち、上記の中継プログラムは、コンピュータ１０００によって実行される指令が記述されたプログラムモジュールとして、例えばハードディスクドライブ１０３１に記憶される。例えば、図３に例示したメッセージ送信部１３１と同様の情報処理を実行するメッセージ送信手順と、メッセージ格納部１３２と同様の情報処理を実行するメッセージ格納手順とが記述されたプログラムモジュール１０９３が、ハードディスクドライブ１０３１に記憶される。または、上記例のように、メッセージ送信部１３１が比較部と送信部とに分散される場合には、比較手順と、送信手順と、メッセージ格納手順とが記述されたプログラムモジュール１０９３が、ハードディスクドライブ１０３１に記憶される。

また、上記実施の形態で説明した記憶部１３が保持する各種データは、プログラムデータとして、例えばメモリ１０１０やハードディスクドライブ１０３１に記憶される。そして、ＣＰＵ１０２０が、メモリ１０１０やハードディスクドライブ１０３１に記憶されたプログラムモジュール１０９３やプログラムデータ１０９４を必要に応じてＲＡＭ１０１２に読み出し、メッセージ送信手順（または、比較手順、送信手順）、メッセージ格納手順を実行する。

なお、中継プログラムに係るプログラムモジュール１０９３やプログラムデータ１０９４は、ハードディスクドライブ１０３１に記憶される場合に限られず、例えば着脱可能な記憶媒体に記憶され、ディスクドライブ等を介してＣＰＵ１０２０によって読み出されてもよい。あるいは、中継プログラムに係るプログラムモジュール１０９３やプログラムデータ１０９４は、ネットワーク（ＬＡＮ（Local Area Network）、ＷＡＮ（Wide Area Network）等）を介して接続された他のコンピュータに記憶され、ネットワークインタフェース１０７０を介してＣＰＵ１０２０によって読み出されてもよい。

１０、１０Ａ ゲートウェイ
１１、１２ 通信部
１３ 記憶部
１４ 疎通監視部
１５ ＰＭＴＵ通知判定部
１６ ＰＭＴＵ通知部
２０Ａ〜２０Ｃ 端末
２１ 通知部
２２ ＰＭＴＵ設定部
３０ ルータ
４０ ＬＡＮ
５０ ＷＡＮ
１００ ネットワークシステム

Claims (9)

1. 広域通信網とローカル通信網との間で通信を中継する中継装置であって、
   前記ローカル通信網側の端末から前記広域通信網側の端末へのデータ送信に対する応答を監視する監視部と、
   前記監視部による監視に基づいて所定の時間以内に応答が返ってきたかを判定する判定部と、
   前記判定部によって所定の時間以内に応答がないと判定された場合には、１回に転送可能なデータ容量であって前記データ送信時のデータ容量よりも小さいデータ容量である転送可能容量を指示するメッセージを生成し、該メッセージを前記ローカル通信網側の端末に通知する通知部と
   を有し、
   前記判定部によって所定の時間以内に応答がないと判定された場合には、前記ローカル通信網側の端末から前記広域通信網側の端末へのデータ送信時よりも小さいデータ容量のデータを前記広域通信網側の端末へ送信し、該送信に対する応答が所定の時間以内にあるか否かを確認する確認部をさらに有し、
   前記通知部は、前記確認部によって所定の時間以内に応答があると確認された場合には、前記転送可能容量を指示するメッセージを生成し、該メッセージを前記ローカル通信網側の端末に通知することを特徴とする中継装置。
2. 広域通信網とローカル通信網との間で通信を中継する中継装置であって、
   前記ローカル通信網側の端末から前記広域通信網側の端末へのデータ送信に対する応答を監視する監視部と、
   前記監視部による監視に基づいて所定の時間以内に応答が返ってきたかを判定する判定部と、
   前記判定部によって所定の時間以内に応答がないと判定された場合には、１回に転送可能なデータ容量であって前記データ送信時のデータ容量よりも小さいデータ容量である転送可能容量を指示するメッセージを生成し、該メッセージを前記ローカル通信網側の端末に通知する通知部と
   を有し、
   前記広域通信網側の端末における宛先情報と、該広域通信網側の端末とデータ通信を行う際の転送可能容量とを対応付けて記憶する記憶部をさらに有し、
   前記監視部は、前記ローカル通信網側の端末から前記広域通信網側の端末へのデータ通信が行われる際に、該広域通信網側の端末の宛先情報に該当する宛先情報が記憶部に記憶されている場合には、該宛先情報に対応付けて記憶されている転送可能容量よりも前記データ通信における転送可能容量が大きいか否かを監視し、
   前記通知部は、宛先情報に対応付けて記憶されている転送可能容量よりも前記データ通信における転送可能容量が大きい場合には、前記広域通信網側の端末へのデータ通信を中止し、前記宛先情報に対応付けて記憶されている転送可能容量を指示するメッセージを生成し、該メッセージを前記ローカル通信網側の端末に通知することを特徴とする中継装置。
3. 広域通信網とローカル通信網との間で通信を中継する中継装置であって、
   前記ローカル通信網側の端末から前記広域通信網側の端末へのデータ送信に対する応答を監視する監視部と、
   前記監視部による監視に基づいて所定の時間以内に応答が返ってきたかを判定する判定部と、
   前記判定部によって所定の時間以内に応答がないと判定された場合には、１回に転送可能なデータ容量であって前記データ送信時のデータ容量よりも小さいデータ容量である転送可能容量を指示するメッセージを生成し、該メッセージを前記ローカル通信網側の端末に通知する通知部と
   を有し、
   前記通知部は、前記判定部によって所定の時間以内に応答がないと判定された回数が所定の回数以上となった場合には、前記広域通信網側の全ての端末へのデータ送信に対して、最小の転送可能容量を指示するメッセージを生成し、該メッセージを前記ローカル通信網側の端末に通知することを特徴とする中継装置。
4. 広域通信網とローカル通信網との間で通信を中継する中継装置であって、
   前記ローカル通信網側の端末から前記広域通信網側の端末へのデータ送信に対する応答を監視する監視部と、
   前記監視部による監視に基づいて所定の時間以内に応答が返ってきたかを判定する判定部と、
   前記判定部によって所定の時間以内に応答がないと判定された場合には、１回に転送可能なデータ容量であって前記データ送信時のデータ容量よりも小さいデータ容量である転送可能容量を指示するメッセージを生成し、該メッセージを前記ローカル通信網側の端末に通知する通知部と
   を有し、
   前記通知部は、アドレス範囲と該アドレス範囲を宛先とする通信に適用する転送可能容量、または、アドレスもしくはアドレス範囲以外の宛先への通信に適用する転送可能容量を指示するメッセージを生成し、該メッセージを前記ローカル通信網側の端末に通知することを特徴とする中継装置。
5. 広域通信網とローカル通信網との間で端末同士の通信を中継する中継装置で実行される中継方法であって、
   前記ローカル通信網側の端末から前記広域通信網側の端末へのデータ送信に対する応答を監視する監視工程と、
   前記監視工程による監視に基づいて所定の時間以内に応答が返ってきたかを判定する判定工程と、
   前記判定工程によって所定の時間以内に応答がないと判定された場合には、前記ローカル通信網側の端末から前記広域通信網側の端末へのデータ送信時よりも小さいデータ容量のデータを前記広域通信網側の端末へ送信し、該送信に対する応答が所定の時間以内にあるか否かを確認する確認工程と、
   前記確認工程によって所定の時間以内に応答があると確認された場合には、１回に転送可能なデータ容量であって前記データ送信時のデータ容量よりも小さいデータ容量である転送可能容量を指示するメッセージを生成し、該メッセージを前記ローカル通信網側の端末に通知する通知工程と
   を含んだことを特徴とする中継方法。
6. 広域通信網とローカル通信網との間で端末同士の通信を中継する中継装置で実行される中継方法であって、
   前記中継装置は、前記広域通信網側の端末における宛先情報と、該広域通信網側の端末とデータ通信を行う際の転送可能容量とを対応付けて記憶する記憶部を有し、
   前記ローカル通信網側の端末から前記広域通信網側の端末へのデータ通信が行われる際に、該広域通信網側の端末の宛先情報に該当する宛先情報が記憶部に記憶されている場合には、該宛先情報に対応付けて記憶されている転送可能容量よりも前記データ通信における転送可能容量が大きいか否かを監視するとともに、前記ローカル通信網側の端末から前記広域通信網側の端末へのデータ送信に対する応答を監視する監視工程と、
   前記監視工程による監視に基づいて所定の時間以内に応答が返ってきたかを判定する判定工程と、
   前記宛先情報に対応付けて記憶されている転送可能容量よりも前記データ通信における転送可能容量が大きい場合には、前記広域通信網側の端末へのデータ通信を中止し、前記宛先情報に対応付けて記憶されている転送可能容量を指示するメッセージを生成し、該メッセージを前記ローカル通信網側の端末に通知し、前記判定工程によって所定の時間以内に応答がないと判定された場合には、１回に転送可能なデータ容量であって前記データ送信時のデータ容量よりも小さいデータ容量である転送可能容量を指示するメッセージを生成し、該メッセージを前記ローカル通信網側の端末に通知する通知工程と
   を含んだことを特徴とする中継方法。
7. 広域通信網とローカル通信網との間で端末同士の通信を中継する中継装置で実行される中継方法であって、
   前記ローカル通信網側の端末から前記広域通信網側の端末へのデータ送信に対する応答を監視する監視工程と、
   前記監視工程による監視に基づいて所定の時間以内に応答が返ってきたかを判定する判定工程と、
   前記判定工程によって所定の時間以内に応答がないと判定された回数が所定の回数以上となった場合には、前記広域通信網側の全ての端末へのデータ送信に対して、１回に転送可能なデータ容量であって前記データ送信時のデータ容量よりも小さいデータ容量である最小の転送可能容量を指示するメッセージを生成し、該メッセージを前記ローカル通信網側の端末に通知する通知工程と
   を含んだことを特徴とする中継方法。
8. 広域通信網とローカル通信網との間で端末同士の通信を中継する中継装置で実行される中継方法であって、
   前記ローカル通信網側の端末から前記広域通信網側の端末へのデータ送信に対する応答を監視する監視工程と、
   前記監視工程による監視に基づいて所定の時間以内に応答が返ってきたかを判定する判定工程と、
   前記判定工程によって所定の時間以内に応答がないと判定された場合には、１回に転送可能なデータ容量であって前記データ送信時のデータ容量よりも小さいデータ容量である転送可能容量であって、アドレス範囲と該アドレス範囲を宛先とする通信に適用する転送可能容量、または、アドレスもしくはアドレス範囲以外の宛先への通信に適用する転送可能容量を指示するメッセージを生成し、該メッセージを前記ローカル通信網側の端末に通知する通知工程と
   を含んだことを特徴とする中継方法。
9. コンピュータを請求項１〜４のいずれか一つに記載の中継装置として機能させるための中継プログラム。

Images