(57)【要約】【課題】  変換対象のパケットを異なる形式のパケットに変換するパケット変換において、通信に先立つＰＭＴＵ検出を不要としながら再フラグメントを行っても、網での伝送遅延を小さくする。【解決手段】  本発明のパケット変換装置は、到来したパケットを異なる形式のパケットに変換し、到来したパケットがフラグメントパケットであり、再フラグメントパケットを形成して送出する場合には、変換済パケットのペイロードから、再フラグメントパケットの１パケット分以下のペイロード分を抽出し、抽出したペイロードに変換済パケットのヘッダを付与し、付与したヘッダの一部若しくはヘッダに対する誤り検出用情報を、再フラグメントパケット向けに修正した後、再フラグメントパケットを送出し、変換済パケットのペイロードの全てが、送出された再フラグメントパケットに分配されたかを確認し残りがある場合に、ペイロード抽出からの処理を繰り返すことを特徴とする。【選択図】      図１
2008277884.tif 000002
【特許請求の範囲】
【請求項１】
変換対象パケットが与えられると、上記変換対象パケットを異なる形式のパケットに変換して変換済パケットを形成するパケット変換手段と、
到来したパケットがフラグメントパケットであり、到来したフラグメントパケット、若しくは、到来したフラグメントパケットを上記パケット変換手段に与えて変換させた変換済フラグメントパケットについて、より小さいペイロードの再フラグメントパケットを形成して送出する場合には、到来したフラグメントパケット若しくは上記変換済フラグメントパケットのペイロードから、再フラグメントパケットの１パケット分又はそれより少ないペイロード分を抽出する再フラグメント用ペイロード抽出手段と、
上記再フラグメント用ペイロード抽出手段で抽出されたペイロードに、到来したフラグメントパケット若しくは上記変換済フラグメントパケットのヘッダを付与するヘッダ付与手段と、
上記ヘッダ付与手段により付与されたヘッダの一部若しくはヘッダに対する誤り検出用情報を、再フラグメントパケット向けに修正するヘッダ修正手段と、
上記ヘッダ修正手段の修正によって得られた再フラグメントパケットを、そのまま、若しくは、上記パケット変換手段に与えて変換させてから送出する再フラグメントパケット送出手段と、
到来したフラグメントパケット若しくは上記変換済フラグメントパケットのペイロードの全てが、上記再フラグメントパケット送出手段によって今まで送出された１又は複数の再フラグメントパケットのペイロードに分割して挿入されたかを確認し、挿入されていない場合に、上記再フラグメント用ペイロード抽出手段の処理を再起動させる終了判定手段と
を有することを特徴とするパケット変換装置。
【請求項２】
上記パケット変換手段は、上記変換対象パケットがＩＰｖ４パケットである場合は、上記変換対象パケットをＩＰｖ６パケットに変換して上記変換済パケットを形成することを特徴とする請求項１に記載のパケット変換装置。
【請求項３】
上記パケット変換手段は、上記変換対象パケットがＩＰｖ６パケットである場合は、上記変換対象パケットをＩＰｖ４パケットに変換して上記変換済パケットを形成することを特徴とする請求項１又は２に記載のパケット変換装置。
【請求項４】
変換対象パケットを異なる形式のパケットに変換して変換済パケットを形成して送出するパケット変換方法において、
パケット変換手段、再フラグメント用ペイロード抽出手段、ヘッダ付与手段、ヘッダ修正手段、再フラグメントパケット送出手段、終了判定手段を有し、
上記パケット変換手段は、変換対象パケットが与えられると、上記変換対象パケットを異なる形式のパケットに変換して変換済パケットを形成し、
上記再フラグメント用ペイロード抽出手段は、到来したパケットがフラグメントパケットであり、到来したフラグメントパケット、若しくは、到来したフラグメントパケットを上記パケット変換手段に与えて変換させた変換済フラグメントパケットについて、より小さいペイロードの再フラグメントパケットを形成して送出する場合には、到来したフラグメントパケット若しくは上記変換済フラグメントパケットのペイロードから、再フラグメントパケットの１パケット分又はそれより少ないペイロード分を抽出し、
上記ヘッダ付与手段は、上記再フラグメント用ペイロード抽出手段で抽出されたペイロードに、到来したフラグメントパケット若しくは上記変換済フラグメントパケットのヘッダを付与し、
上記ヘッダ修正手段は、上記ヘッダ付与手段により付与されたヘッダの一部若しくはヘッダに対する誤り検出用情報を、再フラグメントパケット向けに修正し、
上記再フラグメントパケット送出手段は、上記ヘッダ修正手段の修正によって得られた再フラグメントパケットを、そのまま、若しくは、上記パケット変換手段に与えて変換させてから送出し、
上記終了判定手段は、到来したフラグメントパケット若しくは上記変換済フラグメントパケットのペイロードの全てが、上記再フラグメントパケット送出手段によって今まで送出された１又は複数の再フラグメントパケットのペイロードに分割して挿入されたかを確認し、挿入されていない場合に、上記再フラグメント用ペイロード抽出手段の処理を再起動させる
ことを特徴とするパケット変換方法。
【請求項５】
コンピュータを、
変換対象パケットが与えられると、上記変換対象パケットを異なる形式のパケットに変換して変換済パケットを形成するパケット変換手段と、
到来したパケットがフラグメントパケットであり、到来したフラグメントパケット、若しくは、到来したフラグメントパケットを上記パケット変換手段に与えて変換させた変換済フラグメントパケットについて、より小さいペイロードの再フラグメントパケットを形成して送出する場合には、到来したフラグメントパケット若しくは上記変換済フラグメントパケットのペイロードから、再フラグメントパケットの１パケット分又はそれより少ないペイロード分を抽出する再フラグメント用ペイロード抽出手段と、
上記再フラグメント用ペイロード抽出手段で抽出されたペイロードに、到来したフラグメントパケット若しくは上記変換済フラグメントパケットのヘッダを付与するヘッダ付与手段と、
上記ヘッダ付与手段により付与されたヘッダの一部若しくはヘッダに対する誤り検出用情報を、再フラグメントパケット向けに修正するヘッダ修正手段と、
上記ヘッダ修正手段の修正によって得られた再フラグメントパケットを、そのまま、若しくは、上記パケット変換手段に与えて変換させてから送出する再フラグメントパケット送出手段と、
到来したフラグメントパケット若しくは上記変換済フラグメントパケットのペイロードの全てが、上記再フラグメントパケット送出手段によって今まで送出された１又は複数の再フラグメントパケットのペイロードに分割して挿入されたかを確認し、挿入されていない場合に、上記再フラグメント用ペイロード抽出手段の処理を再起動させる終了判定手段と
して機能させることを特徴とするパケット変換プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、パケット変換装置、パケット変換方法及びパケット変換プログラムに関し、例えば、ＩＰｖ４通信網とＩＰｖ６通信網との境界におけるゲートウェイ装置に適用し得る。
【背景技術】
【０００２】
例えば、ＩＰ通信によるネットワーク（ＩＰｖ４通信網、又は、ＩＰｖ６通信網）において、経路途中にＭＴＵ（Ｍａｘｉｍｕｍ  Ｔｒａｎｓｍｉｓｓｉｏｎ  Ｕｎｉｔ）サイズの小さなネットワークが存在する場合、ルータによって、ＩＰパケットのフラグメンテーションが行われる。しかし、フラグメント化と再構成は、ルータにとっても、通信相手のコンピュータにとっても負荷のかかる処理であり、可能ならば避けることが望ましい。そこで、予め通信ルートのＭＴＵが分かっていれば、最初からそのＭＴＵサイズに合わせて、フラグメンテーションの不要な適切なサイズのＩＰパケットを送信することができる。このような経路途中のＭＴＵサイズを調査する方法を「ＰＭＴＵ検出（Ｐａｔｈ  ＭＴＵ  ｄｉｓｃｏｖｅｒｙ）」といい、ＲＦＣ１１９１（非特許文献３）で標準化されている。
【０００３】
ＰＭＴＵの原理を簡単に説明する。ＤＦフラグ（フラグメント禁止フラグ）を有効にして、サイズをいろいろに変更したＩＰパケットを送信してみる。ＭＴＵサイズを超える大きなパケットをＤＦフラグ付きで送信すると、その直前のルータから「ＩＣＭＰあて先不達」のメッセージが戻ってくる（このときに、ＩＣＭＰヘッダ中に正しいＭＴＵ値をセットしてから返すように求められている）。これにより、特定のネットワークにおけるＭＴＵサイズを知ることができる。但し、フラグメント化されたパケットのルーティングや、（セキュリティ上の理由などによって）それに対するＩＣＭＰあて先不達メッセージの送信を禁止しているようなルータがあれば（このようなルータは外部に対しては何もメッセージを返さないから「ブラックホール・ルータ」と呼ばれることがある）、このＰＭＴＵ機能は正しく働かない。そのため、Ｗｉｎｄｏｗｓ（登録商標）  ＯＳなどでも、この機能を使うかどうかをレジストリで制御することができるようにしている（非特許文献５）。
【０００４】
又、ＩＰｖ４パケットと、ＩＰｖ６パケットの相互変換時のヘッダ領域のマッピング方法や、ＩＰｖ４パケットをＩＰｖ６化したときにＭＴＵを超過する場合は、ヘッダ領域の変換前にフラグメント処理する必要があることに関してＲＦＣ２７６５（非特許文献４）に規定されている。
【非特許文献１】ＩＥＴＦ，「ＲＦＣ７９１“ＩＮＴＥＲＮＥＴ  ＰＲＯＴＯＣＯＬ”」
【非特許文献２】ＩＥＴＦ，「ＲＦＣ１８１２“Ｒｅｑｕｉｒｅｍｅｎｔｓ  ｆｏｒ  ＩＰ  Ｖｅｒｓｉｏｎ  ４  Ｒｏｕｔｅｒｓ”」
【非特許文献３】ＩＥＴＦ，「ＲＦＣ１１９１“Ｐａｔｈ  ＭＴＵ  Ｄｉｓｃｏｖｅｒｙ”」
【非特許文献４】ＩＥＴＦ，「ＲＦＣ２７６５“Ｓｔａｔｅｌｅｓｓ  ＩＰ／ＩＣＭＰ  Ｔｒａｎｓｌａｔｉｏｎ  Ａｌｇｏｒｉｔｈｍ（ＳＩIＴ）”」
【非特許文献５】Ｍｉｃｒｏｓｏｆｔ，「Ｍｉｃｒｏｓｏｔ  Ｗｉｎｄｏｗｓ２０００ＴＣＰ／ＩＰ実装詳細」，[Online]，INTERNET，[２００７年４月４日検索]，＜ＵＲＬ：http://www.microsoft.com/japan/technet/itsolutions/network/deploy/depovg/tcpip2k.mspx＞
【非特許文献６】ＩＥＴＦ，「ＲＦＣ２４６０“Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ  Ｖｅｒｓｉｏｎ  ６  （ＩＰＶ６）  Ｓｐｅｃｉｆｉｃａｔｉｏｎ」
【発明の開示】
【発明が解決しようとする課題】
【０００５】
現状、フラグメントパケットをさらに小さく分割しなければならない場合、その小さなＭＴＵの設定されたネットワーク装置（例えばルータ）において、全てのフラグメントパケットを集積し元のパケットを再構築してから、さらに小さなＭＴＵに合わせて再分割し、新たなフラグメントパケットを生成するのが一般的である。この手法では、途中のネットワーク装置で元のパケットを構築する時間及び再度フラグメントパケットを生成する時間が必要となるため、このような分割が必要となるポイント毎に遅延要因が増大することになり、通信障害が発生する可能性が高まる。
【０００６】
また、ＰＭＴＵ検出においては、パケット送信元がパケットの宛先毎にＰＭＴＵを把握する必要があり、実際の通信に先立って通信を行おうとする相手毎にＰＭＴＵを検出するための処理を行わなければならない。また、その通信経路上にＩＣＭＰパケットの通過を阻害するネットワーク機器がある場合には、ＰＭＴＵ検出の機能が働かない。
【０００７】
さらに、ＩＰｖ４−ＩＰｖ６間のパケット変換が必要な場合は、ｖ６ヘッダ長の方がｖ４ヘッダ長よりも長いため、ｖ４からｖ６への変換時にフラグメント処理されたパケットがＭＴＵを超過するような事態が起こりやすいという問題がある。
【０００８】
そのため、変換対象のパケットを異なる形式のパケットに変換するパケット変換において、通信に先立つＰＭＴＵ検出を不要としながら、再フラグメントを行っても、網での伝送遅延を小さくできるパケット変換装置、パケット変換方法及びパケット変換プログラムが望まれている。
【課題を解決するための手段】
【０００９】
第１の本発明のパケット変換装置は、（１）変換対象パケットが与えられると、上記変換対象パケットを異なる形式のパケットに変換して変換済パケットを形成するパケット変換手段と、（２）到来したパケットがフラグメントパケットであり、到来したフラグメントパケット、若しくは、到来したフラグメントパケットを上記パケット変換手段に与えて変換させた変換済フラグメントパケットについて、より小さいペイロードの再フラグメントパケットを形成して送出する場合には、到来したフラグメントパケット若しくは上記変換済フラグメントパケットのペイロードから、再フラグメントパケットの１パケット分又はそれより少ないペイロード分を抽出する再フラグメント用ペイロード抽出手段と、（３）上記再フラグメント用ペイロード抽出手段で抽出されたペイロードに、到来したフラグメントパケット若しくは上記変換済フラグメントパケットのヘッダを付与するヘッダ付与手段と、（４）上記ヘッダ付与手段により付与されたヘッダの一部若しくはヘッダに対する誤り検出用情報を、再フラグメントパケット向けに修正するヘッダ修正手段と、（５）上記ヘッダ修正手段の修正によって得られた再フラグメントパケットを、そのまま、若しくは、上記パケット変換手段に与えて変換させてから送出する再フラグメントパケット送出手段と、（６）到来したフラグメントパケット若しくは上記変換済フラグメントパケットのペイロードの全てが、上記再フラグメントパケット送出手段によって今まで送出された１又は複数の再フラグメントパケットのペイロードに分割して挿入されたかを確認し、挿入されていない場合に、上記再フラグメント用ペイロード抽出手段の処理を再起動させる終了判定手段とを有することを特徴とする。
【００１０】
第２の本発明のパケット変換方法は、（０）変換対象パケットを異なる形式のパケットに変換して変換済パケットを形成して送出するパケット変換方法において、パケット変換手段、再フラグメント用ペイロード抽出手段、ヘッダ付与手段、ヘッダ修正手段、再フラグメントパケット送出手段、終了判定手段を有し、（１）上記パケット変換手段は、変換対象パケットが与えられると、上記変換対象パケットを異なる形式のパケットに変換して変換済パケットを形成し、（２）上記再フラグメント用ペイロード抽出手段は、到来したパケットがフラグメントパケットであり、到来したフラグメントパケット、若しくは、到来したフラグメントパケットを上記パケット変換手段に与えて変換させた変換済フラグメントパケットについて、より小さいペイロードの再フラグメントパケットを形成して送出する場合には、到来したフラグメントパケット若しくは上記変換済フラグメントパケットのペイロードから、再フラグメントパケットの１パケット分又はそれより少ないペイロード分を抽出し、（３）上記ヘッダ付与手段は、上記再フラグメント用ペイロード抽出手段で抽出されたペイロードに、到来したフラグメントパケット若しくは上記変換済フラグメントパケットのヘッダを付与し、（４）上記ヘッダ修正手段は、上記ヘッダ付与手段により付与されたヘッダの一部若しくはヘッダに対する誤り検出用情報を、再フラグメントパケット向けに修正し、（５）上記再フラグメントパケット送出手段は、上記ヘッダ修正手段の修正によって得られた再フラグメントパケットを、そのまま、若しくは、上記パケット変換手段に与えて変換させてから送出し、（６）上記終了判定手段は、到来したフラグメントパケット若しくは上記変換済フラグメントパケットのペイロードの全てが、上記再フラグメントパケット送出手段によって今まで送出された１又は複数の再フラグメントパケットのペイロードに分割して挿入されたかを確認し、挿入されていない場合に、上記再フラグメント用ペイロード抽出手段の処理を再起動させることを特徴とする。
【００１１】
第３の本発明のパケット変換プログラムは、コンピュータを、（１）変換対象パケットが与えられると、上記変換対象パケットを異なる形式のパケットに変換して変換済パケットを形成するパケット変換手段と、（２）到来したパケットがフラグメントパケットであり、到来したフラグメントパケット、若しくは、到来したフラグメントパケットを上記パケット変換手段に与えて変換させた変換済フラグメントパケットについて、より小さいペイロードの再フラグメントパケットを形成して送出する場合には、到来したフラグメントパケット若しくは上記変換済フラグメントパケットのペイロードから、再フラグメントパケットの１パケット分又はそれより少ないペイロード分を抽出する再フラグメント用ペイロード抽出手段と、（３）上記再フラグメント用ペイロード抽出手段で抽出されたペイロードに、到来したフラグメントパケット若しくは上記変換済フラグメントパケットのヘッダを付与するヘッダ付与手段と、（４）上記ヘッダ付与手段により付与されたヘッダの一部若しくはヘッダに対する誤り検出用情報を、再フラグメントパケット向けに修正するヘッダ修正手段と、（５）上記ヘッダ修正手段の修正によって得られた再フラグメントパケットを、そのまま、若しくは、上記パケット変換手段に与えて変換させてから送出する再フラグメントパケット送出手段と、（６）到来したフラグメントパケット若しくは上記変換済フラグメントパケットのペイロードの全てが、上記再フラグメントパケット送出手段によって今まで送出された１又は複数の再フラグメントパケットのペイロードに分割して挿入されたかを確認し、挿入されていない場合に、上記再フラグメント用ペイロード抽出手段の処理を再起動させる終了判定手段として機能させることを特徴とする。
【発明の効果】
【００１２】
本発明によれば、変換対象のパケットを異なる形式のパケットに変換するパケット変換において、通信に先立つＰＭＴＵ検出を不要としながら、再フラグメントを行っても、網での伝送遅延を小さくすることができる。
【発明を実施するための最良の形態】
【００１３】
（Ａ）実施形態
以下、本発明によるパケット変換装置、パケット変換方法及びパケット変換プログラムの実施形態を、図面を参照しながら詳述する。
【００１４】
（Ａ−１）実施形態の構成
図２は、この実施形態に関係する各種装置の接続関係などの説明図である。
【００１５】
ここでは、ＩＰｖ４網１−６に属する第１のノード１−１（例えば、通信端末）と、ＩＰｖ６網１−７に属する第２のノード１−２の間で交換されるトラフィックが、ＩＰｖ４網１−６とＩＰｖ６網１−７の境界に配置された、実施形態のパケット変換装置を搭載しているｖ４／ｖ６変換通信装置１−３を必ず通ることを前提とする。ｖ４／ｖ６変換通信装置１−３において、第１のノード１−１側のインタフェース１−４と、第２のノード１−２側のインタフェース１−５とで、異なる値のＭＴＵが設定されているとき、ＭＴＵの値が小さいインタフェースからＭＴＵの値が大きいインタフェースにトラフィックが流れる場合は問題ないが、ＭＴＵの値が大きいインタフェースからＭＴＵが小さいインタフェースにトラフィックが流れる場合はフラグメント処理が必要になる。又、ＩＰｖ４網１−６とＩＰｖ６網１−７のＭＴＵサイズが同じであったとしても、ＩＰｖ６ヘッダ長の方がＩＰｖ４ヘッダ長よりも長いため、ＩＰｖ４からＩＰｖ６への変換時にフラグメント処理されたパケットがＭＴＵを超過する場合もフラグメント処理が必要になる。
【００１６】
通常のパケットのフラグメント処理はＲＦＣ７９１（非特許文献１）、ＲＦＣ２４６０（非特許文献６）で規定されている通りで問題ないが、フラグメントパケットを、さらにフラグメント処理する場合は、全てのフラグメントパケットを収集して元のパケットを構築してから再度フラグメントを行う方式が一般的である。また、ＲＦＣ２７６５（非特許文献４）においては、ＩＰｖ４／ｖ６ヘッダ変換を行う前にフラグメント処理するべきであることが規定されている。
【００１７】
図３は、ＩＰｖ４パケットのヘッダフォーマットを示す説明図である。図３に示すヘッダフォーマットにおいて、フラグメントに関係するのは、フラグメントの組立のための識別値が挿入される「Ｉｄｅｎｔｉｆｉｃａｔｉｏｎ」と、Ｂｉｔ１（以下、ＤＦフラグと呼ぶ）にフラグメントの可／不能が挿入され、Ｂｉｔ２（以下、ＭＦフラグと呼ぶ）に最後のフラグメントかフラグメントの継続かが挿入される「Ｆｌａｇｓ」と、元のデータのどこにフラグメントの先頭が属するかを指示する「フラグメントオフセット」とである。この点に着目すると、ＩＰｖ４においてフラグメントパケットの再フラグメントが必要になった場合には、「Ｉｄｅｎｔｉｆｉｃａｔｉｏｎ」、「Ｆｌａｇｓ」、「フラグメントオフセット」及びヘッダのヘッダチェックサムだけを書き換えれば良いことが分かる。
【００１８】
図４は、ＩＰｖ６パケットのフラグメント拡張ヘッダフォーマットを示す説明図であり、図５は、ＩＰｖ６パケットの（基本）ヘッダフォーマットを示す説明図である。
【００１９】
ＩＰｖ６において、フラグメントに関係するのは、フラグメント拡張ヘッダフォーマットの「Ｉｄｅｎｔｉｆｉｃａｔｉｏｎ」、「Ｆｌａｇｓ（ＭＦフラグのみ）」、「フラグメントオフセット」だけであるので、フラグメントパケットの再フラグメントが必要になった場合には、上記の値だけを書き換えれば良いことが分かる。
【００２０】
この実施形態は、ＩＰｖ４パケット又はＩＰｖ６パケットにおいて再フラグメントが必要になった場合に、以上のような書き換え対象が限定されていることに着目し、元のパケットに戻す冗長な処理を不要としたものである。ネットワークの途中で何度もフラグメントパケットを元のパケットに戻す冗長な処理を不要にすると、遅延の改善やパケット損失率の改善につながる。
【００２１】
図６は、ｖ４／ｖ６変換通信装置１−３の機能的構成を示すブロック図である。ここで、ｖ４／ｖ６変換通信装置１−３は、例えば、ハードウェア的な通信部の他は、通信処理やデータ処理（ｖ４／ｖ６のプロトコル変換、再フラグメント処理を含む）等を実行するためのＣＰＵ、ＲＯＭ、ＲＡＭ等を有しており、ＣＰＵが実行するプログラム（実施形態のパケット変換プログラムを含む）がインストールされている。上述したプログラムを含め、ｖ４／ｖ６変換通信装置１−３の機能的構成を示すと図６に示すようになる。
【００２２】
図６において、ｖ４／ｖ６変換通信装置１−３は、トラフィック識別部５−１、ｖ４／ｖ６変換処理部５−２、出力インタフェース部（出力ＩＦ部）５−３、５−５、及び、制御部５−４を有する。
【００２３】
トラフィック識別部５−１は、当該通信装置３に入力される全てのトラフィックを識別するものである。トラフィック識別部５−１は、当該ｖ４／ｖ６変換通信装置１−３宛のパケットを制御部５−４に与え、それ以外のトラフィックをｖ４／ｖ６変換処理部５−２に与えるものである。
【００２４】
制御部５−４は、当該ｖ４／ｖ６変換通信装置１−３の全体を制御するものである。制御部５−４は、例えば、各出力インタフェース部５−３、５−５のＭＴＵの値等の情報を管理しており、ｖ４／ｖ６変換処理部５−２にそれらの情報を伝達するものである。なお、各出力インタフェース部５−３、５−５のＭＴＵの値は、制御部５−４への設定次第で自由に変更可能である。
【００２５】
ｖ４／ｖ６変換処理部５−２は、図７、図８、図１に示すパケット処理（ＩＰｖ４／ＩＰｖ６パケット変換処理、フラグメント処理、再フラグメント処理を含む）を行い、処理後のトラフィックを出力インタフェース部５−３、５−５に与えるものである（なお、処理によりパケットが廃棄されることもあり得る）。なお、ｖ４／ｖ６変換処理部５−２における、ＩＰｖ４／ＩＰｖ６パケット変換処理は、例えば、ＲＦＣ２７６５（非特許文献４）の内容に基づいて行っても良い。
【００２６】
各出力インタフェース部５−３、５−５は、担当する方向へのトラフィックの送出を行うものである。出力インタフェース部５−３は、ＩＰｖ６網１−７にパケットを送出するものであり、出力インタフェース部５−５は、ＩＰｖ４網１−６にパケットを送出するものである。
【００２７】
（Ａ−２）実施形態の動作
次に、上述したｖ４／ｖ６変換処理部５−２が実行する、ｖ４／ｖ６変換通信装置１−３が受信し、中継するパケットの処理を、図７、図８、図１のフローチャートを参照しながら説明する。
【００２８】
（Ａ−２−１）ＩＰｖ６からＩＰｖ４へのパケット変換
まず、ｖ４／ｖ６変換通信装置１−３の、ＩＰｖ６パケットから、ＩＰｖ４パケットへの変換処理の動作について説明する。
【００２９】
図７は、ｖ４／ｖ６変換通信装置１−３の、ＩＰｖ６パケットから、ＩＰｖ４パケットへの変換処理のフローチャートである。図１は、図７の「再フラグメント処理」の詳細を示すフローチャートである。
【００３０】
ｖ４／ｖ６変換処理部５−２は、初期状態において（ステップ３−１）、当該装置が中継する受信パケット（変換対象のＩＰｖ６パケット）が与えられると、変換対象のＩＰｖ６パケットのヘッダの、ＩＰｖ４ヘッダへの変換・付け替え処理をする（ステップ３−２）。
【００３１】
ここでは、ステップ３−２における変換処理は、概ねＲＦＣ２７６５（非特許文献４）に従い、次のように行われるものとする。
【００３２】
ｖｅｒｓｉｏｎ値を４、ＩＨＬ値を５（ＲＦＣ２７６５の規定に倣い、「オプションヘッダ無し」を示す最小値５とする）、ＴｏＳ領域はＩＰｖ６ヘッダのＴｒａｆｆｉｃＣｌａｓｓ領域を複製、ＴｏｔａｌＬｅｎｇｔｈ値はＩＰｖ６ヘッダのＰａｙｌｏａｄ  ｌｅｎｇｔｈ値にＩＰｖ４ヘッダ長２０バイトを加算した値、Ｉｄｅｎｔｉｆｉｃａｔｉｏｎ値はＩＰｖ６フラグメントオプションヘッダのＩｄｅｎｔｉｆｉｃａｔｉｏｎ値の下位１６ビットを複製、ＤＦフラグは０、ＭＦフラグはＩＰｖ６フラグメントオプションヘッダのＭＦフラグを複製、フラグメントオフセット値はＩＰｖ６フラグメントオプションヘッダのフラグメントオフセット値を複製、ＴＴＬ値はＩＰｖ６ヘッダのＨｏｐＬｉｍｉｔ値を複製、送信元アドレス／宛先アドレスはＩＰｖ６ヘッダ記載のアドレスに対応するＩＰｖ４アドレスに付け替え、ヘッダチェックサムは上記の書き換えた値を用いて所定の算出をした値とする。なお、送信元アドレス／宛先アドレスの付け替えは、ＩＰｖ４アドレスとＩＰｖ６アドレスの１対１対応付けを、ｖ４／ｖ６変換処理部５−２が記憶して管理したものを適用しても良いし、変換後のＩＰｖ６アドレスの下位３２ビットを、変換前のＩＰｖ４アドレスの内容として適用しても良い。
【００３３】
次に、変換後のＩＰｖ４パケットの上述したＭＦフラグが１（フラグメント継続）となっているか否かを判別する（ステップ３−５）。ＭＦフラグが１となっている場合は、別のフラグメントパケットが続くことを示しており、このことは、変換前のＩＰｖ６パケットが、最初かあるいは途中のフラグメントパケットであることを意味している。
【００３４】
ＭＦフラグが１（フラグメント継続）となっている場合には、ｖ４／ｖ６変換処理部５−２において、変換後のＩＰｖ４パケットのパケット長と、出力インタフェース部５−５に設定されたＭＴＵの値とが比較される（ステップ３−７）。パケット長がＭＴＵを越えている場合には、図１に詳細を示す再フラグメント処理が実行（ステップ３−９）された後、出力インタフェース部５−５から、再フラグメント処理で分離されたパケットを送出させ（ステップ３−１１）、一方、パケット長がＭＴＵ以下の場合には、出力インタフェース５−５から、変換後のＩＰｖ４パケットをそのまま送出させる（ステップ３−１１）。
【００３５】
なお、図１では、ステップ３−９の再フラグメント処理には、分離パケットの送出処理を含まないように記載しているが、後述する再フラグメント処理の詳細処理の説明から明らかなように、再フラグメント処理の一連の処理の中で、ステップ３−１１に相当する分離パケットの送出処理が実行される。
【００３６】
ＭＦフラグが０（フラグメント終了）の場合（ステップ３−５でＦａｌｓｅ）には、ｖ４／ｖ６変換処理部５−２は、さらに、変換後のＩＰｖ４パケットの上述したフラグメントオフセットの値が０となっているか否かを判別する（ステップ３−６）。
【００３７】
フラグメントオフセットの値が０以外の場合は、変換対象のＩＰｖ６パケットが最終のフラグメントパケットであることを意味している。この場合には、ｖ４／ｖ６変換処理部５−２は、他のフラグメントパケット（最初あるいは途中のフラグメントパケット）と同様に処理する（ステップ３−７、３−９、３−１１）。
【００３８】
フラグメントオフセットの値が０の場合には、そのパケットがフラグメントパケットとして分割されていない、通常のパケットであることを意味している。この場合には、ｖ４／ｖ６変換処理部５−２は、出力インタフェース５−５のＭＴＵと、変換後のＩＰｖ４パケットのパケット長を比較する（ステップ３−８）。パケット長がＭＴＵを越えている場合には、ＲＦＣ７９１（非特許文献１）に規定されているフラグメント処理が実行され（ステップ３−１０）、出力インタフェース５−５から、フラグメント処理で分割されたパケットを送出させ（ステップ３−１１）、一方、変換後のＩＰｖ４パケットのパケット長がＭＴＵ以下の場合には、出力インタフェース部５−５から、変換後のＩＰｖ４パケットをそのまま送出させる（ステップ３−１１）。
【００３９】
次に、上述したステップ３−９における再フラグメント処理の詳細を、図１のフローチャートを参照しながら説明する。
【００４０】
この処理では、３つの変数（パラメータ）Ｎ、Ｌ、Ｕを用いる。変数Ｎは、フラグメントの分割回数を表し、変数Ｌは、ＩＰヘッダを除いた搬送対象となるデータのペイロード長（搬送されずに残っているペイロード長）を表し（単位は［バイト］）、変数Ｕは、１パケット（分離後の１パケット）当たりに搬送できるデータのペイロード長である（単位は［バイト］）。
【００４１】
変数Ｕは、ＭＴＵの定められたインタフェース毎に固有の値であり、フラグメントオフセットが８バイト単位となっているため、（１）式によって表すことができる。（１）式において、ＩＨＬ（Ｉｎｔｅｒｎｅｔ  Ｈｅａｄｅｒ  Ｌｅｎｇｔｈ）に４を掛けているのは、ＩＨＬがロングワード（３２ビット＝４バイト）単位の値となっているので、バイト単位に変換するためである。
【００４２】
Ｕ＝（｛（出力ＩＦのＭＴＵ）−（ＩＨＬ×４）｝／８の小数点以下切下げ整数）×８
…（１）
再フラグメント処理が開始された時点では、他の２つの変数Ｎ、Ｌの値は、（２）式、（３）式のように定義されている。すなわち、ｖ４／ｖ６変換処理部５−２は、初期化処理で、変数Ｎ、Ｌの値を（２）式、（３）式に示す初期値に設定する（ステップ４−１）。
【００４３】
Ｎ＝０                                                              …（２）
Ｌ＝（パケット長）−｛４×（ＩＨＬ）｝                              …（３）
続いて、ｖ４／ｖ６変換処理部５−２は、搬送対象ペイロードの初めから先頭１パケット（Ｕバイト）分のペイロードを分離する（ステップ４−２）。次に、分離したペイロードに対する処理を行い、元のフラグメントパケット（処理対象となっている変換後のＩＰｖ４パケット）のＩＰヘッダが付与され、フラグメントオフセットの値が、（４）式で表される値に書き換えられる（ステップ４−３）。但し、Ｎ＝０の場合には、フラグメントオフセットの値は元のフラグメントパケットのフラグメントオフセット値と同一である。
【００４４】
フラグメントオフセット＝（元パケットのオフセット値）＋Ｎ×Ｕ／８    …（４）
その後、変数Ｌを、Ｌ＝Ｌ−Ｕに更新すると共に、変数Ｎを１インクリメントする（ステップ４−４）。
【００４５】
続いて、ｖ４／ｖ６変換処理部５−２は、変数Ｌが変数Ｕ以下か否かを判別する（ステップ４−５）。この判別は、元のフラグメントパケットにおける、分離パケットへの移行がなされていない残りのペイロードが１パケット分以下か否かの判別になっている。
【００４６】
変数Ｌが変数Ｕの値を超えていれば、１分離パケットに納まりきらないため、ｖ４／ｖ６変換処理部５−２は、分離したパケットのＭＦフラグを１にし、ＩＰヘッダのチェックサムを再計算し、該当する出力インタフェース部５−３又は５−５から、分離パケットを送出した後（ステップ４−６；図７のステップ３−１１参照）、上述したステップ４−２からステップ４−５までの処理を繰り返す。このようにして戻ったステップ４−２でのペイロード分離は、残っている中の先頭側からの１パケット分の分離である。
【００４７】
ステップ４−５の判別で、変数Ｌが変数Ｕの値以下であるという結果を得る場合は、残りのペイロード部分が、１分離パケットに納まる場合である。そこで、ｖ４／ｖ６変換処理部５−２は、残りのペイロードに、元フラグメントパケットのＩＰヘッダを付与し、フラグメントオフセットの値を上述した（４）式で計算された値に書き換える（ステップ４−７）。
【００４８】
次に、ｖ４／ｖ６変換処理部５−２は、元のフラグメントパケットのＭＦフラグが１となっているか否かを判別する（ステップ４−８）。
【００４９】
元のフラグメントパケットのＭＦフラグが１となっている場合は、その後に到来する元のフラグメントパケットを分離した分離パケットが継続することを示すため、ｖ４／ｖ６変換処理部５−２は、そのままＭＦフラグを１とし、ＩＰヘッダのチェックサムを再計算して書き換え（ステップ４−９）、該当する出力インタフェース部５−３又は５−５から分離パケットを送出させ（ステップ４−１１；図７のステップ３−１１参照）、再フラグメント処理を完了する。
【００５０】
これに対して、ＭＦフラグが０となっている場合は、この元のフラグメントパケットが最終フラグメントとなっていることを意味しており、最終の元のフラグメントパケットから分離した最終の分離パケットであるため、ｖ４／ｖ６変換処理部５−２は、そのままＭＦフラグを０とし、ＩＰヘッダのチェックサムを再計算して書き換え（ステップ４−１０）、該当する出力インタフェース部５−３又は５−５から分離パケットを送出させ（ステップ４−１１；図７のステップ３−１１参照）、再フラグメント処理を完了する。
【００５１】
（Ａ−２−２）ＩＰｖ４からＩＰｖ６へのパケット変換
図８は、ｖ４／ｖ６変換通信装置１−３の、ＩＰｖ４パケットから、ＩＰｖ６パケットへの変換処理のフローチャートである。
【００５２】
ｖ４／ｖ６変換処理部５−２は、初期状態において（ステップ６−１）、当該装置が中継する受信パケット（変換対象のＩＰｖ４パケット）が与えられると、その変換対象のＩＰｖ４パケットの上述したＤＦフラグが１（フラグメント不能）となっているか否かを判別する（ステップ６−２）。
【００５３】
ＤＦフラグが１となっている場合（フラグメント不能である場合）には、ｖ４／ｖ６変換処理部５−２は、変換対象のＩＰｖ４パケットのヘッダをＩＰｖ６のヘッダに変換処理する（ステップ６−３）。
【００５４】
ここでは、ＩＰｖ４パケットからＩＰｖ６パケットへの変換処理におけるヘッダ変換処理の内容は以下の通りとする。
【００５５】
まず、ｖ４／ｖ６変換処理部５−２は、変換対象のＩＰｖ４パケットのＭＦフラグ、又は、フラグメントオフセットのいずれかが０でないかどうかを判別し、いずれかが０でない場合（変換対象のＩＰｖ４パケットがフラグメントパケットであった）は、変換にあたって、ＩＰｖ６フラグメント拡張ヘッダを付与する。ここでは、ｖ４／ｖ６変換処理部５−２は、以下のようにしてＩＰｖ６フラグメント拡張ヘッダを付与するものとする。
【００５６】
ＭＦフラグの値は、ＩＰｖ４ヘッダのＭＦフラグを複製、Ｉｄｅｎｔｉｆｉｃａｔｉｏｎ値については上位１６ビットは０とし、下位１６ビットはＩＰｖ４ヘッダのＩｄｅｎｔｉｆｉｃａｔｉｏｎ値を複製、フラグメントオフセット値はＩＰｖ４ヘッダのフラグメントオフセット値を複製、次ヘッダはＩＰｖ４ヘッダのプロトコル値を複製するものとする。
【００５７】
また、上述の図５に示すＩＰｖ６基本ヘッダは以下のような要領で生成されるものとする。
【００５８】
Ｖｅｒｓｉｏｎ値は６に書き換え、
ＴｒａｆｆｉｃＣｌａｓｓ値はＩＰｖ４ヘッダのＴｏＳフィールドの値を複製、フローラベルは０、ＰａｙｌｏａｄＬｅｎｇｔｈ値はＩＰｖ４ヘッダのＴｏｔａｌＬｅｎｇｔｈ値からＩＨＬ値×４（ＩＰｖ４ヘッダ長）を引いた値に書き換え、次ヘッダ値はフラグメント拡張ヘッダを付与する場合はフラグメント拡張ヘッダの値、フラグメント拡張ヘッダを付与しない場合はＩＰｖ４ヘッダのプロトコル領域を複製、送信元アドレス／宛先アドレスはＩＰｖ６ヘッダ記載のアドレスに対応するＩＰｖ４アドレスに付け替える。なお、送信元アドレス／宛先アドレスの付け替えは、ＩＰｖ６アドレスとＩＰｖ４アドレスの１対１対応付けについて、ｖ４／ｖ６変換処理部５−２が記憶して管理したものを適用しても良いし、ＩＰｖ４射影ＩＰｖ６アドレス（上位９６ビットが０ｘＦＦＦＦ、下位３２ビットがＩＰｖ４アドレスの複製）として適用しても良い。
【００５９】
次に、ｖ４／ｖ６変換処理部５−２は、出力インタフェース部５−３又のＭＴＵと、変換対象のパケットのパケット長とを比較する（ステップ６−４）。そして、パケット長がＭＴＵを越えている場合には、変換対象のＩＰｖ４パケット及び変換後のＩＰｖ６パケットを廃棄し（ステップ６−５）、一方、パケット長がＭＴＵ以下の場合には、出力インタフェース部５−３から、変換後のＩＰｖ６パケットをそのまま送出させる（ステップ６−１３）。
【００６０】
ＭＦフラグが１（フラグメント継続）となっている場合には、ｖ４／ｖ６変換処理部５−２は、まず、上述のステップ６−３と同様に、変換対象のパケットのヘッダをＩＰｖ４からＩＰｖ６に変換処理する（ステップ６−６）。
【００６１】
次に、変換後のＩＰｖ６パケットの上述したＭＦフラグが１（フラグメント継続）となっているか否かを判別する（ステップ６−７）。ＭＦフラグが１となっている場合は、別のフラグメントパケットが続くことを示しており、このことは、変換前のＩＰｖ４パケットが、最初かあるいは途中のフラグメントパケットであることを意味している。
【００６２】
ＭＦフラグが１（フラグメント継続）となっている場合には、ｖ４／ｖ６変換処理部５−２において、変換後のＩＰｖ６パケットのパケット長と、出力インタフェース部５−３に設定されたＭＴＵの値とが比較される（ステップ６−９）。パケット長がＭＴＵを越えている場合には、後述する再フラグメント処理が実行（ステップ６−１１）された後、出力インタフェース部５−３から、再フラグメント処理で分離されたパケットを送出させ（ステップ６−１３）、一方、パケット長がＭＴＵ以下の場合には、出力インタフェース５−３から、変換後のＩＰｖ６パケットをそのまま送出させる（ステップ６−１３）。
【００６３】
ＭＦフラグが０（フラグメント終了）の場合（ステップ６−７でＦａｌｓｅ）には、ｖ４／ｖ６変換処理部５−２は、さらに、変換後のＩＰｖ６パケットの上述したフラグメントオフセットの値が０となっているか否かを判別する（ステップ６−８）。
【００６４】
フラグメントオフセットの値が０以外の場合は、変換前のＩＰｖ４パケットが最終のフラグメントパケットであることを意味している。この場合には、ｖ４／ｖ６変換処理部５−２は、他のフラグメントパケット（最初あるいは途中のフラグメントパケット）と同様に処理する（ステップ６−９、６−１１、６−１３）。
【００６５】
フラグメントオフセットの値が０の場合には、そのパケットがフラグメントパケットとして分割されていない、通常のパケットであることを意味している。この場合には、ｖ４／ｖ６変換処理部５−２は、出力インタフェース５−３のＭＴＵと、変換後のＩＰｖ６パケットのパケット長とを比較する（ステップ６−１０）。パケット長がＭＴＵを越えている場合には、ＲＦＣ２４６０（非特許文献６）に規定されているフラグメント処理が実行され（ステップ６−１２）、出力インタフェース５−３から、フラグメント処理で分割されたパケットを送出させ（ステップ６−１３）、一方、変換後のＩＰｖ６パケットのパケット長がＭＴＵ以下の場合には、出力インタフェース部５−３から、変換後のＩＰｖ６パケットをそのまま送出させる（ステップ６−１３）。
【００６６】
上述のステップ６−１１における再フラグメント処理は、上述の図１と同様の処理であるのでその詳しい説明を省略する。上述の図１では、ＩＰｖ４パケットを再フラグメント処理の対象としていたが、ここではＩＰｖ６パケットを対象とし、ヘッダのデータの書き換えはＩＰｖ６フラグメント拡張ヘッダ（上述の図４参照）、基本ヘッダ（上述の図５参照）における同一名称のデータが書き換えられる点で異なっている。又、ここでは、判別に使用されるＭＴＵ値は出力インタフェース部５−３（ＩＰｖ６網１−７へパケットを送出するためのインタフェース）のＭＴＵ値が適用されること、ＩＰｖ６のヘッダにはＩＰｖ４のヘッダチェックサムに該当するデータが無いため、ヘッダチェックサムの書き換えが不要である点で、上述の図１の処理とは異なっている。
【００６７】
又、ここでは、ＩＰｖ６パケットでの再フラグメント処理では、パラメータの初期値は以下のようなものとする。
【００６８】
Ｎ＝０                                                              …（５）
Ｌ＝ＰａｙｌｏａｄＬｅｎｇｔｈ値                                    …（６）
Ｕ＝１パケットで搬送できるペイロード長
＝（｛（出力インタフェース部5-3のMTU）−４０｝／８の小数点以下切下げ整数）×８
（ＩＰｖ６ヘッダが基本ヘッダのみの場合）
又は、
（｛（出力インタフェース部5-3のMTU）−４８｝／８の小数点以下切下げ整数）×８
（ＩＰｖ６ヘッダが基本ヘッダ＋フラグメント拡張ヘッダの場合）      …（７）
（Ａ−３）の実施形態の効果
上記実施形態によれば、ｖ４／ｖ６変換通信装置１−３が、既にフラグメントされたＩＰパケットを変換対象のＩＰパケットとして受信し、更にフラグメントが必要な場合であっても、変換対象のフラグメントパケットの系列から元のパケットを再構築することなく、変換対象のフラグメントパケット毎の逐次処理で、受信したフラグメントパケットに対する再フラグメント化を実行しており、エンドツーエンドの伝送遅延を小さくすることができる。
【００６９】
また、ネットワークの途中で元のパケットを再構築する機会を削減しているので、再構築失敗による通信障害の可能性を削減することができる。
【００７０】
さらに、元のパケットを再構築していた場合の伝送遅延に対処するＰＭＴＵ検出のような処理を、通信に先立って行う必要がないため、即座に任意の通信先に対して通信が可能となり、また、ＩＣＭＰパケットを阻害するルータに影響を受けることもない。
【００７１】
以上のように、上記実施形態によれば、ＩＰｖ４網の通信ノードと、ＩＰｖ６網の通信ノード間の通信において、通信開始までの時間の短縮、フラグメントパケットの処理遅延の短縮、パケット損失率の削減等を期待することができる。
【００７２】
（Ｂ）他の実施形態
本発明は、上記の実施形態に限定されるものではなく、以下に例示するような変形実施形態も挙げることができる。
【００７３】
（Ｂ−１）  上記実施形態では、パケット変換装置をｖ４／ｖ６変換通信装置自体に搭載した場合を示したが、ｖ４／ｖ６変換通信装置に対する外付け装置（コネクタ接続、ケーブル接続は問わない）として、ｖ４／ｖ６変換通信装置を構築するようにしても良い。なお、パケット変換装置を搭載又は外付けする通信装置の種類は限定されないものである。
【００７４】
また、上記実施形態では、パケット変換プログラムと、ＣＰＵなどの汎用的なプログラムの実行構成とでパケット変換装置を構築した場合を示したが、上述した図１、図７、図８の処理を行う専用装置としてパケット変換装置を構築しても良く、その専用装置がＩＣチップとして構築しても良い。
【００７５】
（Ｂ−２）上記実施形態では、ｖ４／ｖ６変換通信装置は、到来したフラグメントパケットをＩＰｖ４／ＩＰｖ６パケット変換をしてからフラグメント又は再フラグメントを行っているが（上述の図７、図８参照）、フラグメント又は再フラグメントを行った後に、パケット変換を行っても良い。その際、ｖ４／ｖ６変換通信装置は、到来したフラグメントパケットについて、パケット変換後のヘッダ長及びパケット長を予測し、フラグメント又は再フラグメントの要否について判定をして、再フラグメントが必要と判定した場合にのみ再フラグメントを行っても良い。上述の図３、図４、図５に示すように、ＩＰｖ４のヘッダ長、及び、ＩＰｖ６のヘッダ長（基本ヘッダ、及び、フラグメント拡張ヘッダ）やその構成は予め明らかであるので、これらの情報に基づいて、パケット変換後のヘッダ長、及び、パケット長（ヘッダ長にペイロード長を加算）を予測しても良い。なお、ＩＰｖ４パケットからＩＰｖ６パケットに変換した後のヘッダ長を予測する際に、変換前のＩＰｖ４パケットがフラグメントパケットである場合には、変換後のＩＰｖ６パケットには上述の図４に示すフラグメント拡張ヘッダが付加されるので、その分ヘッダ長が長くなる。
【００７６】
（Ｂ−３）  上記実施形態では、パケット変換装置をｖ４／ｖ６変換通信装置に搭載し、ＩＰｖ４からＩＰｖ６へのパケット変換、及び、ＩＰｖ６からＩＰｖ４へのパケット変換を１つの装置で行う場合を示したが、ＩＰｖ４からＩＰｖ６へのパケット変換のみ、又は、ＩＰｖ６からＩＰｖ４へのパケット変換のみを行う装置として構築しても良い。
【００７７】
又、上記の実施形態では、ＩＰｖ４／ＩＰｖ６パケットの変換に適用したものを示したが、適用されるパケットの種類はＩＰｖ４、ＩＰｖ６に限定されるものではない。
【図面の簡単な説明】
【００７８】
【図１】実施形態の再フラグメント処理の詳細を示すフローチャートである。
【図２】実施形態に関係する各種装置の接続関係などの説明図である。
【図３】ＩＰｖ４パケットの（基本）ヘッダフォーマットを示す説明図である。
【図４】ＩＰｖ６パケットのフラグメント拡張ヘッダフォーマットを示す説明図である。
【図５】ＩＰｖ６パケットのヘッダフォーマットを示す説明図である。
【図６】実施形態のパケット変換装置が搭載されているｖ４／ｖ６変換通信装置の機能的構成を示すブロック図である。
【図７】実施形態のｖ４／ｖ６変換処理部が実行するＩＰｖ６パケットから、ＩＰｖ４パケットの変換処理を示すフローチャートである。
【図８】実施形態のｖ４／ｖ６変換処理部が実行するＩＰｖ４パケットから、ＩＰｖ６パケットの変換処理を示すフローチャートである。
【符号の説明】
【００７９】
１―１、１−２…ノード、１−３…ｖ４／ｖ６変換通信装置（パケット変換装置を搭載）、１−６…ＩＰｖ４網、１−７…ＩＰｖ６網、５−１…トラフィック識別部、５−２…ｖ４／ｖ６変換処理部、５−３、５−５…出力インタフェース部、５−４…制御部。
【図１】
2008277884.tif 000003
【図２】
2008277884.tif 000004
【図３】
2008277884.tif 000005
【図４】
2008277884.tif 000006
【図５】
2008277884.tif 000007
【図６】
2008277884.tif 000008
【図７】
2008277884.tif 000009
【図８】
2008277884.tif 000010