(57)【要約】【課題】  ＰＰＰ,Ｌ２ＴＰの処理を行う装置上に接続中ユーザの情報テーブルを作成し、接続要求を行っているユーザが同一ＩＤにて重複接続を行おうとしていないかを常時監視する。既に情報テーブルにあるユーザが同一ＩＤで接続要求を行っている場合には接続処理を終了させ、そうでない場合は接続処理を続行する。接続中ユーザの情報テーブルユーザの接続/切断時に更新される。【解決手段】  ユーザーＩＤとパスワードにて認証を行う認証サーバーと連携し、ユーザーにインターネット接続環境を提供するサービスを可能とする装置において、接続中ユーザーのユーザーＩＤ情報テーブルを装置内に作成し、新規に接続要求を行ってくるユーザーのＩＤとそのテーブルの情報とを照らし合わせ、同一のＩＤにて重複した接続が行われないよう装置側にて抑止を行う。【選択図】  図３
2007174005.tif 000002
【特許請求の範囲】
【請求項１】
ユーザーＩＤとパスワードにて認証を行う認証サーバーと連携し、ユーザーにインターネット接続環境を提供するサービスを可能とする装置において、接続中ユーザーのユーザーＩＤ情報テーブルを装置内に作成し、新規に接続要求を行ってくるユーザーのＩＤとそのテーブルの情報とを照らし合わせ、同一のＩＤにて重複した接続が行われないよう装置側にて同一ＩＤによる多重セッション取得抑止方法。
【請求項２】
請求項１において、接続要求を行っているユーザーのユーザーＩＤを、ユーザーＩＤをデータとして含むパケットから抽出し、これを接続中ユーザーのユーザーＩＤ情報テーブルを検索する際の条件とする同一ＩＤによる多重セッション取得抑止方法。
【請求項３】
請求項１において、接続要求を行っているユーザーのユーザーＩＤを、ユーザーＩＤをデータとして含むパケットから抽出し、抽出したユーザーＩＤがすでにユーザーＩＤ情報テーブル上に存在する場合、これを重複接続の要求であると判断し、接続処理を中止することを特徴とする同一ＩＤによる多重セッション取得抑止方法。
【請求項４】
請求項１において、接続要求を行っているユーザーのユーザーＩＤを、ユーザーＩＤをデータとして含むパケットから抽出し、抽出したユーザーＩＤがすでにユーザーＩＤ情報テーブル上に存在しない場合、新規接続要求であると判断し、接続処理を続行することを特徴とする同一ＩＤによる多重セッション取得抑止方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ユーザーアカウントを認証に使用してユーザーにインターネット接続環境を提供する回線事業者側装置の同一ＩＤによる多重セッション取得抑止方法に関するものである。
【背景技術】
【０００２】
ポイント・ツウ・ポイントプロトコル（PPP:Point to Point Protocol）を使用し、ユーザーアカウント（ユーザーＩＤとユーザーパスワード）にて認証を行い、契約ユーザーに対しインターネット環境を提供するサービスが一般的に行われている。回線事業者によっては、ユーザーアカウントを見て、接続先のインターネットサービスプロバイダー（ＩＳＰ）を自由に切換えることが出来るＰＰＰｏＥマルチセッションサービスを行っている例もある。本来、ＰＰＰｏＥマルチセッションとは加入者宅から複数のＰＰＰｏＥ（ＰＰＰ）セッションをそれぞれ個別に異なるＩＳＰに確立して行うものである。
【０００３】
しかしながら、現状の回線事業者の装置では、同一のＩＳＰに同一アカウントで複数の接続要求があった場合、回線事業者側で許可しているセッション数限界まで、セッションを確立できる場合がある。これは、ＩＳＰ側の認証サーバーで重複認証を許可している場合に起こり得る。
この問題をＩＳＰ側で防ぐには、認証サーバーにてユーザーの接続状況を把握しておき、重複して接続要求が来た場合には、これを拒否するように設定することが必要になる。
【０００４】
また、ユーザーの接続情報がＩＳＰの認証サーバー上と回線事業者側の装置とで、同期出来ていない状態（ＩＳＰの認証サーバーでは接続中のステータスであるが、回線事業者側の装置では未接続である、といった状態）になると、ユーザーは未接続の状態から接続要求を行っているにも関わらず、接続できないといった問題が出てくる可能性があった。
【０００５】
【特許文献１】特開２００５−３３９０９３号公報
【発明の開示】
【発明が解決しようとする課題】
【０００６】
解決しようとする問題点は、回線事業者側の装置にてユーザーＩＤをチェックし、重複接続を抑止できない点である。
【課題を解決するための手段】
【０００７】
本発明は、接続中ユーザーのユーザーＩＤ情報テーブルを回線事業者の装置内に保持しておき、接続要求がある毎に、テーブル内を検索し、重複接続で無ければ接続を許可、且つテーブル情報を更新し、重複接続であれば拒否するものである。
【発明の効果】
【０００８】
本発明によれば、回線事業者側でのＰＰＰｏＥマルチセッションサービスは従来通り提供可能であるとともに、インターネットサービスプロバイダー（ＩＳＰ）毎にＰＰＰｏＥ（ＰＰＰ）セッション数を回線事業者側で制限でき、インターネットプロバイダーＩＳＰ側での重複接続に対する対策が不要である。また、接続中ユーザーのユーザーＩＤ情報テーブルは装置内に接続要求毎に作成、更新可能であるため、別途機器、事前のユーザー情報の登録作業も不要となる。
【発明を実施するための最良の形態】
【０００９】
ＰＰＰｏＥマルチセッションサービスを行っている回線事業者を利用してインターネットサービスプロバイダー（ＩＳＰ）がサービスを行う形態において、ＩＳＰ側にて重複接続への対策が不要になるように構成した点にある。
【００１０】
本発明は、回線事業者の装置のアクセスコンセントレータ（AC=Access Concentrator）側での対処とＬＮＳ(L2TP Network Server)側での対処が考えられる。接続中ユーザーの情報テーブルと照らし合わせるユーザーＩＤは、ＡＣ側においてはＰＡＰ、ＣＨＡＰのパケットから、ＬＮＳ側ではＰＡＰ、ＣＨＡＰ以外にＬ２ＴＰのＩＣＣＮパケットから抽出が可能である。まず、本発明を未導入のサービスの問題点と、導入した場合の効果について説明する。
【００１１】
図１は、本発明を未導入である回線事業者網側の装置にてＰＰＰｏＥマルチセッションサービスを行っている回線事業者と、その回線事業者を利用しているＩＳＰの概略図である。
【００１２】
ＩＳＰの認証サーバー１０３では、重複認証のチェックをしていないものとする。この場合、図１のＡＣ、ＬＮＳ１０２の接続ユーザー情報テーブル１０４のユーザー情報１０５、１０６のように、ユーザー端末１０１からの重複接続が可能となる。現在ＩＳＰの認証サーバー１０３にて重複接続に対処する方法があるが、この場合ＩＳＰの認証サーバー１０３のユーザー接続情報テーブル１０９と、回線事業者側のユーザー接続状況との同期を常に取っておく必要がある。同期を取っておく理由としては、次の場合が挙げられる。
【００１３】
図２において、回線事業者側網の装置（ＡＣ、ＬＮＳ）２０２上においてはユーザーが未接続の状態（２０５）であるが、なんらかの理由により、ＩＳＰの認証サーバー２０３上のユーザー接続情報テーブル２０９に情報が残っていた場合（２１０）、回線事業者側網の装置（ＡＣ、ＬＮＳ）２０２では端末２０１からの当該ユーザー（user001＠isp001.com）の接続を受け入れ可能な状態にありながら、ＩＳＰの認証サーバー２０３にて、本来接続を許可すべきユーザーを重複接続として拒否してしまう。このため、回線事業者側網の装置（ＡＣ、ＬＮＳ）２０２とＩＳＰの認証サーバー２０３上のユーザー接続情報テーブル２０９は常に同期を取っておく必要がある。
【００１４】
本発明は、上述した問題を是正するためになされたものであり、例えば図３のように、ユーザー端末３０１から送出されるユーザーＩＤをデータに含むパケット３１３からユーザーＩＤを抽出（抽出部３０５）し、回線事業者側網の装置（ＡＣ、ＬＮＳ）３０２のユーザー情報テーブル３０４を検索（検索部３０６）し、その検索の結果、重複するようであれば、接続処理を中止する。重複しないようであればそのまま通常どおり接続処理を続行するようにしたものである。このため、ＩＳＰの認証サーバー３０３においては、ユーザーの重複接続の確認を行う必要が無く、認証のために送られてきたユーザーアカウントが正しいかどうかを確認するだけでよい。その結果、回線事業者側網の装置（ＡＣ、ＬＮＳ）のユーザー接続情報テーブル３０４とＩＳＰの認証サーバーのユーザー接続情報テーブル３０９間でデータの同期をとる必要が無くなるというメリットがある。次に、ポイント・ツウ・ポイントプロトコル（ＰＰＰ）を用いてサービスを提供している回線事業者が主に使っているプロトコル（ＰＡＰ、ＣＨＡＰ、Ｌ２ＴＰ）に関して、重複接続チェックの具体的な方法について説明する。
【実施例１】
【００１５】
図４はＰＡＰを認証に使用している場合の、重複接続チェックのフローチャートである。ここで使われるＰＡＰの端末３０１と回線事業者側網の装置（ＡＣ、ＬＮＳ）間の認証シーケンスを図７に示す。
【００１６】
図７のＰＡＰでは端末３０１がユーザーＩＤとパスワード含むＰＡＰ Ａｕｔｈｅｎｔｉｃａｔｅ Ｒｅｑｕｅｓｔパケット７０１をＡＣまたはＬＮＳ３０２に対して送出する。正常に認証されると、ＡＣまたはＬＮＳはＰＡＰ Ａｕｔｈｅｎｔｉｃａｔｅ ＡＣＫパケット７０２を端末３０１に送出し、認証完了を通知する。本発明では、回線事業者側網の装置（アクセスコンセントレータＡＣ、ＬＮＳ）にて端末３０１から送出されるＰＡＰ Ａｕｔｈｅｎｔｉｃａｔｅ ＲｅｑｕｅｓｔパケットからユーザーＩＤを抽出する。従って、回線事業者側網の装置（アクセスコンセントレータＡＣ、ＬＮＳ）には、ユーザーＩＤを抽出するユーザーＩＤ抽出部（図３の３１４）が設けられている。
【００１７】
図４において、回線事業者側網の装置（ＡＣ、ＬＮＳ）３０２は、ステップ４０１において、端末３０１からのＰＡＰ ａｕｔｈｅｎｔｉｃａｔｅ ｒｅｑｕｅｓｔパケットを受信し（図７のパケット７０１）、ステップ４０２にて、受信したパケットのデータ部にあるＰｅｅｒ−ＩＤよりユーザーＩＤを抽出する。次に、ステップ４０３において、ステップ４０２で抽出したユーザーＩＤと同一のＩＤがＡＣまたはＬＮＳ上の接続ユーザー情報テーブルに無いかどうか検索を行い、ステップ４０４において、当該ユーザーが接続中であるかどうかの判断を行う。接続ユーザー情報テーブル３０４に同一のユーザーＩＤが存在しない場合は、ステップ４０６にて当該ユーザーの接続処理を続行し、ステップ４０７にて接続ユーザー情報テーブル３０４に当該ユーザーの情報を追加、更新を行う。一方、ステップ４０３での検索の結果、当該ユーザーが接続中で合った場合には、ステップ４０５にて接続処理を中止する。
【実施例２】
【００１８】
図５はＣＨＡＰを認証に使用している場合の、重複接続チェックのフローチャートである。ここで使われるＣＨＡＰの端末と回線事業者側網の装置（ＡＣ、ＬＮＳ）３０２間の認証シーケンスを図８に示しておく。ＣＨＡＰでは、最初に端末３０１が回線事業者側網の装置（ＡＣ、ＬＮＳ）３０２からのＣＨＡＰ チャレンジ（Challenge）パケット８０１を受信する。受信したＣＨＡＰ チャレンジ（Challenge）パケット８０１には乱数データが入っており、端末３０１ではユーザーアカウント情報と、この乱数からハッシュ値を計算する。ハッシュ値の計算後、端末はユーザーＩＤとハッシュ値をＣＨＡＰ レスポンス（response）パケット８０２として回線事業者側網の装置（ＡＣ、ＬＮＳ）３０２に送出する。正常に認証が完了すると、回線事業者側網の装置（ＡＣ、ＬＮＳ）３０２は、Ｃｈａｐ サクセス（success）パケット８０３を端末３０１に送出し、認証完了を通知する。本発明では、ＣＨＡＰ レスポンスパケット８０２からユーザーＩＤを抽出する。
【００１９】
図５のステップ５０１において、回線事業者側網の装置（ＡＣ、ＬＮＳ）３０２は、ＣＨＡＰ レスポンスパケット８０２を受信し、ステップ５０２にて、受信したパケット８０２のデータ部内のＮａｍｅ部よりユーザーＩＤを抽出する。次に、ステップ５０３において、ステップ５０２で抽出したユーザーＩＤと同一のＩＤが、回線事業者側網の装置（ＡＣ、ＬＮＳ）３０２上の接続ユーザー情報テーブルに無いかどうか検索を行い、ステップ５０４にて当該ユーザーが接続中であるかどうかの判断を行う。接続ユーザー情報テーブルに同一のユーザーＩＤが存在しない場合は、ステップ５０６にて当該ユーザーの接続処理を続行し、ステップ５０７において接続ユーザー情報テーブルに当該ユーザーの情報を追加し、更新を行う。一方、ステップ５０３での検索の結果、当該ユーザーが接続中であった場合には、ステップにて接続処理を中止する。
【実施例３】
【００２０】
図６は、Ｌ２ＴＰ-ＩＣＣＮパケットのＰｒｏｘｙＡｕｔｈｅｎＮａｍｅからユーザーＩＤを抽出し、重複接続チェックを行う場合のフローチャートである。Ｌ２ＴＰでは端末３０１と回線事業者側網の装置（ＬＮＳ）間でＰＰＰセッションを確立する際に、ＬＮＳの対向装置であるＬＡＣ（L2TP Access Concentrator）と、図９で示されるメッセージの交換が行われる。図９において、LACが端末３０１からの接続要求を検知すると、Ｌ２ＴＰ-ＩＣＲＱ（L2TP Incoming−Call−Request）９０１を回線事業者側網の装置（ＬＮＳ）３０２に送出し、セッションの確立要求を行う。回線事業者側網の装置（ＬＮＳ）３０２は、この要求にＬ２ＴＰ-ＩＣＲＰ（L2TP Incoming−Call−Reply）９０２で応答する。ＬＡＣは、ステップ９０２にてＬ２ＴＰ−ＩＣＲＰを受信すると、セッション確立要求が受け入れられたとして、ユーザーＩＤなどの情報が含まれたＬ２ＴＰ-ＩＣＣＮ（L2TP Incoming−Call−Connected）９０３を回線事業者側網の装置（ＬＮＳ）３０２に送出する。回線事業者側網の装置（ＬＮＳ）３０２は、このＬ２ＴＰ-ＩＣＣＮ９０３を受信すると、受信完了通知として、ＺＬＢ（Zero−Length−Body）９０４をＬＡＣに送出する。本発明では、Ｌ２ＴＰ-ＩＣＣＮ９０３からユーザーＩＤを抽出する。
【００２１】
図６のステップ６０１において、このＬ２ＴＰ−ＩＣＣＮパケットを受信し（図９の９０３のパケット）、ステップ６０２にて、受信したパケットからユーザーＩＤを抽出する。次に、ステップ６０３において、ステップ６０２で抽出したユーザーＩＤと同一のＩＤが、回線事業者側網の装置（ＬＮＳ）３０２上の接続ユーザー情報テーブル３０４に無いかどうか検索を行い、ステップ６０４にて当該ユーザーが接続中であるかどうかの判断を行う。接続ユーザー情報テーブルに同一のユーザーＩＤが存在しない場合は、ステップ６０６にて当該ユーザーの接続処理を続行し、ステップ６０７にて接続ユーザー情報テーブルに当該ユーザーの情報を追加し、更新を行う。一方、ステップ６０３での検索の結果、当該ユーザーが接続中で合った場合には、ステップ６０５にて接続処理を中止する。
【産業上の利用可能性】
【００２２】
回線事業者側にてユーザーＩＤ単位での重複接続が抑止可能であり、ＩＳＰ側が重複接続への対処を考慮せずに済むため、同一ＩＤでの同一ＩＳＰへの重複接続問題に対処したＰＰＰｏＥマルチセッションサービスが提供できる。
【図面の簡単な説明】
【００２３】
【図１】本発明を未導入である装置を用いたＰＰＰｏＥマルチセッションサービスを行っている回線事業者を利用した場合の重複接続の模様を示す図である。
【図２】ＩＳＰの認証サーバーにて重複接続に対処した場合の問題点を説明する図である。
【図３】本発明を導入済の装置を用いたＰＰＰｏＥマルチセッションサービスを行っている回線事業者を利用した場合のサービスの模様を示す図である。
【図４】ＡＣ、またはＬＮＳがＰＡＰ Ａｕｔｈｅｎｔｉｃａｔｅ ｒｅｑｕｅｓｔパケットからユーザーＩＤを調査し、重複接続のチェックを行う場合のフローチャートである。
【図５】ＡＣ、またはＬＮＳがＣＨＡＰ ｒｅｓｐｏｎｓｅパケットからユーザーＩＤを調査し、重複接続のチェックを行う場合のフローチャートである。
【図６】ＬＮＳがＬ２ＴＰ-ＩＣＣＮパケットからユーザーＩＤを調査し、重複接続のチェックを行う場合のフローチャートである。
【図７】端末とＡＣ、またはＬＮＳ間のＰＡＰのシーケンスである。
【図８】端末とＡＣ、またはＬＮＳ間のＣＨＡＰのシーケンスである。
【図９】ＬＡＣ、ＬＮＳ間にてＬ２ＴＰセッションを確立するＩＣＲＱ、ＩＣＲＰ、ＩＣＣＮなどのシーケンスである。
【符号の説明】
【００２４】
１０１： ユーザー端末
１０２： ＡＣ（Access Concentrator）,ＬＮＳ（L2TP Network Server）
１０３： ＩＳＰの認証サーバー
１０４： ＡＣ,ＬＮＳ上の接続ユーザー情報テーブル
１０５： ＡＣ,ＬＮＳ上の接続ユーザー情報テーブルに登録されている接続中ユーザーmailto:（user001＠isp001.com）のユーザーＩＤ
１０６： ＡＣ,ＬＮＳ上の接続ユーザー情報テーブルに登録されている接続中ユーザー(user001＠isp001.com)のユーザーＩＤ
１０７： ＡＣ,ＬＮＳ上の接続ユーザー情報テーブルに登録されている接続中ユーザー(user002＠isp001.comのユーザーＩＤ
１０８： ＡＣ,ＬＮＳ上の接続ユーザー情報テーブルに登録されている接続中ユーザー(user003＠isp001.com)のユーザーＩＤ
１０９： ＩＳＰの認証サーバー上の接続ユーザー情報テーブル
１１０： ＩＳＰの認証サーバー上の接続ユーザー情報テーブルに登録されている接続中ユーザー( user001＠isp001.com)のユーザーＩＤ
１１１： ＩＳＰの認証サーバー上の接続ユーザー情報テーブルに登録されている接続中ユーザー( user001＠isp001.com)のユーザーＩＤ
１１２： ＩＳＰの認証サーバー上の接続ユーザー情報テーブルに登録されている接続中ユーザー(user002＠isp001.com)のユーザーＩＤ
１１３： ＩＳＰの認証サーバー上の接続ユーザー情報テーブルに登録されている接続中ユーザー( user003＠isp001.com)のユーザーＩＤ
２０１： ユーザー端末
２０２： ＡＣ（Access Concentrator）,ＬＮＳ（L2TP Network Server）
２０３： ＩＳＰの認証サーバー
２０４： ＡＣ,ＬＮＳ上の接続ユーザー情報テーブル
２０５： ＩＳＰの認証サーバー上の接続ユーザー情報テーブルとアンマッチになっている部分
２０６： ＡＣ,ＬＮＳ上の接続ユーザー情報テーブルに登録されている接続中ユーザー
(user002＠isp001.com)のユーザーＩＤ
２０７： ＡＣ,ＬＮＳ上の接続ユーザー情報テーブルに登録されている接続中ユーザー
(user003＠isp001.com)のユーザーＩＤ
２０８： ＡＣ,ＬＮＳ上の接続ユーザー情報テーブルに登録されている接続中ユーザー
(user004＠isp001.com)のユーザーＩＤ
２０９： ＩＳＰの認証サーバー上の接続ユーザー情報テーブル
２１０： ＩＳＰの認証サーバー上の接続ユーザー情報テーブルに登録されている接続中ユーザー(user001＠isp001.com)のユーザーＩＤ
２１１： ＩＳＰの認証サーバー上の接続ユーザー情報テーブルに登録されている接続中ユーザー(user002＠isp001.com)のユーザーＩＤ
２１２： ＩＳＰの認証サーバー上の接続ユーザー情報テーブルに登録されている接続中ユーザー(user003＠isp001.com)のユーザーＩＤ
２１３： ＩＳＰの認証サーバー上の接続ユーザー情報テーブルに登録されている接続中ユーザー(user004＠isp001.com)のユーザーＩＤ
３０１： ユーザー端末
３０２： ＡＣ（Access Concentrator）、ＬＮＳ（L2TP Network Server）
３０３： ＩＳＰの認証サーバー
３０４： ＡＣ,ＬＮＳ上の接続ユーザー情報テーブル
３０５： ＡＣ,ＬＮＳ上の接続ユーザー情報テーブルに登録されている接続中ユーザー
(user001＠isp001.com)のユーザーＩＤ
３０６： ＡＣ,ＬＮＳ上の接続ユーザー情報テーブルに登録されている接続中ユーザー
(user002＠isp001.com)のユーザーＩＤ
３０７： ＡＣ,ＬＮＳ上の接続ユーザー情報テーブルに登録されている接続中ユーザー
(user003＠isp001.com)のユーザーＩＤ
３０８： ＡＣ,ＬＮＳ上の接続ユーザー情報テーブルに登録されている接続中ユーザー
(user004＠isp001.com)のユーザーＩＤ
３０９： ＩＳＰの認証サーバー上の接続ユーザー情報テーブル
３１０： ＩＳＰの認証サーバー上の接続ユーザー情報テーブルに登録されている接続中ユーザー( user001＠isp001.com)のユーザーＩＤ
３１１： ＩＳＰの：認証サーバー上の接続ユーザー情報テーブルに登録されている接続中ユーザー(user002＠isp001.com)のユーザーＩＤ
３１２： ＩＳＰの認証サーバー上の接続ユーザー情報テーブルに登録されている接続中ユーザー(user003＠isp001.com)のユーザーＩＤ
３１３： ＩＳＰの認証サーバー上の接続ユーザー情報テーブルに登録されている接続中ユーザー(user004＠isp001.com)のユーザーＩＤ
３１４： ユーザーＩＤをデータに含むパケット
４０１： ＡＣ,ＬＮＳでのＰＡＰ Ａｕｔｈｅｎｔｉｃａｔｅ ｒｅｑｕｅｓｔパケット受信処理
４０２： ＰＡＰ Ａｕｔｈｅｎｔｉｃａｔｅ ｒｅｑｕｅｓｔパケットからのユーザーＩＤ抽出処理
４０３： 接続ユーザー情報テーブル内の検索処理
４０４： 検索結果からの次処理判断
４０５： 接続処理停止
４０６： 接続処理続行
４０７： 当該ユーザーＩＤの接続ユーザー情報テーブルへの登録処理
５０１： ＡＣ,ＬＮＳでのＣＨＡＰ Ｒｅｓｐｏｎｓｅパケット受信処理
５０２： ＣＨＡＰ ＲｅｓｐｏｎｓｅパケットからのユーザーＩＤ抽出処理
５０３： 接続ユーザー情報テーブル内の検索処理
５０４： 検索結果からの次処理判断
５０５： 接続処理停止
５０６： 接続処理続行
５０７： 当該ユーザーＩＤの接続ユーザー情報テーブルへの登録処理
６０１： ＬＮＳでのＬ２ＴＰ-ＩＣＣＮパケット受信処理
６０２： Ｌ２ＴＰ-ＩＣＣＮパケットからのユーザーＩＤ抽出処理
６０３： 接続ユーザー情報テーブル内の検索処理
６０４： 検索結果からの次処理判断
６０５： 接続処理停止
６０６： 接続処理続行
６０７： 当該ユーザーIDの接続ユーザー情報テーブルへの登録処理
７０１： ＰＡＰ Ａｕｔｈｅｎｔｉｃａｔｅ Ｒｅｑｕｅｓｔパケット
７０２： ＰＡＰ Ａｕｔｈｅｎｔｉｃａｔｅ ＡＣＫパケット
８０１： Ｃｈａｐ ｃｈａｌｌｅｎｇｅパケット
８０２： Ｃｈａｐ ｒｅｓｐｏｎｓｅパケット
８０３： Ｃｈａｐ ｓｕｃｃｅｓｓパケット
９０１： Ｌ２ＴＰ-ＩＣＲＱ （L2TP Incoming−Call−Request）パケット
９０２： Ｌ２ＴＰ-ＩＣＲＰ （L2TP Incoming−Call−Reply）パケット
９０３： Ｌ２ＴＰ-ＩＣＣＮ （L2TP Incoming−Call−Connected）パケット
９０４： ＺＬＢ （Zero Length Body）パケット
【図１】
2007174005.tif 000003
【図２】
2007174005.tif 000004
【図３】
2007174005.tif 000005
【図４】
2007174005.tif 000006
【図５】
2007174005.tif 000007
【図６】
2007174005.tif 000008
【図７】
2007174005.tif 000009
【図８】
2007174005.tif 000010
【図９】
2007174005.tif 000011