RFC 2637 - ポイントツーポイントトンネリングプロトコル (PPTP)
- ステータス: Informational
- 発行日: July 1999
- ストリーム: IETF
- エラッタ: エラッタなし
概要 (Abstract)
本文書は、ポイントツーポイントプロトコル (Point-to-Point Protocol, PPP) を IP ネットワーク経由でトンネリングすることを可能にするプロトコルを規定します。PPTP は PPP プロトコル自体に変更を加えるのではなく、PPP を伝送するための新しい手段を記述します。現在のネットワークアクセスサーバー (Network Access Server, NAS) に存在する機能を分離し、仮想プライベートネットワーク (Virtual Private Network, VPN) をサポートするために、クライアント・サーバーアーキテクチャが定義されています。PPTP ネットワークサーバー (PNS) は汎用オペレーティングシステム上で動作することが想定されており、PPTP アクセスコンセントレーター (PAC) と呼ばれるクライアントはダイヤルアクセスプラットフォーム上で動作します。PPTP は、PSTN または ISDN から発信されるダイヤルイン回線交換呼の接続をサーバーが制御したり、アウトバウンド回線交換接続を開始したりすることを可能にする呼制御および管理プロトコルを規定します。PPTP は、PPP パケットを伝送するためのフロー制御および輻輳制御機能を持つカプセル化データグラムサービスを提供する、拡張 GRE (Generic Routing Encapsulation) メカニズムを使用します。
目次 (Contents)
- 1. Introduction (序論)
- 1.1 Protocol Goals and Assumptions (プロトコルの目標と前提)
- 1.2 Terminology (用語)
- 1.3 Protocol Overview (プロトコル概要)
- 1.4 Message Format and Protocol Extensibility (メッセージフォーマットとプロトコル拡張性)
- 2. Control Connection Protocol Specification (制御接続プロトコル仕様)
- 2.1-2.16 メッセージタイプ定義
- 3. Control Connection Protocol Operation (制御接続プロトコル操作)
- 3.1 Control Connection States (制御接続状態)
- 3.2 Call States (呼状態)
- 4. Tunnel Protocol Operation (トンネルプロトコル操作)
- 4.1 Enhanced GRE Header (拡張 GRE ヘッダー)
- 4.2 Sliding Window Protocol (スライディングウィンドウプロトコル)
- 4.3 Out-of-sequence Packets (順序不同パケット)
- 4.4 Acknowledgment Time-Outs (確認応答タイムアウト)
- 5. Security Considerations (セキュリティに関する考慮事項)
- 6. Authors' Addresses (著者連絡先)
- 7. References (参考文献)
- 8. Full Copyright Statement (完全な著作権表示)
関連リソース
- 公式原文: RFC 2637
- 公式ページ: RFC 2637 DataTracker
- 正誤表: RFC Editor Errata
1. 序論 (Introduction)
PPTP は、クライアント・サーバーアーキテクチャを使用して、既存のネットワークアクセスサーバー (Network Access Server, NAS) の機能を分離することを可能にします。従来、NAS は以下の機能を実装していました。
-
PSTN または ISDN への物理的なネイティブインターフェースと外部モデムまたは端末アダプターの制御
NAS は、電気通信会社のアナログまたはデジタル回線に直接インターフェースするか、外部モデムまたは端末アダプターを介して接続することができます。回線交換接続の制御は、モデム制御または DSS1 ISDN 呼制御プロトコルのいずれかで実現されます。
NAS は、モデムまたは端末アダプターと連携して、レート適応、アナログからデジタルへの変換、同期から非同期への変換、またはデータストリームの他の多くの変更を実行することができます。
-
ポイントツーポイントプロトコル (Point-to-Point Protocol, PPP) リンク制御プロトコル (Link Control Protocol, LCP) セッションの論理的な終端
-
PPP 認証プロトコル [3,9,10] への参加
-
PPP マルチリンクプロトコル (Multilink Protocol) のチャネル集約とバンドル管理
-
各種 PPP ネットワーク制御プロトコル (Network Control Protocol, NCP) の論理的な終端
-
NAS インターフェース間のマルチプロトコルルーティングおよびブリッジング
PPTP は、これらの機能を PAC と PNS の間で分割します。PAC は機能 1、2、および場合によっては機能 3 を担当します。PNS は機能 3 を担当する場合があり、機能 4、5、6 を担当します。PAC と PNS の間で PPP プロトコルデータユニット (Protocol Data Unit, PDU) を伝送するために使用されるプロトコル、および呼制御と管理は PPTP によって対処されます。
NAS 機能の分離により、以下の利点が提供されます。
柔軟な IP アドレス管理。ダイヤルインユーザーは、共通の PNS からサービスを受ける限り、異なる PAC にダイヤルインする際に単一の IP アドレスを維持できます。企業ネットワークが未登録アドレスを使用する場合、企業に関連付けられた PNS は、プライベートネットワークに意味のあるアドレスを割り当てます。
IP ネットワークの背後にあるダイヤルネットワークに対する非 IP プロトコルのサポート。これにより、例えば AppleTalk や IPX を IP のみのプロバイダー経由でトンネリングすることができます。PAC はこれらのプロトコルを処理する必要がありません。
「マルチリンクハントグループ分割」問題の解決。通常 ISDN B チャネルを集約するために使用されるマルチリンク PPP (Multilink PPP) は、マルチリンクバンドルを構成するすべてのチャネルが単一の NAS にグループ化される必要があります。マルチリンク PPP バンドルは単一の PNS で処理できるため、バンドルを構成するチャネルは複数の PAC に分散される可能性があります。
1.1. プロトコルの目標と前提 (Protocol Goals and Assumptions)
PPTP プロトコルは PAC と PNS によってのみ実装されます。他のシステムは PPTP を認識する必要がありません。ダイヤルネットワークは、PPTP を認識することなく PAC に接続できます。標準 PPP クライアントソフトウェアは、トンネル化された PPP リンク上で引き続き動作するべきです (SHOULD)。
PPTP は、IP ネットワーク経由で PPP セッションをトンネリングするためにも使用できます。この構成では、PPTP トンネルと PPP セッションは同じ 2 台のマシン間で実行され、発呼者が PNS として機能します。
PAC と PNS の間には多対多の関係があることが想定されています。1 つの PAC は多数の PNS にサービスを提供できます。例えば、インターネットサービスプロバイダーは、多数のプライベートネットワーククライアントに対して PPTP をサポートし、それらのために VPN を作成することを選択できます。各プライベートネットワークは、1 つ以上の PNS を運用できます。単一の PNS は、多数の地理的に分散したサイトからのトラフィックを集中させるために、多数の PAC と関連付けることができます。
PPTP は、ユーザー PPP パケットを伝送するために GRE の拡張バージョンを使用します。これらの拡張機能により、PAC と PNS 間でユーザーデータを伝送するために使用されるトンネルに低レベルの輻輳制御およびフロー制御を提供できます。このメカニズムにより、トンネルで利用可能な帯域幅を効率的に使用でき、不要な再送信やバッファオーバーランを回避できます。PPTP は、この低レベル制御に使用される特定のアルゴリズムを規定していませんが、これらのアルゴリズムが機能するために通信する必要があるパラメーターを定義しています。推奨されるアルゴリズムは、セクション 4 に含まれています。
1.2. 用語 (Terminology)
アナログチャネル (Analog Channel)
各方向で 3.1 kHz のオーディオを伝送することを目的とした回線交換通信パス。
デジタルチャネル (Digital Channel)
各方向でデジタル情報を伝送することを目的とした回線交換通信パス。
呼 (Call)
PSTN または ISDN 上の 2 つの端末エンドポイント間の接続または接続試行。例えば、2 つのモデム間の電話呼。
制御接続 (Control Connection)
各 PAC-PNS ペアに対して作成され、TCP 上で動作する接続。制御接続は、トンネルとトンネルに割り当てられたセッションの側面を管理します。
ダイヤルユーザー (Dial User)
オンデマンド PSTN または ISDN に接続されたエンドシステムまたはルーターで、呼の発信者または受信者のいずれかです。
ネットワークアクセスサーバー (Network Access Server, NAS)
ユーザーに一時的なオンデマンドネットワークアクセスを提供するデバイス。このアクセスは、PSTN または ISDN 回線を使用したポイントツーポイント接続です。
PPTP アクセスコンセントレーター (PPTP Access Concentrator, PAC)
1 つ以上の PSTN または ISDN 回線に接続され、PPP 操作と PPTP プロトコルの処理が可能なデバイス。PAC は、1 つ以上の PNS にトラフィックを渡すために TCP/IP のみを実装する必要があります。非 IP プロトコルをトンネリングすることもできます。
PPTP ネットワークサーバー (PPTP Network Server, PNS)
PNS は、汎用コンピューティング/サーバープラットフォーム上で動作することが想定されています。PNS は PPTP プロトコルのサーバー側を処理します。PPTP は TCP/IP に完全に依存し、インターフェースハードウェアから独立しているため、PNS は LAN および WAN デバイスを含む任意の IP インターフェースハードウェアの組み合わせを使用できます。
セッション (Session)
PPTP はコネクション型です。PNS と PAC は、PAC に接続されている各ユーザーの状態を維持します。ダイヤルユーザーと PNS 間でエンドツーエンド PPP 接続が試行されると、セッションが作成されます。セッションに関連するデータグラムは、PAC と PNS 間のトンネルを介して送信されます。
トンネル (Tunnel)
トンネルは PNS-PAC ペアによって定義されます。トンネルプロトコルは、GRE の修正バージョンによって定義されます。トンネルは、PAC と PNS 間で PPP データグラムを伝送します。複数のセッションが単一のトンネル上で多重化されます。TCP 上で動作する制御接続が、セッションとトンネル自体の確立、解放、および維持を制御します。
1.3. プロトコル概要 (Protocol Overview)
PPTP には 2 つの並列コンポーネントがあります: 1) 各 PAC-PNS ペア間で TCP 上で動作する制御接続、2) 同じ PAC-PNS ペア間で動作し、ペア間のユーザーセッション用の GRE カプセル化 PPP パケットを転送するために使用される IP トンネル。
1.3.1. 制御接続概要 (Control Connection Overview)
PAC と PNS 間で PPP トンネリングが発生する前に、それらの間に制御接続を確立する必要があります。制御接続は、PPTP 呼制御および管理情報が渡される標準の TCP セッションです。制御セッションは、PPTP トンネルを介してトンネリングされるセッションと論理的に関連付けられていますが、分離されています。各 PAC-PNS ペアには、トンネルと制御接続の両方が存在します。制御接続は、トンネルを介して伝送されるセッションの確立、管理、および解放を担当します。これは、関連する PAC での着信呼が PNS に通知される手段であり、また PAC が発信ダイヤル呼を行うように指示される手段でもあります。
制御接続は、PNS または PAC のいずれかによって確立できます。必要な TCP 接続の確立に続いて、PNS と PAC は Start-Control-Connection-Request および -Reply メッセージを使用して制御接続を確立します。これらのメッセージは、PAC と PNS の基本的な動作能力に関する情報を交換するためにも使用されます。制御接続が確立されると、PAC または PNS は、アウトバウンド呼を要求するか、インバウンド要求に応答することによってセッションを開始できます。制御接続は、Set-Link-Info メッセージを使用して、個々のユーザーセッションの動作特性の変化を伝達できます。個々のセッションは、PAC または PNS のいずれかによって、制御接続メッセージを介して解放されることもあります。
制御接続自体は、キープアライブエコーメッセージによって維持されます。これにより、PNS と PAC 間の接続障害をタイムリーに検出できます。その他の障害は、制御接続上の Wan-Error-Notify メッセージを介して報告できます。
制御接続は、将来的には、PNS が特定の PAC のステータスを要求できるようにするメッセージなど、管理関連のメッセージも伝送することが意図されています。これらのメッセージタイプはまだ定義されていません。
1.3.2. トンネルプロトコル概要 (Tunnel Protocol Overview)
PPTP は、通信する各 PNS-PAC ペアに対してトンネルを確立する必要があります。このトンネルは、特定の PNS-PAC ペアに関係するすべてのユーザーセッション PPP パケットを伝送するために使用されます。GRE ヘッダーに存在するキーは、特定の PPP パケットがどのセッションに属するかを示します。
このようにして、PPP パケットは、特定の PNS-PAC ペア間の単一のトンネル上で多重化および多重化解除されます。キーフィールドで使用する値は、制御接続上で行われる呼確立手順によって確立されます。
GRE ヘッダーには、トンネル上である程度の輻輳制御とエラー検出を実行するために使用される確認応答およびシーケンス情報も含まれています。制御接続は、トンネルを介した特定のセッションの PPP パケットのフローを調整するために使用されるレートとバッファリングパラメーターを決定するために再度使用されます。PPTP は、輻輳制御とフロー制御に使用する特定のアルゴリズムを規定していません。トンネル上でドロップされたデータまたは確認応答から回復するための適応タイムアウトの決定に関する提案アルゴリズムは、本文書のセクション 4.4 に含まれています。
1.4. メッセージフォーマットとプロトコル拡張性 (Message Format and Protocol Extensibility)
PPTP は、PNS と特定の PAC 間の制御接続上で TCP データとして送信される一連のメッセージを定義します。制御接続の TCP セッションは、ポート 1723 への TCP 接続を開始することによって確立されます。送信元ポートは、未使用の任意のポート番号に割り当てられます。
各 PPTP 制御接続メッセージは、8 オクテットの固定ヘッダー部分で始まります。この固定ヘッダーには、メッセージの全長、PPTP メッセージタイプインジケーター、および「マジッククッキー」が含まれています。
PPTP メッセージタイプフィールドは、2 つの制御接続メッセージタイプを示します:
- 1 - 制御メッセージ (Control Message)
- 2 - 管理メッセージ (Management Message)
管理メッセージは現在定義されていません。
マジッククッキーは常に定数 0x1A2B3C4D として送信されます。その基本的な目的は、受信者が TCP データストリームと適切に同期していることを確認できるようにすることです。送信者が不適切にフォーマットされたメッセージを発行した場合、TCP データストリームを再同期する手段として使用すべきではありません (SHOULD NOT)。同期の喪失は、制御接続の TCP セッションの即座のクローズを引き起こさなければなりません (MUST)。
明確化のため、次のセクションのすべての制御接続メッセージテンプレートには、完全な PPTP 制御接続メッセージヘッダーが含まれています。0x で始まる数値は16進数値です。
現在定義されている制御メッセージ（機能別にグループ化）は次のとおりです:
制御接続管理 (Control Connection Management)
- Start-Control-Connection-Request (1)
- Start-Control-Connection-Reply (2)
- Stop-Control-Connection-Request (3)
- Stop-Control-Connection-Reply (4)
- Echo-Request (5)
- Echo-Reply (6)
呼管理 (Call Management)
- Outgoing-Call-Request (7)
- Outgoing-Call-Reply (8)
- Incoming-Call-Request (9)
- Incoming-Call-Reply (10)
- Incoming-Call-Connected (11)
- Call-Clear-Request (12)
- Call-Disconnect-Notify (13)
エラー報告 (Error Reporting)
- WAN-Error-Notify (14)
PPP セッション制御 (PPP Session Control)
- Set-Link-Info (15)
Start-Control-Connection-Request および -Reply メッセージは、使用される制御接続プロトコルのバージョンを決定します。これらのメッセージで伝送されるバージョン番号フィールドは、上位オクテットのバージョン番号と下位オクテットのリビジョン番号で構成されます。バージョン処理については、セクション 2 で説明されています。バージョン番号フィールドの現在の値は、バージョン 1、リビジョン 0 の場合は 0x0100 です。
PPP ユーザーパケットのカプセル化に使用される GRE ライクヘッダーの使用は、セクション 4.1 で規定されています。
GRE にカプセル化されたユーザーデータパケットの MTU は、IP および GRE ヘッダーを含まない 1532 オクテットです。
2. 制御接続プロトコル仕様 (Control Connection Protocol Specification)
制御接続メッセージは、ユーザーセッションを確立およびクリアするために使用されます。最初の制御接続メッセージセットは、制御接続自体を維持するために使用されます。制御接続は、基盤となる TCP 接続を確立した後、PNS または PAC によって開始されます。どの TCP 接続を確立するかを決定するために必要な手順と構成情報は、このプロトコルではカバーされていません。
以下の制御接続メッセージはすべて、特定の PNS-PAC ペア間で確立された TCP 接続上のユーザーデータとして送信されます。すべてのワード（2 オクテット）およびロングワード（4 オクテット）値が適切な境界で始まることを保証するように注意が払われていることに注意してください。すべてのデータはネットワーク順序（上位オクテットが先）で送信されます。プロトコルの拡張性を許可するために、「予約済み」フィールドは 0 値として送信されなければなりません (MUST)。
2.1. Start-Control-Connection-Request (制御接続開始要求)
Start-Control-Connection-Request は、PNS と PAC 間の制御接続を確立するために使用される PPTP 制御メッセージです。各 PNS-PAC ペアには、専用の制御接続を確立する必要があります。他の PPTP メッセージを発行する前に、制御接続を確立しなければなりません (MUST)。制御接続の確立は、PNS または PAC のいずれかによって開始できます。PNS と PAC の Start-Control-Connection-Request 間で衝突が発生した場合の処理手順については、セクション 3.1.3 で説明されています。
メッセージフォーマット
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | PPTP Message Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Magic Cookie |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Control Message Type | Reserved0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol Version | Reserved1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Framing Capabilities |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bearer Capabilities |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maximum Channels | Firmware Revision |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Host Name (64 octets) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Vendor String (64 octets) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
フィールド説明
Length（長さ）
PPTP ヘッダー全体を含む、この PPTP メッセージの総オクテット長。
PPTP Message Type（PPTP メッセージタイプ）
制御メッセージの場合は 1。
Magic Cookie（マジッククッキー）
0x1A2B3C4D。この定数値は、受信したメッセージの健全性チェックとして使用されます（セクション 1.4 を参照）。
Control Message Type（制御メッセージタイプ）
Start-Control-Connection-Request の場合は 1。
Reserved0（予約済み 0）
このフィールドは 0 でなければなりません (MUST)。
Protocol Version（プロトコルバージョン）
送信者が使用したい PPTP プロトコルのバージョン。
Reserved1（予約済み 1）
このフィールドは 0 でなければなりません (MUST)。
Framing Capabilities（フレーミング機能）
このメッセージの送信者が提供できるフレーミングタイプを示すビットセット。現在定義されているビット設定は次のとおりです:
- 1 - 非同期フレーミングサポート (Asynchronous Framing supported)
- 2 - 同期フレーミングサポート (Synchronous Framing supported)
Bearer Capabilities（ベアラ機能）
このメッセージの送信者が提供できるベアラ機能を示すビットセット。現在定義されているビット設定は次のとおりです:
- 1 - アナログアクセスサポート (Analog access supported)
- 2 - デジタルアクセスサポート (Digital access supported)
Maximum Channels（最大チャネル数）
この PAC がサポートできる個別 PPP セッションの総数。PNS によって発行される Start-Control-Connection-Request では、この値は 0 に設定されるべきです (SHOULD)。PAC はこれを無視しなければなりません (MUST)。
Firmware Revision（ファームウェアリビジョン）
PAC によって発行された場合、このフィールドには発行元 PAC のファームウェアリビジョン番号が含まれます。PNS によって発行された場合、PNS PPTP ドライバーのバージョンが含まれます。
Host Name（ホスト名）
発行元 PAC または PNS の DNS 名を含む 64 オクテットのフィールド。64 オクテット未満の長さの場合、このフィールドの残りは値 0 のオクテットで埋められるべきです (SHOULD)。
Vendor Name（ベンダー名）
使用されている PAC のタイプ、または PNS によって発行された場合は使用されている PNS ソフトウェアのタイプを説明するベンダー固有の文字列を含む 64 オクテットのフィールド。64 オクテット未満の長さの場合、このフィールドの残りは値 0 のオクテットで埋められるべきです (SHOULD)。
2.2. Start-Control-Connection-Reply (制御接続開始応答)
Start-Control-Connection-Reply は、受信した Start-Control-Connection-Request メッセージに対する応答として送信される PPTP 制御メッセージです。このメッセージには、制御接続確立試行の結果を示す結果コードが含まれています。
メッセージフォーマット
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | PPTP Message Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Magic Cookie |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Control Message Type | Reserved0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol Version | Result Code | Error Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Framing Capability |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bearer Capability |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maximum Channels | Firmware Revision |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Host Name (64 octets) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Vendor String (64 octets) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
フィールド説明
Length（長さ）
PPTP ヘッダー全体を含む、この PPTP メッセージの総オクテット長。
PPTP Message Type（PPTP メッセージタイプ）
制御メッセージの場合は 1。
Magic Cookie（マジッククッキー）
0x1A2B3C4D。
Control Message Type（制御メッセージタイプ）
Start-Control-Connection-Reply の場合は 2。
Reserved0（予約済み 0）
このフィールドは 0 でなければなりません (MUST)。
Protocol Version（プロトコルバージョン）
送信者が使用したい PPTP プロトコルのバージョン。
Result Code（結果コード）
コマンドチャネル確立試行の結果を示します。現在有効な結果コード値は次のとおりです：
- 1 - チャネル確立成功
- 2 - 一般エラー -- エラーコードが問題を示します
- 3 - コマンドチャネルは既に存在します
- 4 - 要求者はコマンドチャネルを確立する権限がありません
- 5 - 要求者のプロトコルバージョンはサポートされていません
Error Code（エラーコード）
「一般エラー」が存在しない限り、このフィールドは 0 に設定されます。その場合、結果コードは 2 に設定され、このフィールドはセクション 2.2 で指定されている一般エラー状態に対応する値に設定されます。
Framing Capabilities（フレーミング機能）
このメッセージの送信者が提供できるフレーミングタイプを示すビットセット。現在定義されているビット設定は次のとおりです：
- 1 - 非同期フレーミングサポート
- 2 - 同期フレーミングサポート
Bearer Capabilities（ベアラ機能）
このメッセージの送信者が提供できるベアラ機能を示すビットセット。現在定義されているビット設定は次のとおりです：
- 1 - アナログアクセスサポート
- 2 - デジタルアクセスサポート
Maximum Channels（最大チャネル数）
この PAC がサポートできる個別 PPP セッションの総数。PNS によって発行される Start-Control-Connection-Reply では、この値は 0 に設定されるべきであり (SHOULD)、PAC はこれを無視しなければなりません (MUST)。PNS は、PAC が許可する残りの PPP セッション数を追跡しようとするためにこの値を使用してはなりません (MUST NOT)。
Firmware Revision（ファームウェアリビジョン）
このフィールドには、発行元 PAC のファームウェアリビジョン番号、または PNS によって発行された場合は PNS PPTP ドライバーのバージョンが含まれます。
Host Name（ホスト名）
発行元 PAC または PNS の DNS 名を含む 64 オクテットのフィールド。
Vendor String（ベンダー文字列）
ベンダー固有の文字列を含む 64 オクテットのフィールド。
2.3. Stop-Control-Connection-Request (制御接続停止要求)
Stop-Control-Connection-Request は、PAC-PNS 制御接続の一方のピアによって送信される PPTP 制御メッセージで、他方のピアに制御接続を閉じるべきことを通知します。制御接続を閉じることに加えて、すべてのアクティブなユーザー呼び出しが暗黙的にクリアされます。この要求を発行する理由は Reason フィールドに示されます。
メッセージフォーマット
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | PPTP Message Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Magic Cookie |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Control Message Type | Reserved0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reason | Reserved1 | Reserved2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
フィールド説明
Length（長さ）
PPTP ヘッダー全体を含む、この PPTP メッセージの総オクテット長。
PPTP Message Type（PPTP メッセージタイプ）
制御メッセージの場合は 1。
Magic Cookie（マジッククッキー）
0x1A2B3C4D。
Control Message Type（制御メッセージタイプ）
Stop-Control-Connection-Request の場合は 3。
Reserved0（予約済み 0）
このフィールドは 0 でなければなりません (MUST)。
Reason（理由）
制御接続が閉じられる理由を示します。現在有効な理由値は次のとおりです：
- 1 (None) - 制御接続をクリアする一般的な要求
- 2 (Stop-Protocol) - ピアのプロトコルバージョンをサポートできません
- 3 (Stop-Local-Shutdown) - 要求者がシャットダウンされています
Reserved1, Reserved2（予約済み 1, 2）
これらのフィールドは 0 でなければなりません (MUST)。
2.4. Stop-Control-Connection-Reply (制御接続停止応答)
Stop-Control-Connection-Reply は、PAC-PNS 制御接続の一方のピアが他方のピアから Stop-Control-Connection-Request を受信したときに送信される PPTP 制御メッセージです。
メッセージフォーマット
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | PPTP Message Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Magic Cookie |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Control Message Type | Reserved0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Result Code | Error Code | Reserved1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
フィールド説明
Length（長さ）
PPTP ヘッダー全体を含む、この PPTP メッセージの総オクテット長。
PPTP Message Type（PPTP メッセージタイプ）
制御メッセージの場合は 1。
Magic Cookie（マジッククッキー）
0x1A2B3C4D。
Control Message Type（制御メッセージタイプ）
Stop-Control-Connection-Reply の場合は 4。
Reserved0（予約済み 0）
このフィールドは 0 でなければなりません (MUST)。
Result Code（結果コード）
制御接続を閉じる試みの結果を示します。現在有効な結果コード値は次のとおりです：
- 1 (OK) - 制御接続が閉じられました
- 2 (General Error) - エラーコードに示された理由により制御接続が閉じられませんでした
Error Code（エラーコード）
「一般エラー」が存在しない限り、このフィールドは 0 に設定されます。その場合、結果コードは 2 に設定され、このフィールドはセクション 2.2 で指定されている一般エラー状態に対応する値に設定されます。
Reserved1（予約済み 1）
このフィールドは 0 でなければなりません (MUST)。
2.5. Echo-Request (エコー要求)
Echo-Request は、PAC-PNS 制御接続のいずれかのピアによって送信される PPTP 制御メッセージです。この制御メッセージは、制御接続の「キープアライブ」として使用されます。受信ピアは、受信した各 Echo-Request に対して Echo-Reply を発行します。セクション 3.1.4 で指定されているように、送信者が Echo-Request に対する Echo-Reply を受信しない場合、最終的に制御接続をクリアします。
メッセージフォーマット
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | PPTP Message Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Magic Cookie |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Control Message Type | Reserved0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
フィールド説明
Length（長さ）
PPTP ヘッダー全体を含む、この PPTP メッセージの総オクテット長。
PPTP Message Type（PPTP メッセージタイプ）
制御メッセージの場合は 1。
Magic Cookie（マジッククッキー）
0x1A2B3C4D。
Control Message Type（制御メッセージタイプ）
Echo-Request の場合は 5。
Reserved0（予約済み 0）
このフィールドは 0 でなければなりません (MUST)。
Identifier（識別子）
対応する Echo-Reply でエコーバックされる 32 ビット値。
2.6. Echo-Reply (エコー応答)
Echo-Reply は、PAC-PNS 制御接続のいずれかのピアが Echo-Request の受信に応答して送信する PPTP 制御メッセージです。
メッセージフォーマット
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | PPTP Message Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Magic Cookie |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Control Message Type | Reserved0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Result Code | Error Code | Reserved1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
フィールド説明
Length（長さ）
PPTP ヘッダー全体を含む、この PPTP メッセージの総オクテット長。
PPTP Message Type（PPTP メッセージタイプ）
制御メッセージの場合は 1。
Magic Cookie（マジッククッキー）
0x1A2B3C4D。
Control Message Type（制御メッセージタイプ）
Echo-Reply の場合は 6。
Reserved0（予約済み 0）
このフィールドは 0 でなければなりません (MUST)。
Identifier（識別子）
受信した Echo-Request の識別フィールドの内容がこのフィールドにコピーされます。
Result Code（結果コード）
Echo-Request の受信結果を示します。現在有効な結果コード値は次のとおりです：
- 1 (OK) - Echo-Reply は有効です
- 2 (General Error) - エラーコードに示された理由により Echo-Request は受け入れられませんでした
Error Code（エラーコード）
「一般エラー」状態が存在しない限り、このフィールドは 0 に設定されます。その場合、結果コードは 2 に設定され、このフィールドはセクション 2.2 で指定されている一般エラー状態に対応する値に設定されます。
Reserved1（予約済み 1）
このフィールドは 0 でなければなりません (MUST)。
2.7. Outgoing-Call-Request (発信呼び出し要求)
Outgoing-Call-Request は、PNS が PAC に送信する PPTP 制御メッセージで、PAC からの発信呼び出しを確立することを示します。この要求は、呼び出しを行うために必要な情報を PAC に提供します。また、セッションが確立された後、この会話のために PNS へのデータ送信を制御するために使用される情報を PAC に提供します。
メッセージフォーマット
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | PPTP Message Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Magic Cookie |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Control Message Type | Reserved0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Call ID | Call Serial Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Minimum BPS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maximum BPS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bearer Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Framing Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Packet Recv. Window Size | Packet Processing Delay |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Phone Number Length | Reserved1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Phone Number (64 octets) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Subaddress (64 octets) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
フィールド説明
Length（長さ）
PPTP ヘッダー全体を含む、この PPTP メッセージの総オクテット長。
PPTP Message Type（PPTP メッセージタイプ）
制御メッセージの場合は 1。
Magic Cookie（マジッククッキー）
0x1A2B3C4D。
Control Message Type（制御メッセージタイプ）
Outgoing-Call-Request の場合は 7。
Reserved0（予約済み 0）
このフィールドは 0 でなければなりません (MUST)。
Call ID（呼び出し ID）
PNS によってこのセッションに割り当てられた一意の識別子で、特定の PAC-PNS ペアに対して一意です。このセッションに関与する PNS と PAC の間でトンネルを介して送信されるデータの多重化と逆多重化に使用されます。
Call Serial Number（呼び出しシリアル番号）
ログに記録されたセッション情報でこの特定のセッションを識別する目的で、PNS によってこのセッションに割り当てられた識別子。呼び出し ID とは異なり、PNS と PAC の両方が、特定のセッションに同じ呼び出しシリアル番号を関連付けます。IP アドレスと呼び出しシリアル番号の組み合わせは一意であるべきです (SHOULD)。
Minimum BPS（最小 BPS）
このセッションの最低許容回線速度（ビット/秒）。
Maximum BPS（最大 BPS）
このセッションの最高許容回線速度（ビット/秒）。
Bearer Type（ベアラタイプ）
この発信呼び出しに必要なベアラ機能を示す値。現在定義されている値は次のとおりです：
- 1 - アナログチャネルで呼び出しを行う
- 2 - デジタルチャネルで呼び出しを行う
- 3 - 任意のタイプのチャネルで呼び出しを行うことができる
Framing Type（フレーミングタイプ）
この発信呼び出しに使用する PPP フレーミングのタイプを示す値。
- 1 - 非同期フレーミングを使用する呼び出し
- 2 - 同期フレーミングを使用する呼び出し
- 3 - いずれかのタイプのフレーミングを使用できる呼び出し
Packet Recv. Window Size（パケット受信ウィンドウサイズ）
PNS がこのセッションのためにバッファリングする受信データパケットの数。
Packet Processing Delay（パケット処理遅延）
PAC から PNS に送信されるデータに課される可能性のあるパケット処理遅延の測定値。この値は 1/10 秒単位で指定されます。PNS の場合、この数値は非常に小さくなるはずです。
Phone Number Length（電話番号の長さ）
電話番号フィールド内の有効な桁数の実際の数。
Reserved1（予約済み 1）
このフィールドは 0 でなければなりません (MUST)。
Phone Number（電話番号）
発信セッションを確立するためにダイヤルする番号。64 オクテット未満の場合、このフィールドの残りは値 0 のオクテットで埋められます。
Subaddress（サブアドレス）
ダイヤル情報の追加ダイヤル文字列を指定するために使用される 64 オクテットのフィールド。64 オクテット未満の場合、このフィールドの残りは値 0 のオクテットで埋められます。
2.8. Outgoing-Call-Reply (発信呼び出し応答)
Outgoing-Call-Reply は、受信した Outgoing-Call-Request メッセージに応答して PAC が PNS に送信する PPTP 制御メッセージです。この応答は、発信呼び出し試行の結果を示します。また、呼び出しに使用される特定のパラメータに関する情報を PNS に提供し、このセッションのために PAC へのデータ送信を制御することを可能にする情報を提供します。
メッセージフォーマット
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | PPTP Message Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Magic Cookie |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Control Message Type | Reserved0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Call ID | Peer's Call ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Result Code | Error Code | Cause Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Connect Speed |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Packet Recv. Window Size | Packet Processing Delay |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Physical Channel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
フィールド説明
Length（長さ）
PPTP ヘッダー全体を含む、この PPTP メッセージの総オクテット長。
PPTP Message Type（PPTP メッセージタイプ）
制御メッセージの場合は 1。
Magic Cookie（マジッククッキー）
0x1A2B3C4D。
Control Message Type（制御メッセージタイプ）
Outgoing-Call-Reply の場合は 8。
Reserved0（予約済み 0）
このフィールドは 0 でなければなりません (MUST)。
Call ID（呼び出し ID）
このセッションのピア（PAC）の一意の識別子。この値は、ピアが受信するすべての後続の呼び出し制御メッセージで多重化キーとして使用されます。
Peer's Call ID（ピアの呼び出し ID）
この値は、対応する Outgoing-Call-Request の呼び出し ID フィールドからコピーされ、この応答を送信された Outgoing-Call-Request に関連付けるために使用されます。
Result Code（結果コード）
発信呼び出し試行の結果を示します。現在有効な結果コード値には次のものがあります：
- 1 (Connected) - 呼び出しが接続されました
- 2 (General Error) - エラーコードに示された理由により発信呼び出しが完了しませんでした
- 3 (No Carrier) - キャリアが検出されなかったため発信呼び出しが失敗しました
- 4 (Busy) - ビジー信号のため発信呼び出しが失敗しました
- 5 (No Dial Tone) - ダイヤルトーンが検出されなかったため発信呼び出しが失敗しました
- 6 (Time-out) - 割り当てられた時間内に発信呼び出しが完了しませんでした
- 7 (Do Not Accept) - 発信呼び出しはローカル管理上受け入れられません
Error Code（エラーコード）
このフィールドは、一般エラー状態（結果コード 2 で示される）が存在しない限り、0 に設定されます。
Cause Code（原因コード）
このフィールドは、呼び出し切断に関する追加の障害情報を提供します。この値は通常、電話ネットワークの施設から提供されます。
Connect Speed（接続速度）
呼び出しが接続された実際の速度（ビット/秒）を示します。
Packet Recv. Window Size（パケット受信ウィンドウサイズ）
PAC がこのセッションのためにバッファリングする受信データパケットの数。
Packet Processing Delay（パケット処理遅延）
PNS から PAC に送信されるデータに課される可能性のあるパケット処理遅延の測定値。この値は 1/10 秒単位で指定されます。
Physical Channel ID（物理チャネル ID）
このフィールドは、この呼び出しに使用される物理チャネルの一意の識別子として PAC によって設定されます。その値は、ログ記録とデバッグ目的で使用されます。
2.9. Incoming-Call-Request (着信呼び出し要求)
Incoming-Call-Request は、PAC が PNS に送信する PPTP 制御メッセージで、PSTN から着信呼び出しが受信され、ローカルで受け入れられたことを示します。この要求は、着信呼び出しのタイプに関する情報を PNS に提供します。また、このセッションのために PAC から PNS へのデータ送信を制御するために使用される情報を提供します。
メッセージフォーマット
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | PPTP Message Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Magic Cookie |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Control Message Type | Reserved0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Call ID | Call Serial Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bearer Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Physical Channel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Dialed Number Length | Dialing Number Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Dialed Number (64 octets) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Dialing Number (64 octets) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Subaddress (64 octets) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
フィールド説明
Length（長さ）
PPTP ヘッダー全体を含む、この PPTP メッセージの総オクテット長。
PPTP Message Type（PPTP メッセージタイプ）
制御メッセージの場合は 1。
Magic Cookie（マジッククッキー）
0x1A2B3C4D。
Control Message Type（制御メッセージタイプ）
Incoming-Call-Request の場合は 9。
Reserved0（予約済み 0）
このフィールドは 0 でなければなりません (MUST)。
Call ID（呼び出し ID）
PAC によってこのセッションに割り当てられた一意の識別子。この値は、すべての後続の呼び出し制御メッセージで多重化キーとして使用されます。
Call Serial Number（呼び出しシリアル番号）
ログに記録されたセッション情報でこの特定のセッションを識別するために、PAC によってこのセッションに割り当てられた識別子。
Bearer Type（ベアラタイプ）
着信呼び出しのベアラ機能を示す値：
- 1 - アナログチャネルでの呼び出し
- 2 - デジタルチャネルでの呼び出し
Physical Channel ID（物理チャネル ID）
PAC がこの呼び出しに使用する物理チャネルの一意の識別子。
Dialed Number Length（ダイヤルされた番号の長さ）
ダイヤルされた番号フィールド内の有効な桁数の実際の数。
Dialing Number Length（ダイヤルする番号の長さ）
ダイヤルする番号フィールド内の有効な桁数の実際の数。
Dialed Number（ダイヤルされた番号）
呼び出された番号。64 オクテットのフィールドで、不足分は 0 で埋められます。
Dialing Number（ダイヤルする番号）
呼び出し元の番号。64 オクテットのフィールドで、不足分は 0 で埋められます。
Subaddress（サブアドレス）
追加のダイヤル情報。64 オクテットのフィールドで、不足分は 0 で埋められます。
2.10. Incoming-Call-Reply (着信呼び出し応答)
Incoming-Call-Reply は、受信した Incoming-Call-Request に応答して PNS が PAC に送信する PPTP 制御メッセージです。この応答は、PNS が着信呼び出しを受け入れるかどうかを示します。また、このセッションのために PNS から PAC へのデータ送信を制御するために使用される情報を提供します。
メッセージフォーマット
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | PPTP Message Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Magic Cookie |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Control Message Type | Reserved0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Call ID | Peer's Call ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Result Code | Error Code | Packet Recv. Window Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Packet Processing Delay | Reserved1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
フィールド説明
Control Message Type（制御メッセージタイプ）
Incoming-Call-Reply の場合は 10。
Call ID（呼び出し ID）
このセッションのピア（PNS）の一意の識別子。
Peer's Call ID（ピアの呼び出し ID）
対応する Incoming-Call-Request の呼び出し ID フィールドからコピーされた値。
Result Code（結果コード）
PNS が着信呼び出しを受け入れるかどうかを示します：
- 1 (Connect) - 着信呼び出しを受け入れる
- 2 (General Error) - エラーコードに示された理由により着信呼び出しが受け入れられませんでした
- 3 (Do Not Accept) - 着信呼び出しは管理上受け入れられません
Packet Recv. Window Size（パケット受信ウィンドウサイズ）
PNS がこのセッションのためにバッファリングする受信データパケットの数。
Packet Processing Delay（パケット処理遅延）
PAC から PNS に送信されるデータに課される可能性のあるパケット処理遅延の測定値。
2.11. Incoming-Call-Connected (着信呼び出し接続完了)
Incoming-Call-Connected は、PAC が PNS に送信する PPTP 制御メッセージで、着信呼び出しの最終確認として機能します。確立されたセッションのパラメータに関する情報を提供します。
メッセージフォーマット
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | PPTP Message Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Magic Cookie |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Control Message Type | Reserved0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer's Call ID | Reserved1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Connect Speed |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Packet Recv. Window Size | Packet Processing Delay |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Framing Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
フィールド説明
Control Message Type（制御メッセージタイプ）
Incoming-Call-Connected の場合は 11。
Connect Speed（接続速度）
呼び出しが接続された実際の速度（ビット/秒）。
Framing Type（フレーミングタイプ）
着信呼び出しで使用されるフレーミングタイプ：
- 1 - 非同期フレーミング
- 2 - 同期フレーミング
2.12. Call-Clear-Request (呼び出しクリア要求)
Call-Clear-Request は、PNS が PAC に送信する PPTP 制御メッセージで、特定の呼び出しを切断する必要があることを示します。
メッセージフォーマット
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | PPTP Message Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Magic Cookie |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Control Message Type | Reserved0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Call ID | Reserved1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
フィールド説明
Control Message Type（制御メッセージタイプ）
Call-Clear-Request の場合は 12。
2.13. Call-Disconnect-Notify (呼び出し切断通知)
Call-Disconnect-Notify は、PAC が PNS に送信する PPTP 制御メッセージで、呼び出しが切断されたことを示します。
メッセージフォーマット
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | PPTP Message Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Magic Cookie |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Control Message Type | Reserved0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Call ID | Result Code | Error Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cause Code | Reserved1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Call Statistics (128 octets) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
フィールド説明
Control Message Type（制御メッセージタイプ）
Call-Disconnect-Notify の場合は 13。
2.14. WAN-Error-Notify (WAN エラー通知)
WAN-Error-Notify は、PAC が PNS に送信する PPTP 制御メッセージで、WAN エラー状態が発生したことを示します。
メッセージフォーマット
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | PPTP Message Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Magic Cookie |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Control Message Type | Reserved0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer's Call ID | Reserved1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CRC Errors |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Framing Errors |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hardware Overruns |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Buffer Overruns |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time-out Errors |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Alignment Errors |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
フィールド説明
Control Message Type（制御メッセージタイプ）
WAN-Error-Notify の場合は 14。
2.15. Set-Link-Info (リンク情報設定)
Set-Link-Info は、PNS が PAC に送信する PPTP 制御メッセージで、PPP ネゴシエーションパラメータを設定します。
メッセージフォーマット
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | PPTP Message Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Magic Cookie |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Control Message Type | Reserved0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer's Call ID | Reserved1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Send ACCM |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receive ACCM |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
フィールド説明
Control Message Type（制御メッセージタイプ）
Set-Link-Info の場合は 15。
2.16. General Error Codes (一般エラーコード)
以下は、さまざまな PPTP 制御メッセージの Error Code フィールドで使用される一般エラーコード値です：
- 0 - None (エラーなし)
- 1 - Not-Connected (未接続) - PAC と PNS の間に制御接続がありません
- 2 - Bad-Format (フォーマット不良) - メッセージ長が間違っているか、メッセージフォーマットが正しくありません
- 3 - Bad-Value (値不良) - メッセージフィールドの値が範囲外または無効です
- 4 - No-Resource (リソース不足) - このコマンドを処理するためのリソースが不足しています
- 5 - Bad-Call ID (呼び出し ID 不良) - このピアは参照されている呼び出し ID を認識していません
- 6 - PAC-Error (PAC エラー) - PAC で発生した一般エラー
エラーコード使用説明
制御メッセージの Result Code フィールドが一般エラーを示すように設定されている場合（通常は値 2）、Error Code フィールドを使用して、そのエラーの性質に関するより詳細な情報を提供する必要があります。Result Code が一般エラーを示していない場合、Error Code フィールドは 0 に設定されなければなりません (MUST)。
これらのエラーコードは、PPTP セッションの確立と維持プロセス中の問題を識別して解決するのに役立つ、デバッグとログ記録目的のための有用な診断情報を提供することを目的としています。
セクション 2 完了 - このセクションでは、PPTP 制御接続プロトコルで使用されるすべてのメッセージタイプを詳細に定義しました。これには、制御接続管理メッセージ（2.1-2.6）、呼び出し制御メッセージ（2.7-2.15）、および一般エラーコード（2.16）が含まれます。
3. プロトコル動作 (Protocol Operation)
このセクションでは、PPTP プロトコルの動作の詳細について説明します。これには、制御接続状態、コール状態、およびさまざまな動作シナリオの処理フローが含まれます。
3.1. 制御接続状態 (Control Connection States)
制御接続は、PAC と PNS の間に確立される TCP 接続であり、PPTP 制御メッセージを交換するために使用されます。制御接続の確立は、PAC または PNS のいずれかによって開始できます。
基本的な状態遷移
制御接続は次の基本状態を経ます：
- Idle（アイドル） - 制御接続が存在しない
- Wait-Connect（接続待ち） - 接続要求を送信し、応答を待機中
- Established（確立済み） - 制御接続が正常に確立された
- Wait-Disconnect（切断待ち） - 切断要求を送信し、確認を待機中
3.1.1. 制御接続発信者 (Control Connection Originator)
制御接続の発信者（PAC または PNS）は次の操作を実行します：
状態：Idle（アイドル）
- 操作：ピアへの TCP 接続を確立する
- 送信：Start-Control-Connection-Request
- 遷移先：Wait-Reply 状態
状態：Wait-Reply（応答待ち）
- 受信：Start-Control-Connection-Reply (Result = 成功)
- 遷移先：Established 状態
- 受信：Start-Control-Connection-Reply (Result = エラー)
- TCP 接続を閉じる
- 遷移先：Idle 状態
- タイムアウト：
- TCP 接続を閉じる
- 遷移先：Idle 状態
状態：Established（確立済み）
- すべての PPTP 制御メッセージを送受信できます
- 送信：Echo-Request（定期的なキープアライブ）
- 受信：Echo-Reply（キープアライブへの応答）
- 送信：Stop-Control-Connection-Request（アクティブなクローズ）
- 遷移先：Wait-Stop-Reply 状態
状態：Wait-Stop-Reply（停止応答待ち）
- 受信：Stop-Control-Connection-Reply
- TCP 接続を閉じる
- 遷移先：Idle 状態
- タイムアウト：
- TCP 接続を閉じる
- 遷移先：Idle 状態
3.1.2. 制御接続受信者 (Control Connection Receiver)
制御接続の受信者（PAC または PNS）は次の操作を実行します：
状態：Idle（アイドル）
- リスン：TCP ポート 1723
- 受信：TCP 接続要求
- TCP 接続を受け入れる
- 遷移先：Wait-Request 状態
状態：Wait-Request（要求待ち）
- 受信：Start-Control-Connection-Request
- 検証：プロトコルバージョン、パラメータ
- 受け入れる場合：
- 送信：Start-Control-Connection-Reply (Result = 成功)
- 遷移先：Established 状態
- 拒否する場合：
- 送信：Start-Control-Connection-Reply (Result = エラー)
- TCP 接続を閉じる
- 遷移先：Idle 状態
状態：Established（確立済み）
- すべての PPTP 制御メッセージを送受信できます
- 受信：Echo-Request
- 送信：Echo-Reply
- 受信：Stop-Control-Connection-Request
- 送信：Stop-Control-Connection-Reply
- TCP 接続を閉じる
- 遷移先：Idle 状態
3.1.3. Start Control Connection 初期化要求の衝突 (Initiation Request Collision)
PAC と PNS が同時に制御接続を確立しようとすると、衝突が発生する可能性があります。処理は次のとおりです：
- 衝突の検出：一方が Wait-Reply 状態で Start-Control-Connection-Request を受信したとき
- 衝突の解決：
- IP アドレスを比較する（数値）
- IP アドレスが小さい方：開始した接続を閉じ、ピアの接続を受け入れる
- IP アドレスが大きい方：開始した接続を続行し、ピアの接続を拒否する
- 最終結果：1 つの制御接続のみが確立される
3.1.4. キープアライブとタイマー (Keep Alives and Timers)
制御接続のアクティブ状態を維持するために、次のメカニズムが実装されています：
Echo-Request/Reply メカニズム
- 送信頻度：60 秒ごとに Echo-Request を送信することが推奨されます
- タイムアウト処理：60 秒以内に Echo-Reply を受信しない場合、接続は失敗したと見なされます
- 再試行戦略：最大 3 回まで再試行でき、各試行の間隔は 60 秒です
- 接続失敗：連続して複数回タイムアウトした後、制御接続を閉じます
TCP キープアライブ
- TCP 層のキープアライブメカニズムを補完として使用できます
- PPTP 層の Echo メカニズムは必須 (MUST) です
タイマーパラメータ
- 制御接続確立タイムアウト：60 秒
- キープアライブ間隔：60 秒
- Echo-Reply タイムアウト：60 秒
- 制御接続クローズタイムアウト：60 秒
これらのタイマー値は推奨値であり、実装は必要に応じて調整できますが、次のことを確認する必要があります：
- キープアライブ間隔は接続失敗をタイムリーに検出できるよう十分に短い
- タイムアウト値はネットワーク遅延による誤判定を避けるため十分に長い
3.2. コール状態 (Call States)
3.2.1. タイミングの考慮事項 (Timing Considerations)
電話シグナリングのリアルタイム性により、PNS と PAC の両方は、複数のコールに関連するメッセージがシリアライズされてブロックされないように、マルチスレッドアーキテクチャで実装する必要があります。PAC と PNS 間の転送遅延は 1 秒を超えてはなりません (SHOULD NOT)。コールおよび接続状態図は、タイマーによって引き起こされる例外を明示的に指定していません。暗黙の前提は、TCP ベースの制御接続が Keep-Alive メッセージによって検証されているため、コール制御メッセージに対して厳格なタイマーを維持する必要性が少ないということです。
モデムトレーニングおよびネゴシエーションシーケンスを含む国際発信コールの確立には、1 分以上かかる場合があるため、短いタイマーの使用は推奨されません。
状態遷移が 1 分以内に発生しない場合（アイドルまたは確立状態の接続を除く）、ピア間のプロトコル処理の整合性が疑わしいため、制御接続全体 (ENTIRE CONTROL CONNECTION) を閉じて再起動する必要があります。制御接続が開始されるたびに、すべてのコール ID が論理的に解放されます。これは、課金コールが「失われて」永遠にクリアされないことを防ぐのにも役立ちます。
3.2.2. コール ID 値 (Call ID Values)
各ピアは、要求または受け入れる各ユーザーセッションにコール ID 値を割り当てます。このコール ID 値は、それが属する PNS と PAC 間のトンネル内で一意である必要があります (MUST)。他のピアへのトンネルは同じコール ID 番号を使用できるため、トンネル上のパケットの受信者は、ユーザーセッションを特定のトンネルとコール ID に関連付ける必要があります。各トンネルの潜在的なコール ID 値の数は、特定のトンネルで予想される最大コール数の少なくとも 2 倍であることが推奨されます。
セッションは、3 つ組 (PAC, PNS, Call ID) によって定義されます。
3.2.3. 着信コール (Incoming Calls)
関連する電話回線が鳴ると、PAC によって Incoming-Call-Request メッセージが生成されます。PAC はコール ID とシリアル番号を選択し、コールベアラータイプを示します。モデムは常にアナログコールタイプを示す必要があります (SHOULD)。ISDN コールは、無制限デジタルサービスまたはレート適応が使用される場合はデジタルを示し、デジタルモデムが関与する場合はアナログを示す必要があります (SHOULD)。発信番号、着信番号、およびサブアドレスが電話ネットワークから利用可能な場合は、メッセージに含めることができます。
PAC が Incoming-Call-Request を送信すると、PNS からの応答を待ちますが、電話ネットワークからのコールには応答しません。次の場合、PNS はコールを受け入れないことを選択できます：
- より多くのセッションを処理するための利用可能なリソースがない
- 着信、発信、またはサブアドレスフィールドが承認されたユーザーを示していない
- ベアラーサービスが承認されていないかサポートされていない
PNS がコールを受け入れることを選択した場合、ウィンドウサイズ（セクション 4.2 参照）も示す Incoming-Call-Reply で応答します。PAC が Outgoing-Call-Reply を受信すると、発信者が切断していないと仮定して、コールの接続を試みます。PAC から PNS への最終的なコール接続メッセージは、PAC と PNS の両方のコール状態が確立状態に入る必要があることを示します。
ダイヤルインクライアントが切断すると、コールは正常にクリアされ、PAC は Call-Disconnect-Notify メッセージを送信します。PNS がコールをクリアしたい場合は、Call-Clear-Request メッセージを送信し、Call-Disconnect-Notify を待ちます。
3.2.3.1. PAC 着信コール状態 (PAC Incoming Call States)
PAC の着信コールに関連する状態は次のとおりです：
idle（アイドル）
- PAC は、その電話インターフェースの 1 つで着信コールを検出します。通常、これはアナログ回線が鳴っているか、ISDN TE が着信 Q.931 SETUP メッセージを検出したことを意味します。PAC は Incoming-Call-Request メッセージを送信し、wait_reply 状態に移行します。
wait_reply（応答待ち）
- PAC は、コールを受け入れる意思がないことを示す Incoming-Call-Reply メッセージ（一般エラーまたは不受理）を受信し、アイドル状態に戻ります。応答メッセージがコールが受け入れられたことを示す場合、PAC は Incoming-Call-Connected メッセージを送信し、確立状態に入ります。
established（確立済み）
- データがトンネルを介して交換されます。コールは次の場合にクリアされる可能性があります：
- 電話接続上のイベント。PAC は Call-Disconnect-Notify メッセージを送信
- Call-Clear-Request の受信。PAC は Call-Disconnect-Notify メッセージを送信
- ローカルな理由。PAC は Call-Disconnect-Notify メッセージを送信
3.2.3.2. PNS 着信コール状態 (PNS Incoming Call States)
PNS の着信コールに関連する状態は次のとおりです：
idle（アイドル）
- Incoming-Call-Request メッセージを受信します。リクエストが受け入れられない場合、Incoming-Call-Reply が PAC に送信され、PNS はアイドル状態のままです。Incoming-Call-Request メッセージが受け入れられる場合、結果コードで受け入れを示す Incoming-Call-Reply が送信されます。セッションは wait_connect 状態に移行します。
wait_connect（接続待ち）
- PAC でセッションが接続されると、PAC は PNS に着信コール接続メッセージを送信し、PNS は確立状態に移行します。PAC は、着信発信者が接続できなかったことを示すために Call-Disconnect-Notify を送信する場合があります。これは、たとえば、電話ユーザーが誤って PAC への標準音声コールを行い、着信モデムでのハンドシェイクが失敗した場合に発生する可能性があります。
established（確立済み）
- セッションは、PAC からの Call-Disconnect-Notify メッセージの受信または Call-Clear-Request の送信によって終了されます。Call-Clear-Request が送信されると、セッションは wait_disconnect 状態に入ります。
wait_disconnect（切断待ち）
- Call-Disconnect-Notify を受信すると、セッションはアイドル状態に戻ります。
3.2.4. 発信コール (Outgoing Calls)
発信メッセージは PNS によって開始され、PAC に電話インターフェースでコールを発信するよう指示します。発信コールには 2 つのメッセージしかありません：Outgoing-Call-Request と Outgoing-Call-Reply。PNS は、着信先の電話番号とサブアドレス、および速度とウィンドウパラメータを指定して Outgoing-Call-Request を送信します。PAC は、次のことを判断すると、Outgoing-Call-Reply メッセージで Outgoing-Call-Request メッセージに応答する必要があります (MUST)：
- コールが正常に接続された
- 次のような理由でコール失敗が発生した：ダイヤルアウトに使用可能なインターフェースがない、着信先が話中または応答しない、またはダイヤル用に選択されたインターフェースでダイヤルトーンが検出されない
3.2.4.1. PAC 発信コール状態 (PAC Outgoing Call States)
PAC の発信コールに関連する状態は次のとおりです：
idle（アイドル）
- Outgoing-Call-Request を受信しました。これがエラーで受信された場合、エラー条件が設定された Outgoing-Call-Reply で応答します。それ以外の場合は、ダイヤルする物理チャネルを割り当てます。発信コールを発信し、接続を待ち、wait_cs_ans 状態に移行します。
wait_cs_ans（回線交換応答待ち）
- コールが不完全な場合、ゼロ以外のエラーコードを含む Outgoing-Call-Reply を送信します。発信コールのタイマーが期限切れになった場合、ゼロ以外のエラーコードを含む Outgoing-Call-Reply を送信します。回線交換接続が確立された場合、成功を示す Outgoing-Call-Reply を送信します。
established（確立済み）
- Call-Clear-Request を受信した場合、適切なメカニズムを介して電話コールを解放するべきであり (SHOULD)、PNS に Call-Disconnect-Notify メッセージを送信するべきです (SHOULD)。クライアントまたは電話インターフェースによってコールが切断された場合、PNS に Call-Disconnect-Notify メッセージを送信するべきです (SHOULD)。
3.2.4.2. PNS 発信コール状態 (PNS Outgoing Call States)
PNS の発信コールに関連する状態は次のとおりです：
idle（アイドル）
- 上位層アプリケーションからのオープン指示により、Outgoing-Call-Request が送信され、wait_reply 状態に移行します。
wait_reply（応答待ち）
- エラーを含む Outgoing-Call-Reply を受信した場合、アイドル状態に戻ります。成功した Outgoing-Call-Reply を受信した場合、確立状態に移行します。Outgoing-Call-Reply を待っている間に中止が発生した場合、Call-Clear-Request を送信し、wait_disconnect 状態に移行します。
established（確立済み）
- Call-Disconnect-Notify を受信した場合、アイドル状態に移行します。ローカル終了が発生した場合、Call-Clear-Request を送信し、wait_disconnect 状態に移行します。
wait_disconnect（切断待ち）
- Call-Disconnect-Notify を受信した場合、アイドル状態に移行します。
4. トンネルプロトコル動作 (Tunnel Protocol Operation)
PPTP プロトコルが運ぶユーザーデータは PPP データパケットです。PPP パケットは PAC と PNS の間で運ばれ、GRE パケットにカプセル化され、GRE パケットは IP 上で運ばれます。カプセル化された PPP パケットは、基本的にメディア固有のフレーミング要素を除いた PPP データパケットです。HDLC フラグ、ビット挿入、制御文字、または制御文字エスケープは含まれません。CRC はトンネルを通じて送信されません。PAC と PNS 間のトンネル上で送信される IP パケットは、次の一般的な構造を持ちます：
+--------------------------------+
| Media Header |
| (メディアヘッダー) |
+--------------------------------+
| IP Header |
| (IP ヘッダー) |
+--------------------------------+
| GRE Header |
| (GRE ヘッダー) |
+--------------------------------+
| PPP Packet |
| (PPP パケット) |
+--------------------------------+
4.1. 拡張 GRE ヘッダー (Enhanced GRE Header)
PPTP で使用される GRE ヘッダーは、現在の GRE プロトコル仕様 [1,2] で指定されているものから若干拡張されています。主な違いは、新しい確認応答番号 (Acknowledgment Number) フィールドの定義で、特定の GRE パケットまたはパケットのセットがトンネルの遠端に到着したかどうかを判断するために使用されます。この確認応答機能は、ユーザーデータパケットの再送信とは組み合わせて使用されません。代わりに、特定のユーザーセッションのユーザーデータパケットがトンネルを介して送信される速度を決定するために使用されます。拡張 GRE ヘッダーのフォーマットは次のとおりです：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|C|R|K|S|s|Recur|A| Flags | Ver | Protocol Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key (HW) Payload Length | Key (LW) Call ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number (Optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Acknowledgment Number (Optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
フィールド説明
C (Bit 0) - Checksum Present (チェックサム存在)
- 0 に設定します。
R (Bit 1) - Routing Present (ルーティング存在)
- 0 に設定します。
K (Bit 2) - Key Present (キー存在)
- 1 に設定します。
S (Bit 3) - Sequence Number Present (シーケンス番号存在)
- ペイロード（データ）パケットが存在する場合は 1 に設定します。ペイロードが存在しない場合（GRE パケットが確認応答のみ）は 0 に設定します。
s (Bit 4) - Strict Source Route Present (厳密なソースルート存在)
- 0 に設定します。
Recur (Bits 5-7) - Recursion Control (再帰制御)
- 0 に設定します。
A (Bit 8) - Acknowledgment Sequence Number Present (確認応答シーケンス番号存在)
- パケットが以前に送信されたデータを確認するための確認応答番号を含む場合は 1 に設定します。
Flags (Bits 9-12)
- 0 に設定する必要があります (MUST)。
Ver (Bits 13-15) - Version (バージョン)
- 1（拡張 GRE）を含む必要があります (MUST)。
Protocol Type (プロトコルタイプ)
- 16 進数 880B [8] に設定します。
Key (キー)
- キーフィールドの使用は実装次第です。PPTP は次のように使用します：
- Payload Length (ペイロード長)（キーの上位 2 オクテット）：ペイロードのサイズ、GRE ヘッダーは含まない
- Call ID (コール ID)（下位 2 オクテット）：このパケットが属するセッションのピアのコール ID を含みます
Sequence Number (シーケンス番号)
- ペイロードのシーケンス番号を含みます。S ビット（Bit 3）が 1 の場合に存在します。
Acknowledgment Number (確認応答番号)
- このユーザーセッションの送信ピアが受信した最も高い番号の GRE パケットのシーケンス番号を含みます。A ビット（Bit 8）が 1 の場合に存在します。
ペイロードセクションには、メディア固有のフレーミング要素を含まない PPP データパケットが含まれます。
関係するシーケンス番号はパケットごとのシーケンス番号です。各ユーザーセッションのシーケンス番号は、セッション開始時にゼロに設定されます。ペイロードを含む（S ビット（Bit 3）が 1 に設定されている）特定のユーザーセッションに対して送信される各パケットには、そのセッションの次の連続したシーケンス番号が割り当てられます。
このプロトコルは、確認応答をデータと一緒に運ぶことを許可し、プロトコル全体をより効率的にし、それによってパケットのバッファリングをより少なくすることができます。
4.2. スライディングウィンドウプロトコル (Sliding Window Protocol)
PPTP データパス上で使用されるスライディングウィンドウプロトコルは、データ交換の各側によるフロー制御に使用されます。拡張 GRE プロトコルは、パケット確認応答をデータパケット上にピギーバックすることを許可します。確認応答は、データパケットとは別に送信することもできます。繰り返しますが、スライディングウィンドウプロトコルの主な目的はフロー制御です。トンネルピアによる再送信は実行されません。
4.2.1. 初期ウィンドウサイズ (Initial Window Size)
各側が受信ウィンドウの最大サイズを示していますが、データの送信を開始するときは保守的なアプローチをとることが推奨されます。送信側の初期ウィンドウサイズは、受信側が要求した最大サイズの半分に設定され、最小サイズは 1 パケットです。確認応答を待っているパケットの数が現在のウィンドウサイズと等しくなると、送信側はパケットの送信を停止します。受信側が各ウィンドウを正常に消化すると、送信側のウィンドウサイズは最大値に達するまで 1 パケットずつ増加します。この方法は、履歴が確立されていないため、システムが既に混雑しているネットワークをフラッディングすることを防ぎます。
4.2.2. ウィンドウのクローズ (Closing the Window)
パケットでタイムアウトが発生すると、送信側は送信ウィンドウのサイズを失敗時の値の半分に調整します。端数は切り上げられ、最小ウィンドウサイズは 1 です。
4.2.3. ウィンドウのオープン (Opening the Window)
タイムアウトなしでウィンドウ分のパケットの送信が成功するたびに、送信ウィンドウサイズは、コールが接続されたときに相手側が送信した最大ウィンドウサイズに達するまで 1 パケットずつ増加します。前述のとおり、タイムアウト時に再送信は行われません。タイムアウト後、送信はウィンドウサイズがタイムアウトが発生したときの送信ウィンドウサイズの半分から始まり、送信ウィンドウがタイムアウトなしですべて確認されるパケットで満たされるたびに 1 ずつ上方に調整して再開されます。
4.2.4. ウィンドウオーバーフロー (Window Overflow)
受信側のウィンドウが着信パケットが多すぎてオーバーフローすると、余分なパケットは破棄されます。送信側と受信側がスライディングウィンドウ手順を適切に遵守している場合、この状況は発生しないはずです。送信側では、パケットが送信用にバッファリングされ、送信バッファがいっぱいになるとパケットソースからパケットを受け入れなくなることが想定されています。
4.2.5. マルチパケット確認応答 (Multi-packet Acknowledgment)
PPTP スライディングウィンドウプロトコルの 1 つの機能は、単一の確認応答で複数のパケットの確認応答を許可することです。確認応答番号以下のシーケンス番号を持つすべての未処理パケットは確認されたと見なされます。タイムアウト計算は、確認されている最高のシーケンス番号に対応するパケットが送信された時刻を使用して実行されます。
適応的タイムアウト計算は、確認応答を受信したときにのみ実行されます。マルチパケット確認応答が使用される場合、適応的タイムアウトアルゴリズムのオーバーヘッドが削減されます。PAC はマルチパケット確認応答を送信する必要はありません (not required)。代わりに、各パケットが PPP クライアントに配信されるときに個別に確認できます。
4.3. シーケンス外パケット (Out-of-sequence Packets)
時々、パケットは複雑なインターネットワークを通過する際にシーケンスを失います。たとえば、PNS がパケット 0 から 5 を PAC に送信するとします。インターネットワークでの再ルーティングのため、パケット 4 がパケット 3 よりも先に PAC に到着します。PAC はパケット 4 を確認し、パケット 3 が失われたと想定する可能性があります。この確認応答は、パケット 4 を超えるウィンドウクレジットを付与します。
PAC が実際にパケット 3 を受信した場合、対応する PPP クライアントに送信しようとしてはなりません (MUST NOT)。そうすると問題が発生する可能性があります。正しい PPP プロトコル動作は、パケットを順番に受信することを前提としているためです。PPP はパケットの損失を適切に処理しますが、再順序付けは処理しないため、PNS と PAC 間のシーケンス外パケットは静かに破棄される必要があります (MUST)。または、受信側が再順序付けすることもできます。パケット 5 が到着すると、PAC がこれまでに確認した最後の最高パケットである 4 よりも高いシーケンス番号を持っているため、PAC はそれを確認します。PAC と PNS は GRE パケットを再送信しないため、重複するシーケンス番号を持つパケットは決して発生しないはずです。堅牢な実装は、受信した場合、重複する GRE パケットを静かに破棄します。
4.4. 確認応答タイムアウト (Acknowledgment Time-Outs)
PPTP は、スライディングウィンドウとタイムアウトを使用して、インターネットワーク全体でユーザーセッションのフロー制御を提供し、受信バッファオーバーフローを引き起こすことなく PAC-PNS データチャネルをいっぱいに保つための効率的なデータバッファリングを実行します。PPTP は、ドロップされたデータまたは確認応答パケットから回復するためにタイムアウトを使用することを要求します。タイムアウトの正確な実装はベンダー固有です。輻輳制御のためのバックオフを伴う適応的タイムアウトを実装することが提案されています。ここで提案されるタイムアウトメカニズムには、次のプロパティがあります：
- 各セッションの独立したタイムアウト：デバイス（PAC または PNS）は、すべてのアクティブなセッションのタイムアウトを維持および計算する必要があります。
- 管理者が調整可能な最大タイムアウト (MaxTimeOut)：各デバイスに固有。
- 適応的タイムアウトメカニズム：変化するスループットを補償します。パケット処理のオーバーヘッドを削減するために、ベンダーは受信したすべての確認応答に対して適応的タイムアウトを再計算しないことを選択できます。このオーバーヘッド削減の結果、タイムアウトは急速なネットワーク変化に迅速に応答しなくなります。
- タイムアウト時のタイマーバックオフ：輻輳を削減します。バックオフされたタイマー値は、設定可能な最大タイムアウト値によって制限されます。タイマーバックオフは、確認応答タイムアウトが発生するたびに実行されます。
一般に、このメカニズムは、タイムアウト時に迅速にバックオフし、タイムアウトなしでパケットが配信されるときにタイムアウト値をゆっくりと減少させる望ましい動作を持っています。
定義
Packet Processing Delay (PPD) - パケット処理遅延
- 各側が受信パケットスライディングウィンドウにバッファリングされた最大データ量を処理するのに必要な時間。PPD は、コールが確立されたときに PAC と PNS の間で交換される値です。PNS の場合、この数値は小さいはずです。モデム接続を行う PAC の場合、この数値は大きい可能性があります。
Sample (サンプル)
- パケットの確認応答を受信するために実際に発生した時間量。サンプルは測定されるものであり、計算されるものではありません。
Round-Trip Time (RTT) - ラウンドトリップタイム
- 特定の送信されたパケットの確認応答を受信するための推定ラウンドトリップタイム。ネットワークリンクがローカルネットワークの場合、この遅延は最小（ゼロでない場合）になります。ネットワークリンクがインターネットの場合、この遅延は大きく、大きく変動する可能性があります。RTT は適応的です：パケットが送信されてからその確認応答を受信するまでの時間に寄与する PPD および変動するネットワーク遅延を含むように調整されます。
Adaptive Time-Out (ATO) - 適応的タイムアウト
- 確認応答が失われたと見なされる前に経過しなければならない時間。タイムアウト後、スライディングウィンドウは部分的に閉じられ、ATO がバックオフされます。
パケット処理遅延 (PPD) パラメータは、コール制御フェーズ中に交換される 16 ビットワードで、10 分の 1 秒を表します（64 は 6.4 秒を意味します）。プロトコルは、パラメータが交換されることのみを指定し、それがどのように計算されるかを指定しません。PPD 値の計算方法は実装依存であり、可変である必要はありません（静的タイムアウトが許可されます）。実装で一定のままであっても、PPD はコール接続シーケンスで交換される必要があります (MUST)。PPD を計算する 1 つの可能な方法は：
PPD' = ((PPP_MAX_DATA_MTU - Header) * WindowSize * 8) / ConnectRate
PPD = PPD' + PACFudge
ここで：
- Header は IP および GRE ヘッダーの合計サイズで、36 です
- MTU は PAC と PNS 間のインターネットワークリンクの全体的な MTU です
- WindowSize はスライディングウィンドウ内のパケット数を表し、実装依存です
- 定数 8 はオクテットをビットに変換します（ConnectRate がビット毎秒である場合を想定）
- PACFudge は必須ではありませんが、PAC の全体的な処理オーバーヘッドを考慮に入れるために使用できます
PPD の値は、初期 RTT[n-1] 値を使用して適応的アルゴリズムをシードするために使用されます。
4.4.1. 適応的確認応答タイムアウトの計算 (Calculating Adaptive Acknowledgment Time-Out)
確認応答を返すのに許可する時間をまだ決定する必要があります。タイムアウトが高すぎる設定の場合、ドロップされたパケットに対して不必要に長い時間待つ可能性があります。タイムアウトが短すぎる場合、確認応答が到着する直前にタイムアウトする可能性があります。確認応答タイムアウトも合理的であり、変化するネットワーク状態に応答する必要があります。
提案される適応的アルゴリズムは、TCP 1989 実装に基づいており、[11] で説明されています。'n' は現在のパケットを意味し、'n-1' は前のパケットを意味します：
Err[n] = Sample[n] - RTT[n-1]
RTT[n] = RTT[n-1] + (g * Err[n])
Dev[n] = Dev[n-1] + h * (|Err[n]| - Dev[n-1])
ATO[n] = RTT[n] + (f * Dev[n])
ここで：
- g はゲイン係数（推奨値は 0.125）
- h は偏差ゲイン係数（推奨値は 0.25）
- f は偏差乗数係数（推奨値は 4）
4.4.2. 輻輳制御：タイムアウトの調整 (Congestion Control: Adjusting for Time-Out)
このセクションでは、タイムアウトが発生した場合に ATO の計算がどのように変更されるかについて説明します。タイムアウトが発生すると、タイムアウト値は急速に上方に調整される必要があります。タイムアウトが発生したときに GRE パケットは再送信されませんが、タイムアウトは最大制限に向けて調整される必要があります。変化するインターネットワークの時間遅延を補償するために、タイムアウトが期限切れになったときにタイムアウトを増やす戦略を採用する必要があります（タイムアウトを増やすことに加えて、次のセクションで説明するようにウィンドウのサイズも縮小していることに注意してください）。
タイムアウトが発生した間隔の場合：
ATO[n] = MIN(2 * ATO[n-1], MaxTimeOut)
ここで、MaxTimeOut は管理者が設定した最大タイムアウト値です。
5. セキュリティに関する考慮事項 (Security Considerations)
トンネル化された PPP 接続を介して渡されるユーザーデータのセキュリティは、PPP ピアの認証と同様に、PPP によって対処されます。
PPTP 制御チャネルメッセージは認証されておらず、完全性も保護されていないため、攻撃者が基礎となる TCP 接続をハイジャックする可能性があります。また、偽の制御チャネルメッセージを製造し、検出されることなく送信中の真正なメッセージを変更することも可能です。
トンネル自体を形成する GRE パケットは暗号的に保護されていません。PPP ネゴシエーションはトンネルを介して実行されるため、攻撃者がこれらのネゴシエーションを盗聴および変更できる可能性があります。
PPP ペイロードデータが暗号的に保護されていない限り、キャプチャされて読み取られたり変更されたりする可能性があります。
6. 著者情報 (Authors' Addresses)
Kory Hamzeh
Ascend Communications
1275 Harbor Bay Parkway
Alameda, CA 94502
Email: [email protected]
Gurdeep Singh Pall
Microsoft Corporation
Redmond, WA
Email: [email protected]
William Verthein
U.S. Robotics/3Com
Jeff Taarud
Copper Mountain Networks
W. Andrew Little
ECI Telematics
Glen Zorn
Microsoft Corporation
Redmond, WA
Email: [email protected]
7. 参考文献 (References)
[1] Hanks, S., Li, T., Farinacci, D. and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 1701, October 1994.
[2] Hanks, S., Li, T., Farinacci, D. and P. Traina, "Generic Routing Encapsulation (GRE) over IPv4 Networks", RFC 1702, October 1994.
[3] Lloyd, B. and W. Simpson, "PPP Authentication Protocols", RFC 1334, October 1992.
[4] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[5] Postel, J., "User Data Protocol", STD 6, RFC 768, August 1980.
[6] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700, October 1994. See also: http://www.iana.org/numbers.html
[7] Simpson, W., editor, "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.
[8] Ethertype for PPP, Reserved with Xerox Corporation.
[9] Simpson, W., "PPP Challenge Handshake Authentication Protocol (CHAP)", RFC 1994, August 1996.
[10] Blunk, L. and J Vollbrecht, "PPP Extensible Authentication Protocol (EAP)", RFC 2284, March 1998.
[11] Stevens, R., "TCP/IP Illustrated, Volume 1", p. 300, Addison-Wesley, 1994.
[12] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
8. 完全な著作権表示 (Full Copyright Statement)
Copyright (C) The Internet Society (1999). All Rights Reserved.
この文書およびその翻訳は他者にコピーして提供することができ、この文書についてコメントまたは説明する派生著作物、またはその実装を支援する派生著作物は、上記の著作権表示とこの段落がすべてのそのようなコピーおよび派生著作物に含まれている場合、全体または一部を制限なく準備、コピー、公開、配布することができます。ただし、この文書自体は、著作権表示を削除したり、Internet Society または他のインターネット組織への参照を削除したりするなど、いかなる方法でも変更することはできません。ただし、インターネット標準を開発する目的で必要な場合を除きます。この場合、インターネット標準プロセスで定義された著作権手順に従う必要があります。または、英語以外の言語に翻訳するために必要な場合を除きます。
上記で付与された限定的な許可は永久的なものであり、Internet Society またはその後継者または譲受人によって取り消されることはありません。
この文書およびここに含まれる情報は「現状のまま」提供され、Internet Society および Internet Engineering Task Force は、ここに含まれる情報の使用が権利を侵害しないこと、または商品性もしくは特定目的への適合性の黙示的な保証を含むがこれに限定されない、明示的または黙示的なすべての保証を否認します。