ポイントツーポイントトンネリングプロトコル（PPTP）
英文を機械翻訳で日本語訳としています。日本語訳が正しくないことが考えられますので原文をメインとし、参考程度にご利用ください。
日本語訳
Network Working Group K. Hamzeh
Request for Comments: 2637 Ascend Communications
Category: Informational G. Pall
Microsoft Corporation
W. Verthein
3Com
J. Taarud
Copper Mountain Networks
W. Little
ECI Telematics
G. Zorn
Microsoft Corporation
July 1999
Point-to-Point Tunneling Protocol (PPTP)
ポイントツーポイントトンネリングプロトコル（PPTP）
Status of this Memo
このメモのステータス
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティに情報を提供します。 いかなる種類のインターネット標準も規定していません。 このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright（C）The Internet Society（1999）。 全著作権所有。
IESG Note
IESG Note
The PPTP protocol was developed by a vendor consortium. The documentation of PPTP is provided as information to the Internet community. The PPP WG is currently defining a Standards Track protocol (L2TP) for tunneling PPP across packet-switched networks.
PPTPプロトコルは、ベンダコンソーシアムによって開発されました。 PPTPのドキュメントは、インターネットコミュニティへの情報として提供されます。 PPP WGは現在、パケット交換ネットワークを介してPPPをトンネリングするためのStandards Trackプロトコル（L2TP）を定義しています。
Abstract
概要
This document specifies a protocol which allows the Point to Point Protocol (PPP) to be tunneled through an IP network. PPTP does not specify any changes to the PPP protocol but rather describes a new vehicle for carrying PPP. A client-server architecture is defined in order to decouple functions which exist in current Network Access Servers (NAS) and support Virtual Private Networks (VPNs). The PPTP Network Server (PNS) is envisioned to run on a general purpose operating system while the client, referred to as a PPTP Access Concentrator (PAC) operates on a dial access platform. PPTP specifies a call-control and management protocol which allows the server to control access for dial-in circuit switched calls originating from a PSTN or ISDN or to initiate outbound circuit- Hamzeh, et al. Informational [Page 1] RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999 switched connections. PPTP uses an enhanced GRE (Generic Routing Encapsulation) mechanism to provide a flow- and congestion-controlled encapsulated datagram service for carrying PPP packets.
このドキュメントでは、ポイントツーポイントプロトコル（PPP）をIPネットワーク経由でトンネリングできるプロトコルを指定しています。 PPTPはPPPプロトコルへの変更を指定していませんが、PPPを運ぶための新しい手段を説明しています。 現在のネットワークアクセスサーバー（NAS）に存在し、仮想プライベートネットワーク（VPN）をサポートする機能を分離するために、クライアントサーバーアーキテクチャが定義されています。 PPTPネットワークサーバー（PNS）は、PPTPアクセスコンセントレータ（PAC）と呼ばれるクライアントがダイヤルアクセスプラットフォーム上で動作している間、汎用オペレーティングシステム上で実行することが想定されています。 PPTPは、サーバーがPSTNまたはISDNから発信されるダイヤルイン回線交換呼び出しのアクセスを制御したり、発信回線交換接続を開始したりできるようにする、呼び出し制御および管理プロトコルを指定します。 PPTPは、強化されたGRE（Generic Routing Encapsulation）メカニズムを使用して、PPPパケットを運ぶためのフロー制御および輻輳制御のカプセル化されたデータグラムサービスを提供します。
Specification of Requirements
要件の仕様
In this document, the key words "MAY", "MUST, "MUST NOT", "optional", "recommended", "SHOULD", and "SHOULD NOT" are to be interpreted as described in [12].
このドキュメントでは、キーワード「MAY」、「MUST、「MUST NOT」、「optional」、「recommended」、「SHOULD」、および「SHOULD NOT」は、[12]で説明されているように解釈されます。
The words "silently discard", when used in reference to the behavior of an implementation upon receipt of an incoming packet, are to be interpreted as follows: the implementation discards the datagram without further processing, and without indicating an error to the sender. The implementation SHOULD provide the capability of logging the error, including the contents of the discarded datagram, and SHOULD record the event in a statistics counter.
着信パケットの受信時の実装の動作に関連して使用される場合、「サイレントに破棄する」という言葉は次のように解釈されます。実装はデータグラムを破棄します。これ以上の処理は行われず、送信者にエラーを示すこともありません。 実装は、破棄されたデータグラムの内容を含むエラーをログに記録する機能を提供する必要があり（SHOULD）、イベントを統計カウンターに記録する必要があります（SHOULD）。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Protocol Goals and Assumptions . . . . . . . . . . . . . . 4 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 1.3. Protocol Overview . . . . . . . . . . . . . . . . . . . . 6 1.3.1. Control Connection Overview . . . . . . . . . . . . . . 7 1.3.2. Tunnel Protocol Overview . . . . . . . . . . . . . . . . 7 1.4. Message Format and Protocol Extensibility . . . . . . . . 8 2. Control Connection Protocol Specification . . . . . . . . . 10 2.1. Start-Control-Connection-Request . . . . . . . . . . . . . 10 2.2. Start-Control-Connection-Reply . . . . . . . . . . . . . . 12 2.3. Stop-Control-Connection-Request . . . . . . . . . . . . . 15 2.4. Stop-Control-Connection-Reply . . . . . . . . . . . . . . 16 2.5. Echo-Request . . . . . . . . . . . . . . . . . . . . . . . 17 2.6. Echo-Reply . . . . . . . . . . . . . . . . . . . . . . . . 18 2.7. Outgoing-Call-Request . . . . . . . . . . . . . . . . . . 19 2.8. Outgoing-Call-Reply . . . . . . . . . . . . . . . . . . . 22 2.9. Incoming-Call-Request . . . . . . . . . . . . . . . . . . 25 2.10. Incoming-Call-Reply . . . . . . . . . . . . . . . . . . . 28 2.11. Incoming-Call-Connected . . . . . . . . . . . . . . . . . 29 2.12. Call-Clear-Request . . . . . . . . . . . . . . . . . . . 31 2.13. Call-Disconnect-Notify . . . . . . . . . . . . . . . . . 32 2.14. WAN-Error-Notify . . . . . . . . . . . . . . . . . . . . 33 2.15. Set-Link-Info . . . . . . . . . . . . . . . . . . . . . . 35 2.16. General Error Codes . . . . . . . . . . . . . . . . . . . 36 3. Control Connection Protocol Operation . . . . . . . . . . . 36 3.1. Control Connection States . . . . . . . . . . . . . . . . 37 3.1.1. Control Connection Originator (may be PAC or PNS) . . . 37 3.1.2. Control connection Receiver (may be PAC or PNS) . . . . 39 Hamzeh, et al. Informational [Page 2] RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999 3.1.3. Start Control Connection Initiation Request Collision . 40 3.1.4. Keep Alives and Timers . . . . . . . . . . . . . . . . . 40 3.2. Call States . . . . . . . . . . . . . . . . . . . . . . . 41 3.2.1. Timing considerations . . . . . . . . . . . . . . . . . 41 3.2.2. Call ID Values . . . . . . . . . . . . . . . . . . . . . 41 3.2.3. Incoming Calls . . . . . . . . . . . . . . . . . . . . . 41 3.2.3.1. PAC Incoming Call States . . . . . . . . . . . . . . . 42 3.2.3.2. PNS Incoming Call States . . . . . . . . . . . . . . . 43 3.2.4. Outgoing Calls . . . . . . . . . . . . . . . . . . . . . 44 3.2.4.1. PAC Outgoing Call States . . . . . . . . . . . . . . . 45 3.2.4.2. PNS Outgoing Call States . . . . . . . . . . . . . . . 46 4. Tunnel Protocol Operation . . . . . . . . . . . . . . . . . 47 4.1. Enhanced GRE header . . . . . . . . . . . . . . . . . . . 47 4.2. Sliding Window Protocol . . . . . . . . . . . . . . . . . 49 4.2.1. Initial Window Size . . . . . . . . . . . . . . . . . . 49 4.2.2. Closing the Window . . . . . . . . . . . . . . . . . . . 49 4.2.3. Opening the Window . . . . . . . . . . . . . . . . . . . 50 4.2.4. Window Overflow . . . . . . . . . . . . . . . . . . . . 50 4.2.5. Multi-packet Acknowledgment . . . . . . . . . . . . . . 50 4.3. Out-of-sequence Packets . . . . . . . . . . . . . . . . . 50 4.4. Acknowledgment Time-Outs . . . . . . . . . . . . . . . . . 51 4.4.1. Calculating Adaptive Acknowledgment Time-Out . . . . . . 53 4.4.2. Congestion Control: Adjusting for Time-Out . . . . . . . 54 5. Security Considerations . . . . . . . . . . . . . . . . . . 54 6. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 55 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 56 8. Full Copyright Statement . . . . . . . . . . . . . . . . . . 57
1.はじめに. . . . . . . . . . . . . . . . . . . . . . . . 3 1.1.プロトコルの目標と仮定. . . . . . . . . . . . . . 4 1.2.用語. . . . . . . . . . . . . . . . . . . . . . . 5 1.3.プロトコル概要. . . . . . . . . . . . . . . . . . . . 6 1.3.1.コントロール接続の概要. . . . . . . . . . . . . . 7 1.3.2.トンネルプロトコル概要. . . . . . . . . . . . . . . . 7 1.4.メッセージフォーマットとプロトコル拡張. . . . . . . . 8 2.コントロール接続プロトコル仕様. . . . . . . . . 10 2.1. Start-Control-Connection-Request. . . . . . . . . . . . . 10 2.2. Start-Control-Connection-Reply. . . . . . . . . . . . . . 12 2.3. Stop-Control-Connection-Request. . . . . . . . . . . . . 15 2.4. Stop-Control-Connection-Reply. . . . . . . . . . . . . . 16 2.5.エコー要求. . . . . . . . . . . . . . . . . . . . . . . 17 2.6.エコー応答. . . . . . . . . . . . . . . . . . . . . . . . 18 2.7. Outgoing-Call-Request. . . . . . . . . . . . . . . . . . 19 2.8. Outgoing-Call-Reply. . . . . . . . . . . . . . . . . . . 22 2.9. Incoming-Call-Request. . . . . . . . . . . . . . . . . . 25 2.10. Incoming-Call-Reply. . . . . . . . . . . . . . . . . . . 28 2.11.着信呼接続. . . . . . . . . . . . . . . . . 29 2.12. Call-Clear-Request. . . . . . . . . . . . . . . . . . . 31 2.13. Call-Disconnect-Notify. . . . . . . . . . . . . . . . . 32 2.14. WAN-Error-Notify. . . . . . . . . . . . . . . . . . . . 33 2.15. Set-Link-Info. . . . . . . . . . . . . . . . . . . . . . 35 2.16.一般的なエラーコード. . . . . . . . . . . . . . . . . . . 36 3.接続プロトコル操作の制御. . . . . . . . . . . 36 3.1.接続状態の制御. . . . . . . . . . . . . . . 37 3.1.1. Control Connection Originator（PACまたはPNSの場合があります）. . . 37 3.1.2.コントロール接続レシーバー（PACまたはPNSの場合があります）. . . . 39 3.1.3.制御接続開始要求の衝突を開始します. 40 3.1.4.キープアライブとタイマー. . . . . . . . . . . . . . . . . 40 3.2.通話状態. . . . . . . . . . . . . . . . . . . . . . . 41 3.2.1.タイミングの検討. . . . . . . . . . . . . . . . . 41 3.2.2.コールID値. . . . . . . . . . . . . . . . . . . . . 41 3.2.3.着信. . . . . . . . . . . . . . . . . . . . . 41 3.2.3.1. PAC着信状態. . . . . . . . . . . . . . . 42 3.2.3.2. PNS着信状態. . . . . . . . . . . . . . . 43 3.2.4.発信. . . . . . . . . . . . . . . . . . . . . 44 3.2.4.1. PAC発信通話状態. . . . . . . . . . . . . . . 45 3.2.4.2. PNS発信状態. . . . . . . . . . . . . . . 46 4.トンネルプロトコル操作. . . . . . . . . . . . . . . . . 47 4.1.拡張GREヘッダー. . . . . . . . . . . . . . . . . . . 47 4.2.スライディングウィンドウプロトコル. . . . . . . . . . . . . . . . . 49 4.2.1.初期ウィンドウサイズ. . . . . . . . . . . . . . . . . . 49 4.2.2.ウィンドウを閉じる. . . . . . . . . . . . . . . . . . . 49 4.2.3.ウィンドウを開く. . . . . . . . . . . . . . . . . . . 50 4.2.4.ウィンドウオーバーフロー. . . . . . . . . . . . . . . . . . . . 50 4.2.5.マルチパケットの確認. . . . . . . . . . . . . . 50 4.3.順不同パケット. . . . . . . . . . . . . . . . . 50 4.4.確認のタイムアウト. . . . . . . . . . . . . . . . . 51 4.4.1.適応確認応答タイムアウトの計算. . . . . . 53 4.4.2.輻輳制御：タイムアウトの調整. . . . . . . 54 5.セキュリティに関する考慮事項. . . . . . . . . . . . . . . . . . 54 6.著者のアドレス. . . . . . . . . . . . . . . . . . . . . 55 7.参考資料. . . . . . . . . . . . . . . . . . . . . . . . . 56 8.完全な著作権表示. . . . . . . . . . . . . . . . . . 57
1. Introduction
1.はじめに
PPTP allows existing Network Access Server (NAS) functions to be separated using a client-server architecture. Traditionally, the following functions are implemented by a NAS:
PPTPでは、クライアントサーバーアーキテクチャを使用して、既存のネットワークアクセスサーバー（NAS）機能を分離できます。 従来、以下の機能はNASによって実装されています。
1) Physical native interfacing to PSTN or ISDN and control of
external modems or terminal adapters.
1）PSTNまたはISDNへの物理的なネイティブインターフェイス、および外部モデムまたはターミナルアダプターの制御。
A NAS may interface directly to a telco analog or digital
circuit or attach via an external modem or terminal adapter.
Control of a circuit-switched connection is accomplished with
either modem control or DSS1 ISDN call control protocols.
NASは、電話会社のアナログ回路またはデジタル回路に直接接続するか、外部モデムまたはターミナルアダプターを介して接続できます。 回線交換接続の制御は、モデム制御またはDSS1 ISDN呼制御プロトコルのいずれかを使用して行われます。
The NAS, in conjunction with the modem or terminal adapters,
may perform rate adaption, analog to digital conversion, sync
to async conversion or a number of other alterations of data
streams.
NASは、モデムまたはターミナルアダプタと組み合わせて、レート調整、アナログからデジタルへの変換、同期から非同期への変換、またはデータストリームの他の多くの変更を実行できます。
Hamzeh, et al. Informational [Page 3]
RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
2) Logical termination of a Point-to-Point-Protocol (PPP) Link
Control Protocol (LCP) session.
2）ポイントツーポイントプロトコル（PPP）リンク制御プロトコル（LCP）セッションの論理的終了。
3) Participation in PPP authentication protocols [3,9,10].
3）PPP認証プロトコルへの参加[3、9、10]。
4) Channel aggregation and bundle management for PPP Multilink
Protocol.
4）PPPマルチリンクプロトコルのチャネル集約とバンドル管理。
5) Logical termination of various PPP network control protocols
(NCP).
5）さまざまなPPPネットワーク制御プロトコル（NCP）の論理終端。
6) Multiprotocol routing and bridging between NAS interfaces.
6）NASインターフェイス間のマルチプロトコルルーティングおよびブリッジング。
PPTP divides these functions between the PAC and PNS. The PAC is responsible for functions 1, 2, and possibly 3. The PNS may be responsible for function 3 and is responsible for functions 4, 5, and 6. The protocol used to carry PPP protocol data units (PDUs) between the PAC and PNS, as well as call control and management is addressed by PPTP.
PPTPは、PACとPNSの間でこれらの機能を分割します。 PACは、機能1、2、および場合によっては3を担当します。 PNSは機能3を担当し、機能4、5、および6を担当します。 PACとPNSの間でPPPプロトコルデータユニット（PDU）を伝送するために使用されるプロトコル、およびコール制御と管理は、PPTPによって処理されます。
The decoupling of NAS functions offers these benefits:
NAS機能の分離には、次の利点があります。
Flexible IP address management. Dial-in users may maintain a
single IP address as they dial into different PACs as long as they
are served from a common PNS. If an enterprise network uses
unregistered addresses, a PNS associated with the enterprise
assigns addresses meaningful to the private network.
柔軟なIPアドレス管理。 ダイヤルインユーザーは、共通のPNSからサービスを受ける限り、異なるPACにダイヤルインするときに単一のIPアドレスを維持できます。 企業ネットワークが未登録のアドレスを使用する場合、企業に関連付けられたPNSは、プライベートネットワークに意味のあるアドレスを割り当てます。
Support of non-IP protocols for dial networks behind IP networks.
This allows Appletalk and IPX, for example to be tunneled through
an IP-only provider. The PAC need not be capable of processing
these protocols.
IPネットワークの背後にあるダイヤルネットワークの非IPプロトコルのサポート。 これにより、たとえば、AppletalkとIPXをIPのみのプロバイダーを介してトンネリングできます。 PACはこれらのプロトコルを処理できる必要はありません。
A solution to the "multilink hunt-group splitting" problem.
Multilink PPP, typically used to aggregate ISDN B channels,
requires that all of the channels composing a multilink bundle be
grouped at a single NAS. Since a multilink PPP bundle can be
handled by a single PNS, the channels comprising the bundle may be
spread across multiple PACs.
「マルチリンクハントグループ分割」問題の解決策。 通常ISDN Bチャネルを集約するために使用されるマルチリンクPPPでは、マルチリンクバンドルを構成するすべてのチャネルを単一のNASでグループ化する必要があります。 マルチリンクPPPバンドルは単一のPNSで処理できるため、バンドルを構成するチャネルは複数のPACに分散する場合があります。
1.1. Protocol Goals and Assumptions
1.1。 プロトコルの目標と仮定
The PPTP protocol is implemented only by the PAC and PNS. No other systems need to be aware of PPTP. Dial networks may be connected to a PAC without being aware of PPTP. Standard PPP client software should continue to operate on tunneled PPP links.
PPTPプロトコルは、PACおよびPNSによってのみ実装されます。 他のシステムはPPTPを認識する必要はありません。 ダイヤルネットワークは、PPTPを意識せずにPACに接続される場合があります。 標準のPPPクライアントソフトウェアは、トンネル化されたPPPリンク上で動作し続ける必要があります。
Hamzeh, et al. Informational [Page 4] RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999 PPTP can also be used to tunnel a PPP session over an IP network. In this configuration the PPTP tunnel and the PPP session runs between the same two machines with the caller acting as a PNS.
PPTPは、IPネットワーク上でPPPセッションをトンネリングするためにも使用できます。 この構成では、PPTPトンネルとPPPセッションは、発信者がPNSとして機能する同じ2台のマシン間で実行されます。
It is envisioned that there will be a many-to-many relationship between PACs and PNSs. A PAC may provide service to many PNSs. For example, an Internet service provider may choose to support PPTP for a number of private network clients and create VPNs for them. Each private network may operate one or more PNSs. A single PNS may associate with many PACs to concentrate traffic from a large number of geographically diverse sites.
PACとPNSの間には多対多の関係が存在することが想定されています。 PACは多くのPNSにサービスを提供できます。 たとえば、インターネットサービスプロバイダーは、多数のプライベートネットワーククライアントに対してPPTPをサポートし、それらのVPNを作成することを選択できます。 各プライベートネットワークは1つ以上のPNSを運用できます。 単一のPNSが多くのPACに関連付けられ、地理的に多様な多数のサイトからのトラフィックを集中させる場合があります。
PPTP uses an extended version of GRE to carry user PPP packets. These enhancements allow for low-level congestion and flow control to be provided on the tunnels used to carry user data between PAC and PNS. This mechanism allows for efficient use of the bandwidth available for the tunnels and avoids unnecessary retransmisions and buffer overruns. PPTP does not dictate the particular algorithms to be used for this low level control but it does define the parameters that must be communicated in order to allow such algorithms to work. Suggested algorithms are included in section 4.
PPTPは、GREの拡張バージョンを使用してユーザーPPPパケットを伝送します。 これらの機能拡張により、PACとPNSの間でユーザーデータを伝送するために使用されるトンネルで低レベルの輻輳とフロー制御を提供できるようになります。 このメカニズムにより、トンネルで使用可能な帯域幅を効率的に使用でき、不要な再送信やバッファオーバーランを回避できます。 PPTPは、この低レベルの制御に使用される特定のアルゴリズムを指示しませんが、そのようなアルゴリズムを機能させるために通信する必要があるパラメーターを定義します。 推奨アルゴリズムはセクション4に含まれています。
1.2. Terminology
1.2。 用語
Analog Channel
アナログチャンネル
A circuit-switched communication path which is intended to carry
3.1 Khz audio in each direction.
各方向に3.1 Khzの音声を伝送するための回線交換通信パス。
Digital Channel
デジタルチャンネル
A circuit-switched communication path which is intended to carry
digital information in each direction.
各方向にデジタル情報を伝送することを目的とした回線交換通信パス。
Call
コール
A connection or attempted connection between two terminal
endpoints on a PSTN or ISDN -- for example, a telephone call
between two modems.
PSTNまたはISDN上の2つの端末エンドポイント間の接続または試行された接続-たとえば、2つのモデム間の電話呼び出し。
Control Connection
制御接続
A control connection is created for each PAC, PNS pair and
operates over TCP [4]. The control connection governs aspects of
the tunnel and of sessions assigned to the tunnel.
制御接続は、PAC、PNSペアごとに作成され、TCPを介して動作します[4]。 制御接続は、トンネルおよびトンネルに割り当てられたセッションの側面を管理します。
Hamzeh, et al. Informational [Page 5] RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999 Dial User
ユーザーにダイヤル
An end-system or router attached to an on-demand PSTN or ISDN
which is either the initiator or recipient of a call.
オンデマンドPSTNまたはISDNに接続されたエンドシステムまたはルーター。これは、呼び出しの開始者または受信者のいずれかです。
Network Access Server (NAS)
ネットワークアクセスサーバー（NAS）
A device providing temporary, on-demand network access to users.
This access is point-to-point using PSTN or ISDN lines.
ユーザーに一時的なオンデマンドネットワークアクセスを提供するデバイス。 このアクセスは、PSTNまたはISDN回線を使用したポイントツーポイントです。
PPTP Access Concentrator (PAC)
PPTPアクセスコンセントレータ（PAC）
A device attached to one or more PSTN or ISDN lines capable of PPP
operation and of handling the PPTP protocol. The PAC need only
implement TCP/IP to pass traffic to one or more PNSs. It may also
tunnel non-IP protocols.
PPP操作が可能で、PPTPプロトコルを処理できる1つ以上のPSTNまたはISDN回線に接続されたデバイス。 PACは、トラフィックを1つ以上のPNSに渡すためにTCP / IPを実装するだけで済みます。 また、非IPプロトコルをトンネリングする場合もあります。
PPTP Network Server (PNS)
PPTPネットワークサーバー（PNS）
A PNS is envisioned to operate on general-purpose computing/server
platforms. The PNS handles the server side of the PPTP protocol.
Since PPTP relies completely on TCP/IP and is independent of the
interface hardware, the PNS may use any combination of IP
interface hardware including LAN and WAN devices.
PNSは、汎用コンピューティング/サーバープラットフォームで動作するように想定されています。 PNSは、PPTPプロトコルのサーバー側を処理します。 PPTPは完全にTCP / IPに依存し、インターフェイスハードウェアから独立しているため、PNSはLANおよびWANデバイスを含むIPインターフェイスハードウェアの任意の組み合わせを使用できます。
Session
セッション
PPTP is connection-oriented. The PNS and PAC maintain state for
each user that is attached to a PAC. A session is created when
end-to-end PPP connection is attempted between a dial user and the
PNS. The datagrams related to a session are sent over the tunnel
between the PAC and PNS.
PPTPはコネクション型です。 PNSとPACは、PACに接続されている各ユーザーの状態を維持します。 ダイヤルユーザーとPNSの間でエンドツーエンドのPPP接続が試行されると、セッションが作成されます。 セッションに関連するデータグラムは、PACとPNS間のトンネルを介して送信されます。
Tunnel
トンネル
A tunnel is defined by a PNS-PAC pair. The tunnel protocol is
defined by a modified version of GRE [1,2]. The tunnel carries
PPP datagrams between the PAC and the PNS. Many sessions are
multiplexed on a single tunnel. A control connection operating
over TCP controls the establishment, release, and maintenance of
sessions and of the tunnel itself.
トンネルは、PNS-PACペアによって定義されます。 トンネルプロトコルは、GRE [1,2]の修正バージョンによって定義されています。 トンネルは、PACとPNSの間でPPPデータグラムを伝送します。 多くのセッションは単一のトンネルで多重化されます。 TCPを介して動作する制御接続は、セッションおよびトンネル自体の確立、解放、および保守を制御します。
1.3. Protocol Overview
1.3。 プロトコルの概要
There are two parallel components of PPTP: 1) a Control Connection between each PAC-PNS pair operating over TCP and 2) an IP tunnel operating between the same PAC-PNS pair which is used to transport GRE encapsulated PPP packets for user sessions between the pair.
PPTPには2つの並列コンポーネントがあります。1）TCPを介して動作する各PAC-PNSペア間の制御接続、および2）ユーザーセッションのGREカプセル化PPPパケットを転送するために使用される同じPAC-PNSペア間で動作するIPトンネル ペア。
Hamzeh, et al. Informational [Page 6] RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999 1.3.1. Control Connection Overview
1.3.1。 コントロール接続の概要
Before PPP tunneling can occur between a PAC and PNS, a control connection must be established between them. The control connection is a standard TCP session over which PPTP call control and management information is passed. The control session is logically associated with, but separate from, the sessions being tunneled through a PPTP tunnel. For each PAC-PNS pair both a tunnel and a control connection exist. The control connection is responsible for establishment, management, and release of sessions carried through the tunnel. It is the means by which a PNS is notified of an incoming call at an associated PAC, as well as the means by which a PAC is instructed to place an outgoing dial call.
PACとPNSの間でPPPトンネリングが発生する前に、両者の間で制御接続を確立する必要があります。 制御接続は、PPTP呼制御および管理情報が渡される標準TCPセッションです。 制御セッションは、PPTPトンネルを介してトンネリングされるセッションに論理的に関連付けられていますが、セッションとは別です。 各PAC-PNSペアには、トンネルと制御接続の両方が存在します。 制御接続は、トンネルを介して伝送されるセッションの確立、管理、および解放を担当します。 これは、関連付けられたPACで着信コールがPNSに通知される手段であり、PACが発信ダイヤルコールを発信するように指示される手段でもあります。
A control connection can be established by either the PNS or the PAC. Following the establishment of the required TCP connection, the PNS and PAC establish the control connection using the Start-Control- Connection-Request and -Reply messages. These messages are also used to exchange information about basic operating capabilities of the PAC and PNS. Once the control connection is established, the PAC or PNS may initiate sessions by requesting outbound calls or responding to inbound requests. The control connection may communicate changes in operating characteristics of an individual user session with a Set- Link-Info message. Individual sessions may be released by either the PAC or PNS, also through Control Connection messages.
制御接続は、PNSまたはPACのいずれかによって確立できます。 必要なTCP接続の確立に続いて、PNSおよびPACはStart-Control- Connection-Requestおよび-Replyメッセージを使用して制御接続を確立します。 これらのメッセージは、PACおよびPNSの基本的な操作機能に関する情報を交換するためにも使用されます。 制御接続が確立されると、PACまたはPNSは、アウトバウンドコールを要求するか、インバウンド要求に応答することにより、セッションを開始できます。 制御接続は、Set-Link-Infoメッセージを使用して、個々のユーザーセッションの動作特性の変更を通知します。 個々のセッションは、PACまたはPNSによって、またコントロール接続メッセージを介して解放されます。
The control connection itself is maintained by keep-alive echo messages. This ensures that a connectivity failure between the PNS and the PAC can be detected in a timely manner. Other failures can be reported via the
制御接続自体は、キープアライブエコーメッセージによって維持されます。 これにより、PNSとPAC間の接続障害をタイムリーに検出できます。 その他の障害は、
Wan-Error-Notify message, also on the control connection.
制御エラー時のWan-Error-Notifyメッセージ。
It is intended that the control connection will also carry management related messages in the future, such as a message allowing the PNS to request the status of a given PAC; these message types have not yet been defined.
制御接続は、PNSが特定のPACのステータスを要求できるようにするメッセージなど、将来的に管理関連のメッセージも運ぶことを意図しています。 これらのメッセージタイプはまだ定義されていません。
1.3.2. Tunnel Protocol Overview
1.3.2。 トンネルプロトコルの概要
PPTP requires the establishment of a tunnel for each communicating PNS-PAC pair. This tunnel is used to carry all user session PPP packets for sessions involving a given PNS-PAC pair. A key which is present in the GRE header indicates which session a particular PPP packet belongs to.
PPTPでは、通信するPNS-PACペアごとにトンネルを確立する必要があります。 このトンネルは、特定のPNS-PACペアが関与するセッションのすべてのユーザーセッションPPPパケットを伝送するために使用されます。 GREヘッダーにあるキーは、特定のPPPパケットが属するセッションを示します。
Hamzeh, et al. Informational [Page 7] RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999 In this manner, PPP packets are multiplexed and demultiplexed over a single tunnel between a given PNS-PAC pair. The value to use in the key field is established by the call establishment procedure which takes place on the control connection.
このようにして、PPPパケットは、特定のPNS-PACペア間の単一のトンネルを介して多重化および逆多重化されます。 キーフィールドで使用する値は、制御接続で行われるコール確立手順によって確立されます。
The GRE header also contains acknowledgment and sequencing information that is used to perform some level of congestion-control and error detection over the tunnel. Again the control connection is used to determine rate and buffering parameters that are used to regulate the flow of PPP packets for a particular session over the tunnel. PPTP does not specify the particular algorithms to use for congestion-control and flow-control. Suggested algorithms for the determination of adaptive time-outs to recover from dropped data or acknowledgments on the tunnel are included in section 4.4 of this document.
GREヘッダーには、確認応答とシーケンス情報も含まれています。これらの情報は、トンネルを介して輻輳制御とエラー検出をある程度行うために使用されます。 ここでも、制御接続を使用して、トンネル上の特定のセッションのPPPパケットのフローを調整するために使用されるレートとバッファリングパラメータを決定します。 PPTPは、輻輳制御とフロー制御に使用する特定のアルゴリズムを指定しません。 トンネルでドロップされたデータまたは確認応答から回復するための適応型タイムアウトを決定するための推奨アルゴリズムは、このドキュメントのセクション4.4に含まれています。
1.4. Message Format and Protocol Extensibility
1.4。 メッセージ形式とプロトコルの拡張性
PPTP defines a set of messages sent as TCP data on the control connection between a PNS and a given PAC. The TCP session for the control connection is established by initiating a TCP connection to port 1723 [6]. The source port is assigned to any unused port number.
PPTPは、PNSと特定のPACの間の制御接続でTCPデータとして送信される一連のメッセージを定義します。 制御接続のTCPセッションは、ポート1723へのTCP接続を開始することによって確立されます[6]。 送信元ポートは、未使用のポート番号に割り当てられます。
Each PPTP Control Connection message begins with an 8 octet fixed header portion. This fixed header contains the following: the total length of the message, the PPTP Message Type indicator, and a "Magic Cookie".
各PPTPコントロール接続メッセージは、8オクテットの固定ヘッダー部分で始まります。 この固定ヘッダーには、メッセージの全長、PPTPメッセージタイプインジケーター、および「マジックCookie」が含まれています。
Two Control Connection message types are indicated by the PPTP Message Type field:
2つのコントロール接続メッセージタイプが[PPTPメッセージタイプ]フィールドで示されます。
1 - Control Message
1-コントロールメッセージ
2 - Management Message
2-管理メッセージ
Management messages are currently not defined.
管理メッセージは現在定義されていません。
The Magic Cookie is always sent as the constant 0x1A2B3C4D. Its basic purpose is to allow the receiver to ensure that it is properly synchronized with the TCP data stream. It should not be used as a means for resynchronizing the TCP data stream in the event that a transmitter issues an improperly formatted message. Loss of synchronization must result in immediate closing of the control connection's TCP session.
Magic Cookieは常に定数0x1A2B3C4Dとして送信されます。 その基本的な目的は、レシーバーがTCPデータストリームと正しく同期していることを確認できるようにすることです。 これは、トランスミッタが不適切にフォーマットされたメッセージを発行した場合に、TCPデータストリームを再同期する手段として使用しないでください。 同期が失われると、制御接続のTCPセッションが即座に終了する必要があります。
For clarity, all Control Connection message templates in the next section include the entire PPTP Control Connection message header. Numbers preceded by 0x are hexadecimal values.
明確にするために、次のセクションのすべてのコントロール接続メッセージテンプレートには、PPTPコントロール接続メッセージヘッダー全体が含まれています。 0xが前に付く数値は、16進値です。
Hamzeh, et al. Informational [Page 8] RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999 The currently defined Control Messages, grouped by function, are:
現在定義されているコントロールメッセージは、機能別にグループ化されています。
Control Message Message Code
(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 Session Control)
Set-Link-Info 15
The Start-Control-Connection-Request and -Reply messages determine
which version of the Control Connection protocol will be used. The
version number field carried in these messages consists of a version
number in the high octet and a revision number in the low octet.
Version handling is described in section 2. The current value of the
version number field is 0x0100 for version 1, revision 0.
Start-Control-Connection-Requestおよび-Replyメッセージは、使用するコントロール接続プロトコルのバージョンを決定します。 これらのメッセージで伝えられるバージョン番号フィールドは、高オクテットのバージョン番号と低オクテットのリビジョン番号で構成されます。 バージョン処理については、セクション2で説明します。 バージョン番号フィールドの現在の値は、バージョン1、リビジョン0の0x0100です。
The use of the GRE-like header for the encapsulation of PPP user packets is specified in section 4.1.
PPPユーザーパケットのカプセル化のためのGREのようなヘッダーの使用は、セクション4.1で指定されています。
The MTU for the user data packets encapsulated in GRE is 1532 octets, not including the IP and GRE headers.
GREでカプセル化されたユーザーデータパケットのMTUは1532オクテットで、IPヘッダーとGREヘッダーは含まれません。
Hamzeh, et al. Informational [Page 9] RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999 2. Control Connection Protocol Specification
2.コントロール接続プロトコル仕様
Control Connection messages are used to establish and clear user sessions. The first set of Control Connection messages are used to maintain the control connection itself. The control connection is initiated by either the PNS or PAC after they establish the underlying TCP connection. The procedure and configuration information required to determine which TCP connections are established is not covered by this protocol.
コントロール接続メッセージは、ユーザーセッションの確立とクリアに使用されます。 コントロール接続メッセージの最初のセットは、コントロール接続自体を維持するために使用されます。 制御接続は、基礎となるTCP接続を確立した後、PNSまたはPACのいずれかによって開始されます。 確立されるTCP接続を決定するために必要な手順と構成情報は、このプロトコルの対象外です。
The following Control Connection messages are all sent as user data on the established TCP connection between a given PNS-PAC pair. Note that care has been taken to ensure that all word (2 octet) and longword (4 octet) values begin on appropriate boundaries. All data is sent in network order (high order octets first). Any "reserved" fields MUST be sent as 0 values to allow for protocol extensibility.
次のコントロール接続メッセージはすべて、特定のPNS-PACペア間に確立されたTCP接続でユーザーデータとして送信されます。 すべてのワード（2オクテット）とロングワード（4オクテット）の値が適切な境界で始まるように注意が払われていることに注意してください。 すべてのデータはネットワーク順で送信されます（高次オクテットが最初）。 プロトコルの拡張性を考慮して、「予約済み」フィールドはすべて0値として送信する必要があります。
2.1. Start-Control-Connection-Request
2.1。 Start-Control-Connection-Request
The Start-Control-Connection-Request is a PPTP control message used to establish the control connection between a PNS and a PAC. Each PNS-PAC pair requires a dedicated control connection to be established. A control connection must be established before any other PPTP messages can be issued. The establishment of the control connection can be initiated by either the PNS or PAC. A procedure which handles the occurrence of a collision between PNS and PAC Start-Control-Connection-Requests is described in section 3.1.3.
Start-Control-Connection-Requestは、PNSとPAC間の制御接続を確立するために使用されるPPTP制御メッセージです。 各PNS-PACペアには、専用の制御接続を確立する必要があります。 他のPPTPメッセージを発行する前に、制御接続を確立する必要があります。 制御接続の確立は、PNSまたはPACのいずれかによって開始できます。 PNSとPACのStart-Control-Connection-Requests間の衝突の発生を処理する手順については、セクション3.1.3で説明します。
Hamzeh, et al. Informational [Page 10]
RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
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 Total length in octets of this PPTP
message, including the entire PPTP
header.
このPPTPメッセージのオクテット単位の全長（PPTPヘッダー全体を含む）。
PPTP Message Type 1 for Control Message.
制御メッセージの場合は1。
Magic Cookie 0x1A2B3C4D. This constant value is used
as a sanity check on received messages
(see section 1.4).
0x1A2B3C4D。 この定数値は、受信したメッセージの正常性チェックとして使用されます（セクション1.4を参照）。
Control Message Type 1 for Start-Control-Connection-Request.
Start-Control-Connection-Requestの場合は1。
Reserved0 This field MUST be 0.
このフィールドは0でなければなりません。
Protocol Version The version of the PPTP protocol that the
sender wishes to use.
送信者が使用したいPPTPプロトコルのバージョン。
Reserved1 This field MUST be 0.
このフィールドは0でなければなりません。
Hamzeh, et al. Informational [Page 11]
RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
Framing Capabilities A set of bits indicating the type of framing
that the sender of this message can provide.
The currently defined bit settings are:
このメッセージの送信者が提供できるフレーミングのタイプを示すビットのセット。 現在定義されているビット設定は次のとおりです。
1 - Asynchronous Framing supported
1-非同期フレーミングをサポート
2 - Synchronous Framing supported
2-同期フレーミングをサポート
Bearer Capabilities A set of bits indicating the bearer
capabilities that the sender of this message
can provide. The currently defined bit
settings are:
このメッセージの送信者が提供できるベアラ機能を示すビットのセット。 現在定義されているビット設定は次のとおりです。
1 - Analog access supported
1-アナログアクセスをサポート
2 - Digital access supported
2-デジタルアクセスをサポート
Maximum Channels The total number of individual PPP sessions
this PAC can support. In Start-Control-
Connection-Requests issued by the PNS, this
value SHOULD be set to 0. It MUST be
ignored by the PAC.
このPACがサポートできる個別のPPPセッションの総数。 PNSによって発行されたStart-Control- Connection-Requestsでは、この値を0に設定する必要があります（SHOULD）。 それはPACによって無視されなければなりません。
Firmware Revision This field contains the firmware revision
number of the issuing PAC, when issued by
the PAC, or the version of the PNS PPTP
driver if issued by the PNS.
このフィールドには、PACによって発行されたときの発行PACのファームウェアリビジョン番号、またはPNSによって発行された場合はPNS PPTPドライバーのバージョンが含まれます。
Host Name A 64 octet field containing the DNS name of
the issuing PAC or PNS. If less than 64
octets in length, the remainder of this
field SHOULD be filled with octets of value
0.
発行するPACまたはPNSのDNS名を含む64オクテットフィールド。 長さが64オクテット未満の場合、このフィールドの残りは値0のオクテットで埋められる必要があります（SHOULD）。
Vendor Name A 64 octet field containing a vendor
specific string describing the type of PAC
being used, or the type of PNS software
being used if this request is issued by the
PNS. If less than 64 octets in length, the
remainder of this field SHOULD be filled
with octets of value 0.
使用されているPACのタイプ、またはこの要求がPNSによって発行された場合に使用されているPNSソフトウェアのタイプを説明するベンダー固有の文字列を含む64オクテットフィールド。 長さが64オクテット未満の場合、このフィールドの残りは値0のオクテットで埋められる必要があります（SHOULD）。
2.2. Start-Control-Connection-Reply
2.2. Start-Control-Connection-Reply
The Start-Control-Connection-Reply is a PPTP control message sent in reply to a received Start-Control-Connection-Request message. This message contains a result code indicating the result of the control connection establishment attempt.
Start-Control-Connection-Replyは、受信したStart-Control-Connection-Requestメッセージへの応答として送信されるPPTP制御メッセージです。 このメッセージには、制御接続確立の試行の結果を示す結果コードが含まれています。
Hamzeh, et al. Informational [Page 12]
RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
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 Total length in octets of this PPTP message,
including the entire PPTP header.
このPPTPメッセージのオクテット単位の全長（PPTPヘッダー全体を含む）。
PPTP Message Type 1 for Control Message.
制御メッセージの場合は1。
Magic Cookie 0x1A2B3C4D.
0x1A2B3C4D。
Control Message Type 2 for Start-Control-Connection-Reply.
Start-Control-Connection-Replyの場合は2。
Reserved0 This field MUST be 0.
このフィールドは0でなければなりません。
Protocol Version The version of the PPTP protocol that the
sender wishes to use.
送信者が使用したいPPTPプロトコルのバージョン。
Result Code Indicates the result of the command channel
establishment attempt. Current valid Result
Code values are:
コマンドチャネル確立試行の結果を示します。 現在有効な結果コードの値は次のとおりです。
1 - Successful channel establishment
1-成功したチャネル確立
2 - General error -- Error Code
indicates the problem
2-一般的なエラー-エラーコードは問題を示しています
Hamzeh, et al. Informational [Page 13]
RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
3 - Command channel already exists;
3-コマンドチャネルは既に存在します。
4 - Requester is not authorized to
establish a command channel
4-リクエスタはコマンドチャネルを確立する権限がありません
5 - The protocol version of the
requester is not supported
5-リクエスターのプロトコルバージョンはサポートされていません
Error Code This field is set to 0 unless a "General
Error" exists, in which case Result Code is
set to 2 and this field is set to the value
corresponding to the general error condition
as specified in section 2.2.
「一般エラー」が存在しない場合、このフィールドは0に設定されます。この場合、結果コードは2に設定され、このフィールドはセクション2.2で指定された一般エラー条件に対応する値に設定されます。
Framing Capabilities A set of bits indicating the type of framing
that the sender of this message can provide.
The currently defined bit settings are:
このメッセージの送信者が提供できるフレーミングのタイプを示すビットのセット。 現在定義されているビット設定は次のとおりです。
1 - Asynchronous Framing supported
1-非同期フレーミングをサポート
2 - Synchronous Framing supported.
2-同期フレーミングがサポートされています。
Bearer Capabilities A set of bits indicating the bearer
capabilities that the sender of this message
can provide. The currently defined bit
settings are:
このメッセージの送信者が提供できるベアラ機能を示すビットのセット。 現在定義されているビット設定は次のとおりです。
1 - Analog access supported
1-アナログアクセスをサポート
2 - Digital access supported
2-デジタルアクセスをサポート
Maximum Channels The total number of individual PPP sessions
this PAC can support. In a Start-Control-
Connection-Reply issued by the PNS, this
value SHOULD be set to 0 and it must be
ignored by the PAC. The PNS MUST NOT use
this value to try to track the remaining
number of PPP sessions that the PAC will
allow.
このPACがサポートできる個別のPPPセッションの総数。 PNSによって発行されたStart-Control-Connection-Replyでは、この値は0に設定する必要があり（SHOULD）、PACによって無視される必要があります。 PNSは、PACが許可するPPPセッションの残りの数を追跡するためにこの値を使用してはなりません（MUST NOT）。
Firmware Revision This field contains the firmware revision
number of the issuing PAC, or the version of
the PNS PPTP driver if issued by the PNS.
このフィールドには、発行元のPACのファームウェアリビジョン番号、またはPNSによって発行された場合はPNS PPTPドライバーのバージョンが含まれます。
Hamzeh, et al. Informational [Page 14]
RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
Host Name A 64 octet field containing the DNS name of
the issuing PAC or PNS. If less than 64
octets in length, the remainder of this
field SHOULD be filled with octets of value
0.
発行するPACまたはPNSのDNS名を含む64オクテットフィールド。 長さが64オクテット未満の場合、このフィールドの残りは値0のオクテットで埋められる必要があります（SHOULD）。
Vendor Name A 64 octet field containing a vendor
specific string describing the type of PAC
being used, or the type of PNS software
being used if this request is issued by the
PNS. If less than 64 octets in length, the
remainder of this field SHOULD be filled
with octets of value 0.
使用されているPACのタイプ、またはこの要求がPNSによって発行された場合に使用されているPNSソフトウェアのタイプを説明するベンダー固有の文字列を含む64オクテットフィールド。 長さが64オクテット未満の場合、このフィールドの残りは値0のオクテットで埋められる必要があります（SHOULD）。
2.3. Stop-Control-Connection-Request
2.3。 Stop-Control-Connection-Request
The Stop-Control-Connection-Request is a PPTP control message sent by one peer of a PAC-PNS control connection to inform the other peer that the control connection should be closed. In addition to closing the control connection, all active user calls are implicitly cleared. The reason for issuing this request is indicated in the Reason field.
Stop-Control-Connection-Requestは、PAC-PNS制御接続の1つのピアが送信する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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reason | Reserved1 | Reserved2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Length Total length in octets of this PPTP message,
including the entire PPTP header.
このPPTPメッセージのオクテット単位の全長（PPTPヘッダー全体を含む）。
PPTP Message Type 1 for Control Message.
制御メッセージの場合は1。
Magic Cookie 0x1A2B3C4D.
0x1A2B3C4D。
Control Message Type 3 for Stop-Control-Connection-Request.
Stop-Control-Connection-Requestの場合は3。
Reserved0 This field MUST be 0.
このフィールドは0でなければなりません。
Reason Indicates the reason for the control
connection being closed. Current valid
Reason values are:
制御接続が閉じられた理由を示します。 現在有効な理由値は次のとおりです。
Hamzeh, et al. Informational [Page 15]
RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
1 (None) - General request to clear
control connection
1（なし）-制御接続をクリアするための一般的な要求
2 (Stop-Protocol) - Can't support
peer's version of the protocol
2（Stop-Protocol）-ピアのバージョンのプロトコルをサポートできません
3 (Stop-Local-Shutdown) - Requester is
being shut down
3（Stop-Local-Shutdown）-リクエスターはシャットダウンされています
Reserved1, Reserved2 These fields MUST be 0.
これらのフィールドは0でなければなりません。
2.4. Stop-Control-Connection-Reply
2.4。 Stop-Control-Connection-Reply
The Stop-Control-Connection-Reply is a PPTP control message sent by one peer of a PAC-PNS control connection upon receipt of a Stop- Control-Connection-Request from the other peer.
Stop-Control-Connection-Replyは、PAC-PNS制御接続の1つのピアが、他のピアから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 Total length in octets of this PPTP message,
including the entire PPTP header.
このPPTPメッセージのオクテット単位の全長（PPTPヘッダー全体を含む）。
PPTP Message Type 1 for Control Message.
制御メッセージの場合は1。
Magic Cookie 0x1A2B3C4D.
0x1A2B3C4D。
Control Message Type 4 for Stop-Control-Connection-Reply.
Stop-Control-Connection-Replyの場合は4。
Reserved0 This field MUST be 0.
このフィールドは0でなければなりません。
Result Code Indicates the result of the attempt to close
the control connection. Current valid Result
Code values are:
制御接続を閉じようとした結果を示します。 現在有効な結果コードの値は次のとおりです。
Hamzeh, et al. Informational [Page 16]
RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
1 (OK) - Control connection closed
1（OK）-制御接続が閉じました
2 (General Error) - Control connection
not closed for reason indicated in
Error Code
2（一般エラー）-エラーコードに示された理由により、制御接続が閉じられていません
Error Code This field is set to 0 unless a "General
Error" exists, in which case Result Code is
set to 2 and this field is set to the value
corresponding to the general error condition
as specified in section 2.2.
「一般エラー」が存在しない場合、このフィールドは0に設定されます。この場合、結果コードは2に設定され、このフィールドはセクション2.2で指定された一般エラー条件に対応する値に設定されます。
Reserved1 This field MUST be 0.
このフィールドは0でなければなりません。
2.5. Echo-Request
2.5。 エコーリクエスト
The Echo-Request is a PPTP control message sent by either peer of a PAC-PNS control connection. This control message is used as a "keep- alive" for the control connection. The receiving peer issues an Echo-Reply to each Echo-Request received. As specified in section 3.1.4, if the sender does not receive an Echo-Reply in response to an Echo-Request, it will eventually clear the control connection.
エコー要求は、PAC-PNS制御接続のいずれかのピアによって送信されるPPTP制御メッセージです。 この制御メッセージは、制御接続の「キープアライブ」として使用されます。 受信ピアは、受信した各エコー要求に対してエコー応答を発行します。 セクション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 Total length in octets of this PPTP message,
including the entire PPTP header.
このPPTPメッセージのオクテット単位の全長（PPTPヘッダー全体を含む）。
PPTP Message Type 1 for Control Message.
制御メッセージの場合は1。
Magic Cookie 0x1A2B3C4D.
0x1A2B3C4D。
Control Message Type 5 for Echo-Request.
Echo-Requestの場合は5。
Reserved0 This field MUST be 0.
このフィールドは0でなければなりません。
Hamzeh, et al. Informational [Page 17]
RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
Identifier A value set by the sender of the Echo-
Request that is used to match the reply with
the corresponding request.
エコー要求の送信者によって設定された値で、応答と対応する要求を照合するために使用されます。
2.6. Echo-Reply
2.6。 エコー応答
The Echo-Reply is a PPTP control message sent by either peer of a PAC-PNS control connection in response to the receipt of an Echo- Request.
エコー応答は、エコー要求の受信に応答して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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Result Code | Error Code | Reserved1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Length Total length in octets of this PPTP message,
including the entire PPTP header.
このPPTPメッセージのオクテット単位の全長（PPTPヘッダー全体を含む）。
PPTP Message Type 1 for Control Message.
制御メッセージの場合は1。
Magic Cookie 0x1A2B3C4D.
0x1A2B3C4D。
Control Message Type 6 for Echo-Reply.
エコー応答の場合は6。
Reserved0 This field MUST be 0.
このフィールドは0でなければなりません。
Identifier The contents of the identify field from the
received Echo-Request is copied to this
field.
受信したエコー要求からの識別フィールドの内容は、このフィールドにコピーされます。
Result Code Indicates the result of the receipt of the
Echo-Request. Current valid Result Code
values are:
Echo-Requestの受信結果を示します。 現在有効な結果コードの値は次のとおりです。
1 (OK) - The Echo-Reply is valid
1（オン）-エコー応答は有効です
2 (General Error) - Echo-Request not
accepted for the reason indicated in
Error Code
2（一般エラー）-エラーコードに示された理由により、エコー要求は受け入れられません
Hamzeh, et al. Informational [Page 18]
RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
Error Code This field is set to 0 unless a "General
Error" condition exists, in which case
Result Code is set to 2 and this field is
set to the value corresponding to the
general error condition as specified in
section 2.2.
「一般エラー」条件が存在しない限り、このフィールドは0に設定されます。この場合、結果コードは2に設定され、このフィールドはセクション2.2で指定された一般エラー条件に対応する値に設定されます。
Reserved1 This field MUST be 0.
2.7. Outgoing-Call-Request
2.7。 発信要求
The Outgoing-Call-Request is a PPTP control message sent by the PNS to the PAC to indicate that an outbound call from the PAC is to be established. This request provides the PAC with information required to make the call. It also provides information to the PAC that is used to regulate the transmission of data to the PNS for this session once it is established.
Outgoing-Call-Requestは、PNSからPACに送信されるPPTP制御メッセージで、PACからの発信コールが確立されることを示します。 このリクエストは、PACに電話をかけるために必要な情報を提供します。 また、このセッションが確立されると、このセッションのPNSへのデータ送信を規制するために使用される情報をPACに提供します。
Hamzeh, et al. Informational [Page 19]
RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
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 Total length in octets of this PPTP message,
including the entire PPTP header.
このPPTPメッセージのオクテット単位の全長（PPTPヘッダー全体を含む）。
PPTP Message Type 1 for Control Message.
制御メッセージの場合は1。
Magic Cookie 0x1A2B3C4D.
0x1A2B3C4D。
Control Message Type 7 for Outgoing-Call-Request.
Outgoing-Call-Requestの場合は7。
Reserved0 This field MUST be 0.
このフィールドは0でなければなりません。
Hamzeh, et al. Informational [Page 20]
RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
Call ID A unique identifier, unique to a particular
PAC-PNS pair assigned by the PNS to this
session. It is used to multiplex and
demultiplex data sent over the tunnel
between the PNS and PAC involved in this
session.
PNSによってこのセッションに割り当てられた特定のPAC-PNSペアに固有の一意の識別子。 これは、このセッションに関与するPNSとPACの間のトンネルを介して送信されるデータを多重化および逆多重化するために使用されます。
Call Serial Number An identifier assigned by the PNS to this
session for the purpose of identifying this
particular session in logged session
information. Unlike the Call ID, both the
PNS and PAC associate the same Call Serial
Number with a given session. The combination
of IP address and call serial number SHOULD
be unique.
ログされたセッション情報でこの特定のセッションを識別するために、PNSによってこのセッションに割り当てられた識別子。 コールIDとは異なり、PNSとPACはどちらも、同じコールシリアル番号を特定のセッションに関連付けます。 IPアドレスとコールシリアル番号の組み合わせは一意である必要があります。
Minimum BPS The lowest acceptable line speed (in
bits/second) for this session.
このセッションの最低許容回線速度（ビット/秒）。
Maximum BPS The highest acceptable line speed (in
bits/second) for this session.
このセッションで許容される最高の回線速度（ビット/秒）。
Bearer Type A value indicating the bearer capability
required for this outgoing call. The
currently defined values are:
この発信コールに必要なベアラ機能を示す値。 現在定義されている値は次のとおりです。
1 - Call to be placed on an analog
channel
1-アナログチャネルで発信されるコール
2 - Call to be placed on a digital
channel
2-デジタルチャネルで発信される通話
3 - Call can be placed on any type of
channel
3-通話はどのタイプのチャネルにもかけられます
Framing Type A value indicating the type of PPP framing
to be used for this outgoing call.
この発信コールに使用されるPPPフレーミングのタイプを示す値。
1 - Call to use Asynchronous framing
1-非同期フレーミングを使用するための呼び出し
2 - Call to use Synchronous framing
2-同期フレーミングを使用するための呼び出し
3 - Call can use either type of
framing
3-通話はどちらのタイプのフレーミングも使用できます
Packet Recv. Window Size The number of received data packets the PNS
will buffer for this session.
ウィンドウサイズこのセッションでPNSがバッファリングする受信データパケットの数。
Hamzeh, et al. Informational [Page 21]
RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
Packet Processing Delay A measure of the packet processing delay
that might be imposed on data sent to the
PNS from the PAC. This value is specified
in units of 1/10 seconds. For the PNS this
number should be very small. See section
4.4 for a description of how this value is
determined and used.
PACからPNSに送信されるデータに課される可能性のあるパケット処理遅延の測定値。 この値は、1/10秒単位で指定されます。 PNSの場合、この数は非常に小さいはずです。 この値がどのように決定され使用されるかの説明については、セクション4.4を参照してください。
Phone Number Length The actual number of valid digits in the
Phone Number field.
「電話番号」フィールドの有効な数字の実際の数。
Reserved1 This field MUST be 0.
このフィールドは0でなければなりません。
Phone Number The number to be dialed to establish the
outgoing session. For ISDN and analog calls
this field is an ASCII string. If the Phone
Number is less than 64 octets in length, the
remainder of this field is filled with
octets of value 0.
発信セッションを確立するためにダイヤルする番号。 ISDNおよびアナログコールの場合、このフィールドはASCII文字列です。 電話番号の長さが64オクテット未満の場合、このフィールドの残りの部分は値0のオクテットで埋められます。
Subaddress A 64 octet field used to specify additional
dialing information. If the subaddress is
less than 64 octets long, the remainder of
this field is filled with octets of value 0.
追加のダイヤル情報を指定するために使用される64オクテットフィールド。 サブアドレスの長さが64オクテット未満の場合、このフィールドの残りの部分は値0のオクテットで埋められます。
2.8. Outgoing-Call-Reply
2.8。 発信呼び出し応答
The Outgoing-Call-Reply is a PPTP control message sent by the PAC to the PNS in response to a received Outgoing-Call-Request message. The reply indicates the result of the outgoing call attempt. It also provides information to the PNS about particular parameters used for the call. It provides information to allow the PNS to regulate the transmission of data to the PAC for this session.
Outgoing-Call-Replyは、受信したOutgoing-Call-Requestメッセージに応答してPACからPNSに送信されるPPTP制御メッセージです。 応答は、発信呼び出しの結果を示します。 また、コールに使用される特定のパラメータに関する情報をPNSに提供します。 これは、PNSがこのセッションのPACへのデータ送信を調整できるようにするための情報を提供します。
Hamzeh, et al. Informational [Page 22]
RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
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 Total length in octets of this PPTP message,
including the entire PPTP header.
このPPTPメッセージのオクテット単位の全長（PPTPヘッダー全体を含む）。
PPTP Message Type 1 for Control Message.
制御メッセージの場合は1。
Magic Cookie 0x1A2B3C4D.
0x1A2B3C4D。
Control Message Type 8 for Outgoing-Call-Reply.
Outgoing-Call-Replyの場合は8。
Reserved0 This field MUST be 0.
このフィールドは0でなければなりません。
Call ID A unique identifier for the tunnel, assigned
by the PAC to this session. It is used to
multiplex and demultiplex data sent over the
tunnel between the PNS and PAC involved in
this session.
PACによってこのセッションに割り当てられたトンネルの一意の識別子。 これは、このセッションに関与するPNSとPACの間のトンネルを介して送信されるデータを多重化および逆多重化するために使用されます。
Peer's Call ID This field is set to the value received in
the Call ID field of the corresponding
Outgoing-Call-Request message. It is used
by the PNS to match the Outgoing-Call-Reply
with the Outgoing-Call-Request it issued. It
also is used as the value sent in the GRE
header for mux/demuxing.
このフィールドは、対応するOutgoing-Call-RequestメッセージのCall IDフィールドで受信した値に設定されます。 これは、PNSがOutgoing-Call-Replyを発行したOutgoing-Call-Requestと照合するために使用されます。 また、mux / demuxingのGREヘッダーで送信される値としても使用されます。
Hamzeh, et al. Informational [Page 23]
RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
Result Code This value indicates the result of the
Outgoing-Call-Request attempt. Currently
valid values are:
この値は、Outgoing-Call-Request試行の結果を示します。 現在有効な値は次のとおりです。
1 (Connected) - Call established with
no errors
1（接続済み）-エラーなしで確立されたコール
2 (General Error) - Outgoing Call not
established for the reason indicated
in Error Code
2（一般エラー）-エラーコードに示されている理由により、発信が確立されていません
3 (No Carrier) - Outgoing Call failed
due to no carrier detected
3（キャリアなし）-キャリアが検出されなかったため、発信に失敗しました
4 (Busy) - Outgoing Call failed due to
detection of a busy signal
4（ビジー）-ビジー信号を検出したため、発信に失敗しました
5 (No Dial Tone) - Outgoing Call
failed due to lack of a dial tone
5（ダイヤルトーンなし）-ダイヤルトーンがないため、発信に失敗しました
6 (Time-out) - Outgoing Call was not
established within time allotted by
PAC
6（タイムアウト）-PACによって割り当てられた時間内に発信呼び出しが確立されませんでした
7 (Do Not Accept) - Outgoing Call
administratively prohibited
7（受け入れない）-発信は管理上禁止されています
Error Code This field is set to 0 unless a "General
Error" condition exists, in which case
Result Code is set to 2 and this field is
set to the value corresponding to the
general error condition as specified in
section 2.2.
「一般エラー」条件が存在しない限り、このフィールドは0に設定されます。この場合、結果コードは2に設定され、このフィールドはセクション2.2で指定された一般エラー条件に対応する値に設定されます。
Cause Code This field gives additional failure
information. Its value can vary depending
upon the type of call attempted. For ISDN
call attempts it is the Q.931 cause code.
このフィールドは、追加の障害情報を提供します。 その値は、試行されたコールのタイプによって異なります。 ISDNコール試行の場合、これはQ.931原因コードです。
Connect Speed The actual connection speed used, in
bits/second.
使用されている実際の接続速度（ビット/秒）。
Packet Recv. Window Size The number of received data packets the PAC
will buffer for this session.
ウィンドウサイズPACがこのセッションでバッファする受信データパケットの数。
Hamzeh, et al. Informational [Page 24]
RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
Packet Processing Delay A measure of the packet processing delay
that might be imposed on data sent to the
PAC from the PNS. This value is specified
in units of 1/10 seconds. For the PAC, this
number is related to the size of the buffer
used to hold packets to be sent to the
client and to the speed of the link to the
client. This value should be set to the
maximum delay that can normally occur
between the time a packet arrives at the PAC
and is delivered to the client. See section
4.4 for an example of how this value is
determined and used.
PNSからPACに送信されるデータに課される可能性のあるパケット処理遅延の測定値。 この値は、1/10秒単位で指定されます。 PACの場合、この数値は、クライアントに送信されるパケットを保持するために使用されるバッファーのサイズと、クライアントへのリンクの速度に関連しています。 この値は、パケットがPACに到着してからクライアントに配信されるまでの間に通常発生する可能性がある最大遅延に設定する必要があります。 この値の決定と使用の例については、セクション4.4を参照してください。
Physical Channel ID This field is set by the PAC in a vendor-
specific manner to the physical channel
number used to place this call. It is used
for logging purposes only.
このフィールドは、PACによってベンダー固有の方法で、このコールの発信に使用される物理チャネル番号に設定されます。 ロギング目的でのみ使用されます。
2.9. Incoming-Call-Request
2.9。 着信呼び出し要求
The Incoming-Call-Request is a PPTP control message sent by the PAC to the PNS to indicate that an inbound call is to be established from the PAC. This request provides the PNS with parameter information for the incoming call.
Incoming-Call-Requestは、PACからPNSに送信されるPPTP制御メッセージで、PACからの着信呼び出しが確立されることを示します。 この要求は、着信コールのパラメータ情報をPNSに提供します。
This message is the first in the "three-way handshake" used by PPTP for establishing incoming calls. The PAC may defer answering the call until it has received an Incoming-Call-Reply from the PNS indicating that the call should be established. This mechanism allows the PNS to obtain sufficient information about the call before it is answered to determine whether the call should be answered or not.
このメッセージは、PPTPが着信コールを確立するために使用する「3ウェイハンドシェイク」の最初のものです。 PACは、PNSからIncoming-Call-Replyを受信するまで、コールへの応答を延期して、コールを確立する必要があることを示します。 このメカニズムにより、PNSは、応答する前にコールに関する十分な情報を取得して、コールに応答する必要があるかどうかを判断できます。
Hamzeh, et al. Informational [Page 25]
RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Call Bearer Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Physical Channel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Dialed Number Length | Dialing Number Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Dialed Number (64 octets) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Dialing Number (64 octets) +
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Subaddress (64 octets) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Length Total length in octets of this PPTP message,
including the entire PPTP header.
このPPTPメッセージのオクテット単位の全長（PPTPヘッダー全体を含む）。
PPTP Message Type 1 for Control Message.
制御メッセージの場合は1。
Magic Cookie 0x1A2B3C4D.
0x1A2B3C4D。
Control Message Type 9 for Incoming-Call-Request.
着信呼び出し要求の場合は9。
Reserved0 This field MUST be 0.
このフィールドは0でなければなりません。
Call ID A unique identifier for this tunnel,
assigned by the PAC to this session. It is
used to multiplex and demultiplex data sent
over the tunnel between the PNS and PAC
involved in this session.
PACによってこのセッションに割り当てられた、このトンネルの一意の識別子。 これは、このセッションに関与するPNSとPACの間のトンネルを介して送信されるデータを多重化および逆多重化するために使用されます。
Hamzeh, et al. Informational [Page 26]
RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
Call Serial Number An identifier assigned by the PAC to this
session for the purpose of identifying this
particular session in logged session
information. Unlike the Call ID, both the
PNS and PAC associate the same Call Serial
Number to a given session. The combination
of IP address and call serial number should
be unique.
ログされたセッション情報でこの特定のセッションを識別するために、PACによってこのセッションに割り当てられた識別子。 コールIDとは異なり、PNSとPACはどちらも、同じコールシリアル番号を特定のセッションに関連付けます。 IPアドレスとコールシリアル番号の組み合わせは一意である必要があります。
Bearer Type A value indicating the bearer capability
used for this incoming call. Currently
defined values are:
この着信コールに使用されるベアラ機能を示す値。 現在定義されている値は次のとおりです。
1 - Call is on an analog channel
1-通話はアナログチャネルで行われている
2 - Call is on a digital channel
2-通話はデジタルチャネルです
Physical Channel ID This field is set by the PAC in a vendor-
specific manner to the number of the
physical channel this call arrived on.
このフィールドは、PACによってベンダー固有の方法で、このコールが到着した物理チャネルの数に設定されます。
Dialed Number Length The actual number of valid digits in the
Dialed Number field.
[Dialed Number]フィールドの有効な数字の実際の数。
Dialing Number Length The actual number of valid digits in the
Dialing Number field.
[ダイヤル番号]フィールドの有効な数字の実際の数。
Dialed Number The number that was dialed by the caller.
For ISDN and analog calls this field is an
ASCII string. If the Dialed Number is less
than 64 octets in length, the remainder of
this field is filled with octets of value 0.
発信者がダイヤルした番号。 ISDNおよびアナログコールの場合、このフィールドはASCII文字列です。 ダイヤル番号の長さが64オクテット未満の場合、このフィールドの残りの部分は値0のオクテットで埋められます。
Dialing Number The number from which the call was placed.
For ISDN and analog calls this field is an
ASCII string. If the Dialing Number is less
than 64 octets in length, the remainder of
this field is filled with octets of value 0.
通話の発信元の番号。 ISDNおよびアナログコールの場合、このフィールドはASCII文字列です。 ダイヤル番号の長さが64オクテット未満の場合、このフィールドの残りの部分は値0のオクテットで埋められます。
Subaddress A 64 octet field used to specify additional
dialing information. If the subaddress is
less than 64 octets long, the remainder of
this field is filled with octets of value 0.
追加のダイヤル情報を指定するために使用される64オクテットフィールド。 サブアドレスの長さが64オクテット未満の場合、このフィールドの残りの部分は値0のオクテットで埋められます。
Hamzeh, et al. Informational [Page 27] RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999 2.10. Incoming-Call-Reply
2.10。 着信呼び出し応答
The Incoming-Call-Reply is a PPTP control message sent by the PNS to the PAC in response to a received Incoming-Call-Request message. The reply indicates the result of the incoming call attempt. It also provides information to allow the PAC to regulate the transmission of data to the PNS for this session.
Incoming-Call-Replyは、受信したIncoming-Call-Requestメッセージに応答してPNSからPACに送信されるPPTP制御メッセージです。 応答は、着信呼び出しの結果を示します。 また、PACがこのセッションのPNSへのデータ送信を規制できるようにするための情報も提供します。
This message is the second in the three-way handshake used by PPTP for establishing incoming calls. It indicates to the PAC whether the call should be answered or not.
このメッセージは、PPTPが着信呼び出しを確立するために使用する3ウェイハンドシェイクの2番目です。 コールに応答する必要があるかどうかを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 Transmit Delay | Reserved1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Length Total length in octets of this PPTP message,
including the entire PPTP header.
このPPTPメッセージのオクテット単位の全長（PPTPヘッダー全体を含む）。
PPTP Message Type 1 for Control Message.
制御メッセージの場合は1。
Magic Cookie 0x1A2B3C4D.
0x1A2B3C4D。
Control Message Type 10 for Incoming-Call-Reply.
Incoming-Call-Replyの場合は10。
Reserved0 This field MUST be 0.
このフィールドは0でなければなりません。
Call ID A unique identifier for this tunnel assigned
by the PNS to this session. It is used to
multiplex and demultiplex data sent over the
tunnel between the PNS and PAC involved in
this session.
PNSによってこのセッションに割り当てられたこのトンネルの一意の識別子。 これは、このセッションに関与するPNSとPACの間のトンネルを介して送信されるデータを多重化および逆多重化するために使用されます。
Peer's Call ID This field is set to the value received in
the Call ID field of the corresponding
Incoming-Call-Request message. It is used by
Hamzeh, et al. Informational [Page 28]
RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
the PAC to match the Incoming-Call-Reply
with the Incoming-Call-Request it issued.
This value is included in the GRE header of
transmitted data packets for this session.
このフィールドは、対応するIncoming-Call-RequestメッセージのCall IDフィールドで受信した値に設定されます。 これは、PACによって使用され、Incoming-Call-Replyを、発行したIncoming-Call-Requestと照合します。 この値は、このセッションで送信されるデータパケットのGREヘッダーに含まれています。
Result Code This value indicates the result of the
Incoming-Call-Request attempt. Current
valid Result Code values are:
この値は、Incoming-Call-Request試行の結果を示します。 現在有効な結果コードの値は次のとおりです。
1 (Connect) - The PAC should answer
the incoming call
1（接続）-PACは着信呼び出しに応答する必要があります
2 (General Error) - The Incoming Call
should not be established due to the
reason indicated in Error Code
2（一般エラー）-エラーコードに示された理由により、着信を確立できません
3 (Do Not Accept) - The PAC should not
accept the incoming call. It should
hang up or issue a busy indication
3（受け入れない）-PACは着信呼び出しを受け入れません。 ハングアップするか、ビジー表示を出す必要があります
Error Code This field is set to 0 unless a "General
Error" condition exists, in which case
Result Code is set to 2 and this field is
set to the value corresponding to the
general error condition as specified in
section 2.2.
「一般エラー」条件が存在しない限り、このフィールドは0に設定されます。この場合、結果コードは2に設定され、このフィールドはセクション2.2で指定された一般エラー条件に対応する値に設定されます。
Packet Recv. Window Size The number of received data packets the PAC
will buffer for this session.
ウィンドウサイズPACがこのセッションでバッファする受信データパケットの数。
Packet Transmit Delay A measure of the packet processing delay
that might be imposed on data sent to the
PAC from the PNS. This value is specified
in units of 1/10 seconds.
PNSからPACに送信されるデータに課される可能性のあるパケット処理遅延の測定値。 この値は、1/10秒単位で指定されます。
Reserved1 This field MUST be 0.
2.11. Incoming-Call-Connected
2.11。 着信呼接続
The Incoming-Call-Connected message is a PPTP control message sent by the PAC to the PNS in response to a received Incoming-Call-Reply. It provides information to the PNS about particular parameters used for the call. It also provides information to allow the PNS to regulate the transmission of data to the PAC for this session.
Incoming-Call-Connectedメッセージは、受信したIncoming-Call-Replyに応答してPACからPNSに送信されるPPTP制御メッセージです。 コールに使用される特定のパラメータに関する情報をPNSに提供します。 また、PNSがこのセッションのPACへのデータ送信を規制できるようにするための情報も提供します。
This message is the third in the three-way handshake used by PPTP for establishing incoming calls. It provides a mechanism for providing the PNS with additional information about the call that cannot, in Hamzeh, et al. Informational [Page 29] RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999 general, be obtained at the time the Incoming-Call-Request is issued by the PAC.
このメッセージは、PPTPが着信呼び出しを確立するために使用する3ウェイハンドシェイクの3番目です。 これは、一般に、PACによってIncoming-Call-Requestが発行されたときに取得できないコールに関する追加情報を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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer's Call ID | Reserved1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Connect Speed |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Packet Recv. Window Size | Packet Transmit Delay |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Framing Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Length Total length in octets of this PPTP message,
including the entire PPTP header.
このPPTPメッセージのオクテット単位の全長（PPTPヘッダー全体を含む）。
PPTP Message Type 1 for Control Message.
制御メッセージの場合は1。
Magic Cookie 0x1A2B3C4D.
0x1A2B3C4D。
Control Message Type 11 for Incoming-Call-Connected.
着信呼接続の場合は11。
Reserved0 This field MUST be 0.
このフィールドは0でなければなりません。
Peer's Call ID This field is set to the value received in
the Call ID field of the corresponding
Incoming-Call-Reply message. It is used by
the PNS to match the Incoming-Call-Connected
with the Incoming-Call-Reply it issued.
このフィールドは、対応するIncoming-Call-ReplyメッセージのCall IDフィールドで受信した値に設定されます。 これは、PNSがIncoming-Call-Connectedを、発行したIncoming-Call-Replyと照合するために使用されます。
Connect Speed The actual connection speed used, in
bits/second.
使用されている実際の接続速度（ビット/秒）。
Packet Recv. Window Size The number of received data packets the PAC
will buffer for this session.
ウィンドウサイズPACがこのセッションでバッファする受信データパケットの数。
Packet Transmit Delay A measure of the packet processing delay
that might be imposed on data sent to the
PAC from the PNS. This value is specified
in units of 1/10 seconds.
PNSからPACに送信されるデータに課される可能性のあるパケット処理遅延の測定値。 この値は、1/10秒単位で指定されます。
Hamzeh, et al. Informational [Page 30]
RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
Framing Type A value indicating the type of PPP framing
being used by this incoming call.
この着信コールで使用されているPPPフレーミングのタイプを示す値。
1 - Call uses asynchronous framing
1-呼び出しは非同期フレーミングを使用します
2 - Call uses synchronous framing
2-呼び出しは同期フレームを使用します
2.12. Call-Clear-Request
2.12。 コールクリアリクエスト
The Call-Clear-Request is a PPTP control message sent by the PNS to the PAC indicating that a particular call is to be disconnected. The call being cleared can be either an incoming or outgoing call, in any state. The PAC responds to this message with a Call-Disconnect- Notify message.
Call-Clear-Requestは、PNSがPACに送信するPPTP制御メッセージで、特定のコールが切断されることを示します。 クリアされるコールは、任意の状態の着信または発信のいずれかです。 PACはこのメッセージにCall-Disconnect- Notifyメッセージで応答します。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Length Total length in octets of this PPTP message,
including the entire PPTP header.
このPPTPメッセージのオクテット単位の全長（PPTPヘッダー全体を含む）。
PPTP Message Type 1 for Control Message.
制御メッセージの場合は1。
Magic Cookie 0x1A2B3C4D.
0x1A2B3C4D。
Control Message Type 12 for Call-Clear-Request.
Call-Clear-Requestの場合は12。
Reserved0 This field MUST be 0.
このフィールドは0でなければなりません。
Call ID The Call ID assigned by the PNS to this
call. This value is used instead of the
Peer's Call ID because the latter may not be
known to the PNS if the call must be aborted
during call establishment.
PNSによってこの通話に割り当てられた通話ID。 ピアのコールIDの代わりにこの値が使用されます。これは、コールの確立中にコールを中止する必要がある場合、PNSは後者を認識できない可能性があるためです。
Reserved1 This field MUST be 0.
このフィールドは0でなければなりません。
Hamzeh, et al. Informational [Page 31] RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999 2.13. Call-Disconnect-Notify
2.13。 通話切断通知
The Call-Disconnect-Notify message is a PPTP control message sent by the PAC to the PNS. It is issued whenever a call is disconnected, due to the receipt by the PAC of a Call-Clear-Request or for any other reason. Its purpose is to inform the PNS of both the disconnection and the reason for it.
Call-Disconnect-Notifyメッセージは、PACからPNSに送信されるPPTP制御メッセージです。 PACがCall-Clear-Requestを受信したため、またはその他の理由で、通話が切断されたときに発行されます。 その目的は、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 | Result Code | Error Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cause Code | Reserved1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Call Statistics (128 octets) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Length Total length in octets of this PPTP message,
including the entire PPTP header.
このPPTPメッセージのオクテット単位の全長（PPTPヘッダー全体を含む）。
PPTP Message Type 1 for Control Message.
制御メッセージの場合は1。
Magic Cookie 0x1A2B3C4D.
0x1A2B3C4D。
Control Message Type 13 for Call-Disconnect-Notify.
Call-Disconnect-Notifyの場合は13。
Reserved0 This field MUST be 0.
このフィールドは0でなければなりません。
Call ID The value of the Call ID assigned by the PAC
to this call. This value is used instead of
the Peer's Call ID because the latter may
not be known to the PNS if the call must be
aborted during call establishment.
PACによってこの通話に割り当てられた通話IDの値。 ピアのコールIDの代わりにこの値が使用されます。これは、コールの確立中にコールを中止する必要がある場合、PNSは後者を認識できない可能性があるためです。
Hamzeh, et al. Informational [Page 32]
RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
Result Code This value indicates the reason for the
disconnect. Current valid Result Code values
are:
この値は、切断の理由を示します。 現在有効な結果コードの値は次のとおりです。
1 (Lost Carrier) - Call disconnected
due to loss of carrier
1（キャリアの喪失）-キャリアの喪失により通話が切断されました
2 (General Error) - Call disconnected
for the reason indicated in Error
Code
2（一般エラー）-エラーコードに示された理由により、通話が切断されました
3 (Admin Shutdown) - Call disconnected
for administrative reasons
3（管理者によるシャットダウン）-管理上の理由で通話が切断されました
4 (Request) - Call disconnected due to
received Call-Clear-Request
4（リクエスト）-Call-Clear-Requestを受信したため、通話が切断されました
Error Code This field is set to 0 unless a "General
Error" condition exists, in which case the
Result Code is set to 2 and this field is
set to the value corresponding to the
general error condition as specified in
section 2.2.
「一般エラー」条件が存在しない限り、このフィールドは0に設定されます。この場合、結果コードは2に設定され、このフィールドはセクション2.2で指定された一般エラー条件に対応する値に設定されます。
Cause Code This field gives additional disconnect
information. Its value varies depending on
the type of call being disconnected. For
ISDN calls it is the Q.931 cause code.
このフィールドは、追加の切断情報を提供します。 その値は、切断される通話のタイプによって異なります。 ISDNコールの場合、これはQ.931原因コードです。
Call Statistics This field is an ASCII string containing
vendor-specific call statistics that can be
logged for diagnostic purposes. If the
length of the string is less than 128, the
remainder of the field is filled with octets
of value 0.
このフィールドは、診断目的でログに記録できるベンダー固有のコール統計を含むASCII文字列です。 文字列の長さが128未満の場合、フィールドの残りは値0のオクテットで埋められます。
2.14. WAN-Error-Notify
2.14。 WANエラー通知
The WAN-Error-Notify message is a PPTP control message sent by the PAC to the PNS to indicate WAN error conditions (conditions that occur on the interface supporting PPP). The counters in this message are cumulative. This message should only be sent when an error occurs, and not more than once every 60 seconds. The counters are reset when a new call is established.
WAN-Error-Notifyメッセージは、PACからPNSに送信されるPPTP制御メッセージで、WANエラー状態（PPPをサポートするインターフェイスで発生する状態）を示します。 このメッセージのカウンターは累積されます。 このメッセージは、エラーが発生した場合にのみ送信され、60秒ごとに送信されます。 カウンタは、新しいコールが確立されるとリセットされます。
Hamzeh, et al. Informational [Page 33]
RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Length Total length in octets of this PPTP message,
including the entire PPTP header.
このPPTPメッセージのオクテット単位の全長（PPTPヘッダー全体を含む）。
PPTP Message Type 1 for Control Message.
制御メッセージの場合は1。
Magic Cookie 0x1A2B3C4D.
0x1A2B3C4D。
Control Message Type 14 for WAN-Error-Notify.
WAN-Error-Notifyの場合は14。
Reserved0 This field MUST be 0.
このフィールドは0でなければなりません。
Peer's Call ID Th Call ID assigned by the PNS to this call.
PNSによってこの通話に割り当てられた通話ID。
CRC Errors Number of PPP frames received with CRC
errors since session was established.
セッションの確立以降にCRCエラーを伴って受信されたPPPフレームの数。
Framing Errors Number of improperly framed PPP packets
received.
誤ってフレーム化されたPPPパケットの受信数。
Hardware Overruns Number of receive buffer over-runs since
session was established.
セッションが確立されてからの受信バッファオーバーランの数。
Buffer Overruns Number of buffer over-runs detected since
session was established.
セッションの確立後に検出されたバッファオーバーランの数。
Hamzeh, et al. Informational [Page 34]
RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
Time-out Errors Number of time-outs since call was
established.
コールが確立されてからのタイムアウトの数。
Alignment Errors Number of alignment errors since call was
established.
コールが確立されてからのアライメントエラーの数。
2.15. Set-Link-Info
2.15。 Set-Link-Info
The Set-Link-Info message is a PPTP control message sent by the PNS to the PAC to set PPP-negotiated options. Because these options can change at any time during the life of the call, the PAC must be able to update its internal call information dynamically and perform PPP negotiation on an active PPP session.
Set-Link-Infoメッセージは、PNSによってPACに送信されてPPPネゴシエーションされたオプションを設定するPPTP制御メッセージです。 これらのオプションはコールの存続期間中いつでも変更できるため、PACは内部のコール情報を動的に更新し、アクティブなPPPセッションで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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Length Total length in octets of this PPTP message,
including the entire PPTP header.
このPPTPメッセージのオクテット単位の全長（PPTPヘッダー全体を含む）。
PPTP Message Type 1 for Control Message.
制御メッセージの場合は1。
Magic Cookie 0x1A2B3C4D.
0x1A2B3C4D。
Control Message Type 15 for Set-Link-Info.
Set-Link-Infoの場合は15。
Reserved0 This field MUST be 0.
このフィールドは0でなければなりません。
Peer's Call ID The value of the Call ID assigned by the PAC
to this call.
PACによってこの通話に割り当てられた通話IDの値。
Reserved1 This field MUST be 0.
このフィールドは0でなければなりません。
Hamzeh, et al. Informational [Page 35]
RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
Send ACCM The send ACCM value the client should use to
process outgoing PPP packets. The default
value used by the client until this message
is received is 0XFFFFFFFF. See [7].
クライアントが発信PPPパケットを処理するために使用する必要がある送信ACCM値。 このメッセージが受信されるまでクライアントが使用するデフォルト値は0XFFFFFFFFです。 [7]を参照してください。
Receive ACCM The receive ACCM value the client should use
to process incoming PPP packets. The default
value used by the client until this message
is received is 0XFFFFFFFF. See [7].
クライアントが着信PPPパケットを処理するために使用する必要がある受信ACCM値。 このメッセージが受信されるまでクライアントが使用するデフォルト値は0XFFFFFFFFです。 [7]を参照してください。
2.16. General Error Codes
2.16。 一般的なエラーコード
General error codes pertain to types of errors which are not specific to any particular PPTP request, but rather to protocol or message format errors. If a PPTP reply indicates in its Result Code that a general error occurred, the General Error value should be examined to determined what the error was. The currently defined General Error codes and their meanings are:
一般的なエラーコードは、特定のPPTP要求に固有ではなく、プロトコルまたはメッセージ形式のエラーに関連するエラーの種類に関連しています。 PPTP応答が結果コードで一般エラーが発生したことを示している場合、一般エラー値を調べて、エラーが何であったかを判別する必要があります。 現在定義されている一般的なエラーコードとその意味は次のとおりです。
0 (None) - No general error
0（なし）-一般的なエラーなし
1 (Not-Connected) - No control connection exists yet for this
PAC-PNS pair
1（未接続）-このPAC-PNSペアにはまだ制御接続がありません
2 (Bad-Format) - Length is wrong or Magic Cookie value is
incorrect
2（不正な形式）-長さが間違っているか、マジッククッキーの値が正しくありません
3 (Bad-Value) - One of the field values was out of range or
reserved field was non-zero
3（無効な値）-フィールド値の1つが範囲外であるか、予約済みフィールドがゼロ以外でした
4 (No-Resource) - Insufficient resources to handle this command
now
4（リソースなし）-このコマンドを処理するにはリソースが不足しています
5 (Bad-Call ID) - The Call ID is invalid in this context
5（不正コールID）-コールIDはこのコンテキストでは無効です
6 (PAC-Error) - A generic vendor-specific error occurred in
the PAC
6（PAC-Error）-PACで一般的なベンダー固有のエラーが発生しました
3. Control Connection Protocol Operation
3.接続プロトコル操作の制御
This section describes the operation of various PPTP control connection functions and the Control Connection messages which are used to support them. The protocol operation of the control connection is simplified because TCP is used to provide a reliable transport mechanism. Ordering and retransmission of messages is not a concern at this level. The TCP connection itself, however, can close at any time and an appropriate error recovery mechanism must be provided to handle this case.
このセクションでは、さまざまなPPTPコントロール接続機能の操作と、それらをサポートするために使用されるコントロール接続メッセージについて説明します。 信頼性の高い転送メカニズムを提供するためにTCPが使用されるため、制御接続のプロトコル操作が簡素化されます。 メッセージの順序付けと再送信は、このレベルでは問題になりません。 ただし、TCP接続自体はいつでも閉じる可能性があるため、このケースを処理するには、適切なエラー回復メカニズムを提供する必要があります。
Hamzeh, et al. Informational [Page 36] RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999 Some error recovery procedures are common to all states of the control connection. If an expected reply does not arrive within 60 seconds, the control connection is closed, unless otherwise specified. Appropriate logging should be implemented for easy determination of the problems and the reasons for closing the control connection.
一部のエラー回復手順は、制御接続のすべての状態に共通です。 予期される応答が60秒以内に到着しない場合、特に指定がない限り、制御接続は閉じられます。 問題と制御接続を閉じる理由を簡単に判別できるように、適切なロギングを実装する必要があります。
Receipt of an invalid or malformed Control Connection message should be logged appropriately, and the control connection should be closed and restarted to ensure recovery into a known state.
無効または不正なコントロール接続メッセージの受信を適切にログに記録し、既知の状態に確実に回復するためにコントロール接続を閉じて再起動する必要があります。
3.1. Control Connection States
3.1。 接続状態の制御
The control connection relies on a standard TCP connection for its service. The PPTP control connection protocol is not distinguishable between the PNS and PAC, but is distinguishable between the originator and receiver. The originating peer is the one which first attempts the TCP open. Since either PAC or PNS may originate a connection, it is possible for a TCP collision to occur. See section 3.1.3 for a description of this situation.
制御接続は、サービスの標準TCP接続に依存しています。 PPTP制御接続プロトコルは、PNSとPACを区別できませんが、発信者と受信者を区別できます。 発信ピアは、最初にTCPオープンを試みるピアです。 PACまたはPNSが接続を開始する可能性があるため、TCP衝突が発生する可能性があります。 この状況の説明については、セクション3.1.3を参照してください。
3.1.1. Control Connection Originator (may be PAC or PNS)
3.1.1。 コントロール接続オリジネーター（PACまたはPNSの場合があります）
TCP Open Indication
/Send Start Control
Connection Request +-----------------+
+------------------------------------>| wait_ctl_reply |
| +-----------------+
| Collision/See (4.1.3) Close TCP V V V Receive Start Ctl
| +-------------------------------+ | | Connection Reply
| | | | Version OK
^ V | V
+-----------------+ Receive Start Ctl | +-----------------+
| idle | Connection Reply | | established |
+-----------------+ Version Not OK | +-----------------+
^ | V Local Terminate
| Receive Stop Control | | /Send Stop
| Connection Request | | Control Request
| /Send Stop Control Reply V V
| Close TCP +-----------------+
+-------------------------------------| wait_stop_reply |
+-----------------+
Hamzeh, et al. Informational [Page 37]
RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
idle
アイドル
The control connection originator attempts to open a TCP
connection to the peer during idle state. When the TCP connection
is open, the originator transmits a send Start-Control-
Connection-Request and then enters the wait_ctl_reply state.
制御接続の発信元は、アイドル状態の間にピアへのTCP接続を開こうとします。 TCP接続が開いている場合、発信者は送信Start-Control-Connection-Requestを送信してから、wait_ctl_reply状態に入ります。
wait_ctl_reply
wait_ctl_reply
The originator checks to see if another TCP connection has been
requested from the same peer, and if so, handles the collision
situation described in section 3.1.3.
発信者は、同じピアから別のTCP接続が要求されているかどうかを確認し、要求されている場合は、セクション3.1.3で説明されている衝突状況を処理します。
When a Start-Control-Connection-Reply is received, it is examined
for a compatible version. If the version of the reply is lower
than the version sent in the request, the older (lower) version
should be used provided it is supported. If the version in the
reply is earlier and supported, the originator moves to the
established state. If the version is earlier and not supported, a
Stop-Control-Connection-Request SHOULD be sent to the peer and the
originator moves into the wait_stop_reply state.
Start-Control-Connection-Replyを受信すると、互換性のあるバージョンかどうかが調べられます。 応答のバージョンがリクエストで送信されたバージョンよりも低い場合は、サポートされている場合は古い（低い）バージョンを使用する必要があります。 応答のバージョンが以前のバージョンでサポートされている場合、発信者は確立された状態に移行します。 バージョンが以前のものでサポートされていない場合は、Stop-Control-Connection-Requestをピアに送信する必要があり（SHOULD）、発信者はwait_stop_reply状態に移行します。
established
設立
An established connection may be terminated by either a local
condition or the receipt of a Stop-Control-Connection-Request. In
the event of a local termination, the originator MUST send a
Stop-Control-Connection-Request and enter the wait_stop_reply
state.
確立された接続は、ローカル条件またはStop-Control-Connection-Requestの受信によって終了する場合があります。 ローカル終了の場合、オリジネーターはStop-Control-Connection-Requestを送信して、wait_stop_reply状態に入る必要があります。
If the originator receives a Stop-Control-Connection-Request it
SHOULD send a Stop-Control-Connection-Reply and close the TCP
connection making sure that the final TCP information has been
"pushed" properly.
発信者がStop-Control-Connection-Requestを受信した場合、Stop-Control-Connection-Replyを送信してTCP接続を閉じ、最終的なTCP情報が適切に「プッシュ」されていることを確認する必要があります。
wait_stop_reply
wait_stop_reply
If a Stop-Control-Connection-Reply is received, the TCP connection
SHOULD be closed and the control connection becomes idle.
Stop-Control-Connection-Replyを受信した場合、TCP接続を閉じて、制御接続をアイドル状態にする必要があります（SHOULD）。
Hamzeh, et al. Informational [Page 38] RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999 3.1.2. Control connection Receiver (may be PAC or PNS)
3.1.2。 制御接続レシーバー（PACまたはPNSの場合があります）
Receive Start Control Connection Request
Version Not OK/Send Start Control Connection
Reply with Error
+--------+
| | Receive Control Connection Request Version OK
| | /Send Start Control Connection Reply
| | +----------------------------------------+
^ V ^ V
+-----------------+ Receive Start Ctl +-----------------+
| Idle | Connection Request | Established |
+-----------------+ /Send Stop Reply +-----------------+
^ ^ Close TCP V V Local Terminate
| +-------------------------------------+ | /Send Stop
| | Control Conn.
| V Request
| +-----------------+
+-------------------------------------| Wait-Stop-Reply |
Receive Stop Control +-----------------+
Connection Reply
/Close TCP
idle
アイドル
The control connection receiver waits for a TCP open attempt on
port 1723. When notified of an open TCP connection, it should
prepare to receive PPTP messages. When a Start-Control-
Connection-Request is received its version field should be
examined. If the version is earlier than the receiver's version
and the earlier version can be supported by the receiver, the
receiver SHOULD send a Start-Control-Connection-Reply. If the
version is earlier than the receiver's version and the version
cannot be supported, the receiver SHOULD send a Start-Connection-
Reply message, close the TCP connection and remain in the idle
state. If the receiver's version is the same as earlier than the
peer's, the receiver SHOULD send a Start-Control-Connection-Reply
with the receiver's version and enter the established state.
制御接続レシーバーは、ポート1723でTCPオープンの試行を待機します。 開いているTCP接続の通知を受けると、PPTPメッセージを受信する準備をする必要があります。 Start-Control- Connection-Requestが受信されると、そのバージョンフィールドを調べる必要があります。 バージョンがレシーバーのバージョンよりも古く、レシーバーが以前のバージョンをサポートできる場合、レシーバーはStart-Control-Connection-Replyを送信する必要があります（SHOULD）。 バージョンがレシーバーのバージョンより前であり、バージョンがサポートできない場合、レシーバーはStart-Connection- Replyメッセージを送信し、TCP接続を閉じてアイドル状態のままにする必要があります（SHOULD）。 レシーバーのバージョンがピアのバージョンと同じである場合、レシーバーは、レシーバーのバージョンでStart-Control-Connection-Replyを送信して、確立状態に入る必要があります（SHOULD）。
established
設立
An established connection may be terminated by either a local
condition or the reception of a Stop-Control-Connection-Request.
In the event of a local termination, the originator MUST send a
Stop-Control-Connection-Request and enter the wait_stop_reply
state.
確立された接続は、ローカル条件またはStop-Control-Connection-Requestの受信によって終了する場合があります。 ローカル終了の場合、オリジネーターはStop-Control-Connection-Requestを送信して、wait_stop_reply状態に入る必要があります。
Hamzeh, et al. Informational [Page 39]
RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
If the originator receives a Stop-Control-Connection-Request it
SHOULD send a Stop-Control-Connection-Reply and close the TCP
connection, making sure that the final TCP information has been
"pushed" properly.
発信者がStop-Control-Connection-Requestを受信した場合、Stop-Control-Connection-Replyを送信してTCP接続を閉じ、最終的なTCP情報が適切に「プッシュ」されていることを確認する必要があります。
wait_stop_reply
wait_stop_reply
If a Stop-Control-Connection-Reply is received, the TCP connection
SHOULD be closed and the control connection becomes idle.
Stop-Control-Connection-Replyを受信した場合、TCP接続を閉じて、制御接続をアイドル状態にする必要があります（SHOULD）。
3.1.3. Start Control Connection Initiation Request Collision
3.1.3。 制御接続開始要求の衝突の開始
A PAC and PNS must have only one control connection between them. It is possible, however, for a PNS and a PAC to simultaneously attempt to establish a control connection to each other. When a Start- Control-Connection-Request is received on one TCP connection and another Start-Control-Connection-Request has already been sent on another TCP connection to the same peer, a collision has occurred.
PACとPNSは、それらの間の制御接続を1つだけ持つ必要があります。 ただし、PNSとPACが同時に制御接続の確立を試みることは可能です。 Start-Control-Connection-Requestが1つのTCP接続で受信され、別のStart-Control-Connection-Requestが別のTCP接続で同じピアにすでに送信されている場合、衝突が発生しています。
The "winner" of the initiation race is the peer with the higher IP address (compared as 32 bit unsigned values, network number more significant). For example, if the peers 192.33.45.17 and 192.33.45.89 collide, the latter will be declared the winner. The loser will immediately close the TCP connection it initiated, without sending any further PPTP control messages on it and will respond to the winner's request with a Start-Control-Connection-Reply message. The winner will wait for the Start-Control-Connection-Reply on the connection it initiated and also wait for a TCP termination indication on the connection the loser opened. The winner MUST NOT send any messages on the connection the loser initiated.
開始レースの「勝者」は、より高いIPアドレスを持つピアです（32ビットの符号なしの値と比較して、ネットワーク番号はより重要です）。 たとえば、ピア192.33.45.17と192.33.45.89が衝突した場合、後者が勝者として宣言されます。 敗者は、PPTP制御メッセージを送信せずに、開始したTCP接続をすぐに閉じ、勝者の要求にStart-Control-Connection-Replyメッセージで応答します。 勝者は、開始した接続でStart-Control-Connection-Replyを待ち、敗者が開いた接続でTCP終了指示を待ちます。 勝者は敗者が開始した接続でメッセージを送信してはいけません。
3.1.4. Keep Alives and Timers
3.1.4。 キープアライブとタイマー
A control connection SHOULD be closed by closing the underlying TCP connection under the following circumstances:
以下の状況では、基礎となるTCP接続を閉じることにより、制御接続を閉じる必要があります（SHOULD）。
1. If a control connection is not in the established state (i.e.,
Start-Control-Connection-Request and Start-Control-Connection-
Reply have not been exchanged), a control connection SHOULD be
closed after 60 seconds by a peer waiting for a Start-Control-
Connection-Request or Start-Control-Connection-Reply message.
1。 制御接続が確立された状態にない場合（つまり、Start-Control-Connection-RequestとStart-Control-Connection- Replyが交換されていない場合）、制御接続は、開始を待機しているピアによって60秒後に閉じられる必要があります（SHOULD） -Control- Connection-RequestまたはStart-Control-Connection-Replyメッセージ。
2. If a peer's control connection is in the established state and has
not received a control message for 60 seconds, it SHOULD send a
Echo-Request message. If an Echo-Reply is not received 60 seconds
after the Echo-Request message transmission, the control
connection SHOULD be closed.
2。 ピアの制御接続が確立された状態にあり、60秒間制御メッセージを受信しなかった場合は、エコー要求メッセージを送信する必要があります（SHOULD）。 Echo-Requestメッセージの送信から60秒後にEcho-Replyが受信されない場合は、制御接続を閉じる必要があります（SHOULD）。
Hamzeh, et al. Informational [Page 40] RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999 3.2. Call States
3.2。 通話状態
3.2.1. Timing considerations
3.2.1。 タイミングに関する考慮事項
Because of the real-time nature of telephone signaling, both the PNS and PAC should be implemented with multi-threaded architectures such that messages related to multiple calls are not serialized and blocked. The transit delay between the PAC and PNS should not exceed one second. The call and connection state figures do not specify exceptions caused by timers. The implicit assumption is that since the TCP-based control connection is being verified with keep-alives, there is less need to maintain strict timers for call control messages.
電話信号のリアルタイム性により、PNSとPACの両方をマルチスレッドアーキテクチャで実装して、複数の呼び出しに関連するメッセージがシリアル化およびブロックされないようにする必要があります。 PACとPNS間の通過遅延は1秒を超えてはなりません。 呼び出しと接続状態の数値は、タイマーが原因の例外を指定していません。 暗黙の前提は、TCPベースの制御接続がキープアライブで検証されているため、呼制御メッセージの厳密なタイマーを維持する必要性が少ないことです。
Establishing outbound international calls, including the modem training and negotiation sequences, may take in excess of 1 minute so the use of short timers is discouraged.
モデムのトレーニングやネゴシエーションシーケンスを含む発信国際通話の確立には1分以上かかる場合があるため、短いタイマーの使用はお勧めしません。
If a state transition does not occur within 1 minute (except for connections in the idle or established states), the integrity of the protocol processing between the peers is suspect and the ENTIRE CONTROL CONNECTION should be closed and restarted. All Call IDs are logically released whenever a control connection is started. This presumably also helps in preventing toll calls from being "lost" and never cleared.
状態遷移が1分以内に発生しない場合（アイドル状態または確立された状態の接続を除く）、ピア間のプロトコル処理の整合性が疑われ、ENTIRE CONTROL CONNECTIONを閉じて再起動する必要があります。 制御接続が開始されると、すべてのコールIDが論理的に解放されます。 これは恐らく、通行料金が「失われ」、決してクリアされるのを防ぐのにも役立つでしょう。
3.2.2. Call ID Values
3.2.2。 コールID値
Each peer assigns a Call ID value to each user session it requests or accepts. This Call ID value MUST be unique for the tunnel between the PNS and PAC to which it belongs. Tunnels to other peers can use the same Call ID number so the receiver of a packet on a tunnel needs to associate a user session with a particular tunnel and Call ID. It is suggested that the number of potential Call ID values for each tunnel be at least twice as large as the maximum number of calls expected on a given tunnel.
各ピアは、要求または受け入れる各ユーザーセッションにコールID値を割り当てます。 このコールID値は、それが属するPNSとPACの間のトンネルに対して一意である必要があります。 他のピアへのトンネルは同じコールID番号を使用できるため、トンネル上のパケットの受信者は、ユーザーセッションを特定のトンネルおよびコールIDに関連付ける必要があります。 各トンネルの潜在的なコールID値の数は、所定のトンネルで予想されるコールの最大数の少なくとも2倍にすることをお勧めします。
A session is defined by the triple (PAC, PNS, Call ID).
セッションはトリプル（PAC、PNS、コールID）によって定義されます。
3.2.3. Incoming Calls
3.2.3。 着信
An Incoming-Call-Request message is generated by the PAC when an associated telephone line rings. The PAC selects a Call ID and serial number and indicates the call bearer type. Modems should always indicate analog call type. ISDN calls should indicate digital when unrestricted digital service or rate adaption is used and analog if Hamzeh, et al. Informational [Page 41] RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999 digital modems are involved. Dialing number, dialed number, and subaddress may be included in the message if they are available from the telephone network.
Incoming-Call-Requestメッセージは、関連する電話回線が鳴ったときにPACによって生成されます。 PACは、コールIDとシリアル番号を選択し、コールベアラタイプを示します。 モデムは常にアナログコールタイプを示す必要があります。 ISDNコールは、無制限のデジタルサービスまたはレート調整が使用されている場合はデジタル、デジタルモデムが含まれている場合はアナログを示す必要があります。 ダイヤル番号、ダイヤル番号、およびサブアドレスは、電話ネットワークから利用できる場合、メッセージに含まれることがあります。
Once the PAC sends the Incoming-Call-Request, it waits for a response from the PNS but does not answer the call from the telephone network. The PNS may choose not to accept the call if:
PACが着信呼び出し要求を送信すると、PNSからの応答を待ちますが、電話網からの呼び出しには応答しません。 PNSは、次の場合にコールを受け入れないことを選択できます。
- No resources are available to handle more sessions
より多くのセッションを処理するために使用できるリソースがありません
- The dialed, dialing, or subaddress fields are not indicative of
an authorized user
ダイヤル、ダイヤル、またはサブアドレスのフィールドは、許可されたユーザーを示すものではありません
- The bearer service is not authorized or supported
ベアラサービスが許可またはサポートされていません
If the PNS chooses to accept the call, it responds with an Incoming- Call-Reply which also indicates window sizes (see section 4.2). When the PAC receives the Outgoing-Call-Reply, it attempts to connect the call, assuming the calling party has not hung up. A final call connected message from the PAC to the PNS indicates that the call states for both the PAC and the PNS should enter the established state.
PNSがコールを受け入れることを選択した場合、PNSはウィンドウサイズも示すIncoming-Call-Replyで応答します（セクション4.2を参照）。 PACはOutgoing-Call-Replyを受信すると、発呼者が電話を切っていないことを前提として、コールを接続しようとします。 PACからPNSへの最後のコール接続メッセージは、PACとPNSの両方のコール状態が確立済み状態になることを示しています。
When the dialed-in client hangs up, the call is cleared normally and the PAC sends a Call-Disconnect-Notify message. If the PNS wishes to clear a call, it sends a Call-Clear-Request message and then waits for a Call-Disconnect-Notify.
ダイヤルインクライアントが電話を切ると、コールは正常にクリアされ、PACはCall-Disconnect-Notifyメッセージを送信します。 PNSがコールをクリアしたい場合、PNSはCall-Clear-Requestメッセージを送信し、Call-Disconnect-Notifyを待ちます。
3.2.3.1. PAC Incoming Call States
3.2.3.1。 PAC着信状態
Ring/Send Incoming Call Request +-----------------+
+----------------------------------------->| wait_reply |
| +-----------------+
| Receive Incoming Call Reply V V V
| Not Accepting | | | Receive Incoming
| +--------------------------------+ | | Call Reply Accept-
| | +------------------------------+ | ing/Answer call;
| | | Abort/Send Call | Send Call
^ V V Disconnect Notify V Connected
+-----------------+ +-----------------+
| idle |<-----------------------------| established |
+-----------------+ Receive Clear Call Request +-----------------+
or telco call dropped
or local disconnect
/Send Call Disconnect Notify
Hamzeh, et al. Informational [Page 42]
RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
The states associated with the PAC for incoming calls are:
着信コールのPACに関連付けられている状態は次のとおりです。
idle
アイドル
The PAC detects an incoming call on one of its telco interfaces.
Typically this means an analog line is ringing or an ISDN TE has
detected an incoming Q.931 SETUP message. The PAC sends an
Incoming-Call-Request message and moves to the wait_reply state.
PACは、Telcoインターフェイスの1つで着信コールを検出します。 通常、これはアナログ回線が鳴っているか、ISDN TEが着信Q.931 SETUPメッセージを検出したことを意味します。 PACはIncoming-Call-Requestメッセージを送信し、wait_reply状態に移行します。
wait_reply
wait_reply
The PAC receives an Incoming-Call-Reply message indicating non-
willingness to accept the call (general error or don't accept) and
moves back into the idle state. If the reply message indicates
that the call is accepted, the PAC sends an Incoming-Call-
Connected message and enters the established state.
PACは、コールを受け入れる意思がない（一般的なエラーまたは受け入れない）ことを示すIncoming-Call-Replyメッセージを受信し、アイドル状態に戻ります。 コールが受け入れられたことを応答メッセージが示している場合、PACはIncoming-Call-Connectedメッセージを送信し、確立状態に入ります。
established
設立
Data is exchanged over the tunnel. The call may be cleared
following:
データはトンネルを介して交換されます。 通話は次のようにクリアされます。
An event on the telco connection. The PAC sends a
Call-Disconnect-Notify message
電話会社の接続に関するイベント。 PACはCall-Disconnect-Notifyメッセージを送信します
Receipt of a Call-Clear-Request. The PAC sends a
Call-Disconnect-Notify message
Call-Clear-Requestの受信。 PACはCall-Disconnect-Notifyメッセージを送信します
A local reason. The PAC sends a Call-Disconnect-Notify message.
ローカルな理由。 PACはCall-Disconnect-Notifyメッセージを送信します。
3.2.3.2. PNS Incoming Call States
3.2.3.2。 PNS着信状態
Receive Incoming Call Request
/Send Incoming Call Reply +-----------------+
Not Accepting if Error | Wait-Connect |
+-----+ +-----------------+
| | Receive Incoming Call Req. ^ V V
| | /Send Incoming Call Reply OK | | | Receive Incoming
| | +--------------------------------+ | | Call Connect
^ V ^ V------------------------------+ V
+-----------------+ Receive Call Disconnect +-----------------+
| Idle | Notify +- | Established |
+-----------------+ | +-----------------+
^ ^ | V Local Terminate
| +----------------------------+ | /Send Call Clear
| Receive Call Disconnect | Request
| Notify V
| +-----------------+
+--------------------------------------| Wait-Disconnect |
Receive Call Disconnect +-----------------+
Notify
Hamzeh, et al. Informational [Page 43]
RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
The states associated with the PNS for incoming calls are:
着信コールのPNSに関連付けられている状態は次のとおりです。
idle
アイドル
An Incoming-Call-Request message is received. If the request is
not acceptable, an Incoming-Call-Reply is sent back to the PAC and
the PNS remains in the idle state. If the Incoming-Call-Request
message is acceptable, an Incoming-Call-Reply is sent indicating
accept in the result code. The session moves to the wait_connect
state.
Incoming-Call-Requestメッセージが受信されます。 要求が受け入れられない場合、Incoming-Call-ReplyがPACに返送され、PNSはアイドル状態のままになります。 Incoming-Call-Requestメッセージが受け入れ可能である場合、結果コードで受け入れを示すIncoming-Call-Replyが送信されます。 セッションがwait_connect状態に移行します。
wait_connect
wait_connect
If the session is connected on the PAC, the PAC sends an incoming
call connect message to the PNS which then moves into established
state. The PAC may send a Call-Disconnect-Notify to indicate that
the incoming caller could not be connected. This could happen,
for example, if a telephone user accidently places a standard
voice call to a PAC resulting in a handshake failure on the called
modem.
セッションがPACで接続されている場合、PACは着信コール接続メッセージをPNSに送信し、PNSは確立された状態に移行します。 PACはCall-Disconnect-Notifyを送信して、着信した発信者が接続できなかったことを示します。 これは、たとえば、電話のユーザーが誤って標準の音声通話をPACにかけたために、呼び出されたモデムでハンドシェイクが失敗した場合に発生する可能性があります。
established
設立
The session is terminated either by receipt of a Call-Disconnect-
Notify message from the PAC or by sending a Call-Clear-Request.
Once a Call-Clear-Request has been sent, the session enters the
wait_disconnect state.
セッションは、PACからCall-Disconnect-Notifyメッセージを受信するか、Call-Clear-Requestを送信することによって終了します。 Call-Clear-Requestが送信されると、セッションはwait_disconnect状態になります。
wait_disconnect
wait_disconnect
Once a Call-Disconnect-Notify is received the session moves back
to the idle state.
Call-Disconnect-Notifyを受信すると、セッションはアイドル状態に戻ります。
3.2.4. Outgoing Calls
3.2.4。 発信通話
Outgoing messages are initiated by a PNS and instruct a PAC to place a call on a telco interface. There are only two messages for outgoing calls: Outgoing-Call-Request and Outgoing-Call-Reply. The PNS sends an Outgoing-Call-Request specifying the dialed party phone number and subaddress as well as speed and window parameters. The PAC MUST respond to the Outgoing-Call-Request message with an Outgoing-Call- Reply message once the PAC determines that:
発信メッセージはPNSによって開始され、電話会社のインターフェイスに電話をかけるようにPACに指示します。 発信コールには、Outgoing-Call-RequestとOutgoing-Call-Replyの2つのメッセージしかありません。 PNSは、発信者の電話番号とサブアドレス、および速度とウィンドウのパラメータを指定してOutgoing-Call-Requestを送信します。 PACが次のことを決定すると、PACはOutgoing-Call-RequestメッセージにOutgoing-Call-Replyメッセージで応答する必要があります。
The call has been successfully connected
通話は正常に接続されました
A call failure has occurred for reasons such as: no interfaces are
available for dial-out, the called party is busy or does not
answer, or no dial tone is detected on the interface chosen for
dialing
ダイヤルアウトに使用できるインターフェイスがない、着信側がビジーである、または応答しない、またはダイヤル用に選択されたインターフェイスでダイヤルトーンが検出されないなどの理由で、通話障害が発生した
Hamzeh, et al. Informational [Page 44] RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999 3.2.4.1. PAC Outgoing Call States
3.2.4.1。 PACの発信状態
Receive Outgoing Call Request in Error
/Send Outgoing Call Reply with Error
|--------+
| | Receive Outgoing Call Request No Error
| | /Off Hook; Dial
| | +-----------------------------------------
^ V ^ V
+-----------------+ Incomplete Call +-----------------+
| idle | /Send Outgoing Call | wait_cs_ans |
+-----------------+ Reply with Error +-----------------+
^ ^ or Recv. Call Clear Req. V V Telco Answer
| | /Send Disconnect Notify| | /Send Outgoing
| +-------------------------------------+ | Call Reply.
| V
| +-----------------+
+-------------------------------------| established |
Receive Call Clear Request +-----------------+
or local terminate
or telco disconnect
/Hangup call and send
Call Disconnect Notify
The states associated with the PAC for outgoing calls are:
発信コールのPACに関連付けられている状態は次のとおりです。
idle
アイドル
Received Outgoing-Call-Request. If this is received in error,
respond with an Outgoing-Call-Reply with error condition set.
Otherwise, allocate physical channel to dial on. Place the
outbound call, wait for a connection, and move to the wait_cs_ans
state.
Outgoing-Call-Requestを受信しました。 これが誤って受信された場合は、エラー条件を設定してOutgoing-Call-Replyで応答します。 それ以外の場合は、ダイヤルする物理チャネルを割り当てます。 アウトバウンドコールを発信し、接続を待機して、wait_cs_ans状態に移行します。
wait_cs_ans
wait_cs_ans
If the call is incomplete, send an Outgoing-Call-Reply with a
non-zero Error Code. If a timer expires on an outbound call, send
back an Outgoing-Call-Reply with a non-zero Error Code. If a
circuit switched connection is established, send an Outgoing-
Call-Reply indicating success.
呼び出しが不完全な場合は、ゼロ以外のエラーコードでOutgoing-Call-Replyを送信します。 アウトバウンドコールでタイマーが期限切れになった場合は、ゼロ以外のエラーコードでOutgoing-Call-Replyを送り返します。 回線交換接続が確立されている場合は、成功を示すOutgoing-Call-Replyを送信します。
established
設立
If a Call-Clear-Request is received, the telco call SHOULD be
released via appropriate mechanisms and a Call-Disconnect-Notify
message SHOULD BE sent to the PNS. If the call is disconnected by
the client or by the telco interface, a Call-Disconnect-Notify
message SHOULD be sent to the PNS.
Call-Clear-Requestを受信した場合、適切なメカニズムを介して電話会社のコールを解放し、Call-Disconnect-NotifyメッセージをPNSに送信する必要があります（SHOULD）。 コールがクライアントまたは電話会社のインターフェイスによって切断された場合、Call-Disconnect-NotifyメッセージをPNSに送信する必要があります（SHOULD）。
Hamzeh, et al. Informational [Page 45] RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999 3.2.4.2. PNS Outgoing Call States
3.2.4.2。 PNS発信コール状態
Open Indication Abort/Send
/Send Outgoing Call Call Clear
Request +-----------------+Request
+-------------------------------->| Wait-Reply |----------+
| +-----------------+ |
| Receive Outgoing Call Reply V V Receive Outgoing |
| with Error | | Call Reply |
| +-------------------------------+ | No Error |
^ V V |
+-----------------+ +-----------------+ |
| Idle |<-----------------------------| Established | |
+-----------------+ Receive Call Disconnect +-----------------+ |
^ Notify V Local Terminate |
| | /Send Call Clear |
| | Request |
| Receive Call Disconnect V |
| Notify +-----------------+ |
+---------------------------------| Wait-Disconnect |<---------+
+-----------------+
The states associated with the PNS for outgoing calls are:
発信コールのPNSに関連する状態は次のとおりです。
idle
アイドル
An Outgoing-Call-Request message is sent to the PAC and the
session moves into the wait_reply state.
Outgoing-Call-RequestメッセージがPACに送信され、セッションがwait_reply状態に移行します。
wait_reply
wait_reply
An Outgoing-Call-Reply is received which indicates an error. The
session returns to idle state. No telco call is active. If the
Outgoing-Call-Reply does not indicate an error, the telco call is
connected and the session moves to the established state.
エラーを示すOutgoing-Call-Replyが受信されます。 セッションはアイドル状態に戻ります。 Telcoコールはアクティブではありません。 Outgoing-Call-Replyがエラーを示さない場合、Telcoコールは接続され、セッションは確立された状態に移行します。
established
設立
If a Call-Disconnect-Notify is received, the telco call has been
terminated for the reason indicated in the Result and Cause Codes.
The session moves back to the idle state. If the PNS chooses to
terminate the session, it sends a Call-Clear-Request to the PAC
and then enters the wait_disconnect state.
Call-Disconnect-Notifyを受信した場合、結果コードと原因コードに示されている理由により、電話会社の通話は終了しています。 セッションはアイドル状態に戻ります。 PNSがセッションの終了を選択した場合、PNSはPACにCall-Clear-Requestを送信してから、wait_disconnect状態に入ります。
wait_disconnect
wait_disconnect
A session disconnection is waiting to be confirmed by the PAC.
Once the PNS receives the Call-Disconnect-Notify message, the
session enters idle state.
セッションの切断は、PACによる確認を待っています。 PNSがCall-Disconnect-Notifyメッセージを受信すると、セッションはアイドル状態になります。
Hamzeh, et al. Informational [Page 46] RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999 4. Tunnel Protocol Operation
4.トンネルプロトコルの動作
The user data carried by the PPTP protocol are PPP data packets. PPP packets are carried between the PAC and PNS, encapsulated in GRE packets which in turn are carried over IP. The encapsulated PPP packets are essentially PPP data packets less any media specific framing elements. No HDLC flags, bit insertion, control characters, or control character escapes are included. No CRCs are sent through the tunnel. The IP packets transmitted over the tunnels between a PAC and PNS has the following general structure:
PPTPプロトコルによって運ばれるユーザーデータは、PPPデータパケットです。 PPPパケットはPACとPNSの間で伝送され、GREパケットにカプセル化されて、IPで伝送されます。 カプセル化されたPPPパケットは、基本的にPPPデータパケットからメディア固有のフレーミングエレメントを差し引いたものです。 HDLCフラグ、ビット挿入、制御文字、または制御文字エスケープは含まれていません。 CRCはトンネルを介して送信されません。 PACとPNS間のトンネルを介して送信されるIPパケットの一般的な構造は次のとおりです。
+--------------------------------+
| Media Header |
+--------------------------------+
| IP Header |
+--------------------------------+
| GRE Header |
+--------------------------------+
| PPP Packet |
+--------------------------------+
4.1. Enhanced GRE header
4.1。 拡張GREヘッダー
The GRE header used in PPTP is enhanced slightly from that specified in the current GRE protocol specification [1,2]. The main difference involves the definition of a new Acknowledgment Number field, used to determine if a particular GRE packet or set of packets has arrived at the remote end of the tunnel. This Acknowledgment capability is not used in conjunction with any retransmission of user data packets. It is used instead to determine the rate at which user data packets are to be transmitted over the tunnel for a given user session. The format of the enhanced GRE header is as follows:
PPTPで使用されるGREヘッダーは、現在のGREプロトコル仕様[1、2]で指定されているものから少し拡張されています。 主な違いは、特定の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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Hamzeh, et al. Informational [Page 47]
RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
C
(Bit 0) Checksum Present. Set to zero (0).
（ビット0）チェックサムの存在。 ゼロ（0）に設定します。
R
(Bit 1) Routing Present. Set to zero (0).
（ビット1）ルーティングの存在。 ゼロ（0）に設定します。
K
(Bit 2) Key Present. Set to one (1).
（ビット2）キープレゼント。 1に設定します。
S
(Bit 3) Sequence Number Present. Set to one (1) if a payload
(data) packet is present. Set to zero (0) if payload is not
present (GRE packet is an Acknowledgment only).
（ビット3）シーケンス番号が存在します。 ペイロード（データ）パケットが存在する場合は、1に設定します。 ペイロードが存在しない場合は、ゼロ（0）に設定します（GREパケットは確認応答のみです）。
s
(Bit 4) Strict source route present. Set to zero (0).
（ビット4）厳密なソースルートが存在します。 ゼロ（0）に設定します。
Recur
(Bits 5-7) Recursion control. Set to zero (0).
（ビット5～7）再帰制御。 ゼロ（0）に設定します。
A
(Bit 8) Acknowledgment sequence number present. Set to one (1) if
packet contains Acknowledgment Number to be used for acknowledging
previously transmitted data.
（ビット8）確認シーケンス番号が存在します。 以前に送信されたデータを確認するために使用される確認番号がパケットに含まれている場合は、1に設定します。
Flags
(Bits 9-12) Must be set to zero (0).
（ビット9～12）ゼロ（0）に設定する必要があります。
Ver
(Bits 13-15) Must contain 1 (enhanced GRE).
（ビット13～15）1（拡張GRE）を含む必要があります。
Protocol Type
Set to hex 880B [8].
16進数の880Bに設定します[8]。
Key
Use of the Key field is up to the implementation. PPTP uses it as
follows:
Keyフィールドの使用は実装次第です。 PPTPは次のように使用します。
Payload Length
ペイロードの長さ
(High 2 octets of Key) Size of the payload, not including
the GRE header
（キーの高2オクテット）GREヘッダーを含まないペイロードのサイズ
Call ID
コールID
(Low 2 octets) Contains the Peer's Call ID for the session
to which this packet belongs.
（低2オクテット）このパケットが属するセッションのピアのコールIDが含まれます。
Sequence Number
シーケンス番号
Contains the sequence number of the payload. Present if S
bit (Bit 3) is one (1).
ペイロードのシーケンス番号が含まれます。 Sビット（ビット3）が1の場合に存在します。
Hamzeh, et al. Informational [Page 48]
RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
Acknowledgment Number
確認番号
Contains the sequence number of the highest numbered GRE
packet received by the sending peer for this user session.
Present if A bit (Bit 8) is one (1).
このユーザーセッションの送信ピアが受信した、最も大きい番号のGREパケットのシーケンス番号が含まれます。 Aビット（ビット8）が1の場合に存在します。
The payload section contains a PPP data packet without any
media specific framing elements.
ペイロードセクションには、メディア固有のフレーミング要素のないPPPデータパケットが含まれています。
The sequence numbers involved are per packet sequence numbers.
The sequence number for each user session is set to zero at
session startup. Each packet sent for a given user session
which contains a payload (and has the S bit (Bit 3) set to one)
is assigned the next consecutive sequence number for that
session.
関連するシーケンス番号は、パケットごとのシーケンス番号です。 各ユーザーセッションのシーケンス番号は、セッションの起動時にゼロに設定されます。 ペイロードを含む（Sビット（ビット3）が1に設定されている）ユーザーセッションに送信される各パケットには、そのセッションの次の連続したシーケンス番号が割り当てられます。
This protocol allows acknowledgments to be carried with the
data and makes the overall protocol more efficient, which in
turn requires less buffering of packets.
このプロトコルを使用すると、確認応答をデータとともに送信でき、プロトコル全体がより効率的になり、パケットのバッファリングが少なくて済みます。
4.2. Sliding Window Protocol
4.2。 スライディングウィンドウプロトコル
The sliding window protocol used on the PPTP data path is used for flow control by each side of the data exchange. The enhanced GRE protocol allows packet acknowledgments to be piggybacked on data packets. Acknowledgments can also be sent separately from data packets. Again, the main purpose of the sliding window protocol is for flow control--retransmissions are not performed by the tunnel peers.
PPTPデータパスで使用されるスライディングウィンドウプロトコルは、データ交換の両側でフロー制御に使用されます。 拡張GREプロトコルにより、パケット確認応答をデータパケットに便乗させることができます。 確認応答は、データパケットとは別に送信することもできます。 ここでも、スライディングウィンドウプロトコルの主な目的はフロー制御です。再送信はトンネルピアによって実行されません。
4.2.1. Initial Window Size
4.2.1。 初期ウィンドウサイズ
Although each side has indicated the maximum size of its receive window, it is recommended that a conservative approach be taken when beginning to transmit data. The initial window size on the transmitter is set to half the maximum size the receiver requested, with a minimum size of one packet. The transmitter stops sending packets when the number of packets awaiting acknowledgment is equal to the current window size. As the receiver successfully digests each window, the window size on the transmitter is bumped up by one packet until the maximum is reached. This method prevents a system from flooding an already congested network because no history has been established.
それぞれの側で受信ウィンドウの最大サイズが示されていますが、データの送信を開始するときには慎重なアプローチをとることをお勧めします。 トランスミッターの初期ウィンドウサイズは、レシーバーが要求した最大サイズの半分に設定され、最小サイズは1パケットです。 確認応答を待っているパケットの数が現在のウィンドウサイズと等しい場合、トランスミッタはパケットの送信を停止します。 受信側が各ウィンドウを正常にダイジェストすると、最大値に達するまで、送信側のウィンドウサイズが1パケットずつ増加します。 この方法は、履歴が確立されていないため、システムがすでに輻輳しているネットワークをフラッディングするのを防ぎます。
4.2.2. Closing the Window
4.2.2。 ウィンドウを閉じる
When a time-out does occur on a packet, the sender adjusts the size of the transmit window down to one half its value when it failed. Fractions are rounded up, and the minimum window size is one.
パケットでタイムアウトが発生すると、送信側は送信ウィンドウのサイズを、失敗したときの値の半分に調整します。 端数は切り上げられ、最小ウィンドウサイズは1です。
Hamzeh, et al. Informational [Page 49] RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999 4.2.3. Opening the Window
4.2.3。 ウィンドウを開く
With every successful transmission of a window's worth of packets without a time-out, the transmit window size is increased by one packet until it reaches the maximum window size that was sent by the other side when the call was connected. As stated earlier, no retransmission is done on a time-out. After a time-out, the transmission resumes with the window starting at one half the size of the transmit window when the time-out occurred and adjusting upward by one each time the transmit window is filled with packets that are all acknowledged without time-outs.
タイムアウトなしでウィンドウに相当するパケットが正常に送信されるたびに、通話が接続されたときに相手側から送信された最大ウィンドウサイズに達するまで、送信ウィンドウサイズが1パケットずつ増加します。 前述のように、タイムアウト時に再送信は行われません。 タイムアウト後、タイムアウトは送信ウィンドウの半分のサイズから始まり、送信ウィンドウがすべてタイムアウトなしで確認応答されるパケットで満たされるたびに1ずつ上方に調整されて、ウィンドウは送信を再開します。 。
4.2.4. Window Overflow
4.2.4。 ウィンドウオーバーフロー
When a receiver's window overflows with too many incoming packets, excess packets are thrown away. This situation should not arise if the sliding window procedures are being properly followed by the transmitter and receiver. It is assumed that, on the transmit side, packets are buffered for transmission and are no longer accepted from the packet source when the transmit buffer fills.
受信側のウィンドウが非常に多くの着信パケットでオーバーフローすると、過剰なパケットは破棄されます。 この状況は、スライディングウィンドウの手順が送信機と受信機によって適切に実行されている場合には発生しません。 送信側では、パケットは送信用にバッファリングされ、送信バッファがいっぱいになるとパケットソースから受け入れられなくなると想定されます。
4.2.5. Multi-packet Acknowledgment
4.2.5。 マルチパケットの確認
One feature of the PPTP sliding window protocol is that it allows the acknowledgment of multiple packets with a single acknowledgment. All outstanding packets with a sequence number lower or equal to the acknowledgment number are considered acknowledged. Time-out calculations are performed using the time the packet corresponding to the highest sequence number being acknowledged was transmitted.
PPTPスライディングウィンドウプロトコルの1つの機能は、単一の確認応答で複数のパケットの確認応答を可能にすることです。 シーケンス番号が確認番号以下のすべての未解決のパケットは確認済みと見なされます。 タイムアウトの計算は、確認されている最大のシーケンス番号に対応するパケットが送信された時間を使用して実行されます。
Adaptive time-out calculations are only performed when an Acknowledgment is received. When multi-packet acknowledgments are used, the overhead of the adaptive time-out algorithm is reduced. The PAC is not required to transmit multi-packet acknowledgments; it can instead acknowledge each packet individually as it is delivered to the PPP client.
アダプティブタイムアウト計算は、確認応答を受信したときにのみ実行されます。 マルチパケット確認応答を使用すると、適応タイムアウトアルゴリズムのオーバーヘッドが削減されます。 PACはマルチパケット確認応答を送信する必要はありません。 代わりに、PPPクライアントに配信されるときに各パケットを個別に確認することができます。
4.3. Out-of-sequence Packets
4.3。 順不同パケット
Occasionally packets lose their sequencing across a complicated internetwork. Say, for example that a PNS sends packets 0 to 5 to a PAC. Because of rerouting in the internetwork, packet 4 arrives at the PAC before packet 3. The PAC acknowledges packet 4, and may assume packet 3 is lost. This acknowledgment grants window credit beyond packet 4.
時折、パケットは複雑なインターネットワーク全体でシーケンスを失う。 たとえば、PNSがパケット0～5をPACに送信するとします。 インターネットワークでの再ルーティングのため、パケット4はパケット3の前にPACに到着します。 PACはパケット4を確認し、パケット3が失われたと想定する場合があります。 この確認応答により、パケット4を超えるウィンドウクレジットが付与されます。
Hamzeh, et al. Informational [Page 50] RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999 When the PAC does receive packet 3, it MUST not attempt to transmit it to the corresponding PPP client. To do so could cause problems, as proper PPP protocol operation is premised upon receiving packets in sequence. PPP does properly deal with the loss of packets, but not with reordering so out of sequence packets between the PNS and PAC MUST be silently discarded, or they may be reordered by the receiver. When packet 5 comes in, it is acknowledged by the PAC since it has a higher sequence number than 4, which was the last highest packet acknowledged by the PAC. Packets with duplicate sequence numbers should never occur since the PAC and PNS never retransmit GRE packets. A robust implementation will silently discard duplicate GRE packets, should it receive any.
PACがパケット3を受信する場合、対応するPPPクライアントへの送信を試みてはなりません。 適切なPPPプロトコルの動作は、パケットを順番に受信することを前提としているため、これを行うと問題が発生することがあります。 PPPはパケットの損失を適切に処理しますが、並べ替えは行いません。そのため、PNSとPACの間の順序が正しくないパケットは静かに破棄する必要があります。 パケット5が入ると、シーケンス番号が4よりも大きいため、PACによって確認されます。これは、PACによって確認された最後の最高のパケットでした。 PACとPNSはGREパケットを再送信しないため、シーケンス番号が重複するパケットは発生しません。 堅牢な実装は、重複するGREパケットを受信した場合、それを静かに破棄します。
4.4. Acknowledgment Time-Outs
4.4。 確認のタイムアウト
PPTP uses sliding windows and time-outs to provide both user session flow-control across the internetwork and to perform efficient data buffering to keep the PAC-PNS data channels full without causing receive buffer overflow. PPTP requires that a time-out be used to recover from dropped data or acknowledgment packets. The exact implementation of the time-out is vendor-specific. It is suggested that an adaptive time-out be implemented with backoff for congestion control. The time-out mechanism proposed here has the following properties:
PPTPは、スライディングウィンドウとタイムアウトを使用して、インターネットワーク全体でユーザーセッションフロー制御を提供し、効率的なデータバッファリングを実行して、受信バッファーのオーバーフローを引き起こさずにPAC-PNSデータチャネルをフルに保ちます。 PPTPでは、データドロップまたは確認応答パケットから回復するためにタイムアウトを使用する必要があります。 タイムアウトの正確な実装はベンダー固有です。 輻輳制御のバックオフを使用して、適応型タイムアウトを実装することをお勧めします。 ここで提案されているタイムアウトメカニズムには、次の特性があります。
Independent time-outs for each session. A device (PAC or PNS) will
have to maintain and calculate time-outs for every active session.
各セッションの独立したタイムアウト。 デバイス（PACまたはPNS）は、アクティブなセッションごとにタイムアウトを維持および計算する必要があります。
An administrator-adjustable maximum time-out, MaxTimeOut, unique
to each device.
各デバイスに固有の、管理者が調整可能な最大タイムアウトMaxTimeOut。
An adaptive time-out mechanism that compensates for changing
throughput. To reduce packet processing overhead, vendors may
choose not to recompute the adaptive time-out for every received
acknowledgment. The result of this overhead reduction is that the
time-out will not respond as quickly to rapid network changes.
スループットの変化を補正する適応タイムアウトメカニズム。 パケット処理のオーバーヘッドを削減するために、ベンダーは、受信したすべての確認応答に対して適応型タイムアウトを再計算しないことを選択する場合があります。 このオーバーヘッドの削減の結果、タイムアウトはネットワークの急激な変化に対応できなくなります。
Timer backoff on time-out to reduce congestion. The backed-off
timer value is limited by the configurable maximum time-out value.
Timer backoff is done every time an acknowledgment time-out
occurs.
タイムアウト時のタイマーバックオフにより、輻輳を軽減します。 バックオフタイマーの値は、構成可能な最大タイムアウト値によって制限されます。 タイマーのバックオフは、確認応答のタイムアウトが発生するたびに行われます。
In general, this mechanism has the desirable behavior of quickly backing off upon a time-out and of slowly decreasing the time-out value as packets are delivered without time-outs.
一般に、このメカニズムには、タイムアウト時に迅速にバックオフし、タイムアウトなしでパケットが配信されるときにタイムアウト値をゆっくりと減少させるという望ましい動作があります。
Hamzeh, et al. Informational [Page 51] RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999 Some definitions:
いくつかの定義：
Packet Processing Delay (PPD) is the amount of time required for
each side to process the maximum amount of data buffered in their
receive packet sliding window. The PPD is the value exchanged
between the PAC and PNS when a call is established. For the PNS,
this number should be small. For a PAC making modem connections,
this number could be significant.
パケット処理遅延（PPD）は、各サイドが受信パケットのスライディングウィンドウにバッファリングされた最大量のデータを処理するために必要な時間です。 PPDは、コールが確立されたときにPACとPNSの間で交換される値です。 PNSの場合、この数は小さくする必要があります。 モデム接続を行うPACの場合、この数は重要になる可能性があります。
Sample is the actual amount of time incurred receiving an
acknowledgment for a packet. The Sample is measured, not
calculated.
サンプルは、パケットの確認応答の受信にかかった実際の時間です。 サンプルは計算ではなく測定されます。
Round-Trip Time (RTT) is the estimated round-trip time for an
Acknowledgment to be received for a given transmitted packet. When
the network link is a local network, this delay will be minimal
(if not zero). When the network link is the Internet, this delay
could be substantial and vary widely. RTT is adaptive: it will
adjust to include the PPD and whatever shifting network delays
contribute to the time between a packet being transmitted and
receiving its acknowledgment.
Round-Trip Time（RTT）は、特定の送信パケットに対して受信確認が受信されるまでの推定往復時間です。 ネットワークリンクがローカルネットワークの場合、この遅延は最小限になります（ゼロではない場合）。 ネットワークリンクがインターネットの場合、この遅延はかなり大きく、大きく異なる可能性があります。 RTTはアダプティブです。PPDを含めるように調整され、パケットの転送とその確認応答の受信との間の時間に寄与するシフトするネットワーク遅延があれば、それに応じます。
Adaptive Time-Out (ATO) is the time that must elapse before an
acknowledgment is considered lost. After a time-out, the sliding
window is partially closed and the ATO is backed off.
アダプティブタイムアウト（ATO）は、確認応答が失われたと見なされるまでに経過する必要がある時間です。 タイムアウト後、スライディングウィンドウが部分的に閉じられ、ATOがバックオフされます。
The Packet Processing Delay (PPD) parameter is a 16-bit word exchanged during the Call Control phase that represents tenths of a second (64 means 6.4 seconds). The protocol only specifies that the parameter is exchanged, it does not specify how it is calculated. The way values for PPD are calculated is implementation-dependent and need not be variable (static time-outs are allowed). The PPD must be exchanged in the call connect sequences, even if it remains constant in an implementation. One possible way to calculate the PPD is:
パケット処理遅延（PPD）パラメータは、10分の1秒（64は6.4秒）を表す、コール制御フェーズ中に交換される16ビットワードです。 プロトコルは、パラメータの交換を指定するだけで、計算方法は指定しません。 PPDの値の計算方法は実装に依存し、可変である必要はありません（静的タイムアウトが許可されます）。 PPDは、実装で一定のままであっても、コール接続シーケンスで交換する必要があります。 PPDを計算する1つの可能な方法は次のとおりです。
PPD' = ((PPP_MAX_DATA_MTU - Header) * WindowSize * 8) / ConnectRate PPD = PPD' + PACFudge Header is the total size of the IP and GRE headers, which is 36. The MTU is the overall MTU for the internetwork link between the PAC and PNS. WindowSize represents the number of packets in the sliding window, and is implementation-dependent. The latency of the internetwork could be used to pick a window size sufficient to keep the current session's pipe full. The constant 8 converts octets to bits (assuming ConnectRate is in bits per second). If ConnectRate is in bytes per second, omit the 8. PACFudge is not required but can be used to take overall processing overhead of the PAC into account.
ヘッダーは、IPヘッダーとGREヘッダーの合計サイズで、36です。 MTUは、PACとPNS間のインターネットワークリンクの全体的なMTUです。 WindowSizeは、スライディングウィンドウ内のパケット数を表し、実装によって異なります。 インターネットワークの待ち時間を使用して、現在のセッションのパイプをいっぱいに保つのに十分なウィンドウサイズを選択できます。 定数8はオクテットをビットに変換します（ConnectRateがビット/秒であると想定）。 ConnectRateがバイト/秒の場合は、8を省略します。 PACFudgeは必須ではありませんが、PACの全体的な処理オーバーヘッドを考慮するために使用できます。
Hamzeh, et al. Informational [Page 52] RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999 The value of PPD is used to seed the adaptive algorithm with the initial RTT[n-1] value.
PPDの値は、適応アルゴリズムに初期RTT [n-1]値をシードするために使用されます。
4.4.1. Calculating Adaptive Acknowledgment Time-Out
4.4.1。 アダプティブ確認応答タイムアウトの計算
We still must decide how much time to allow for acknowledgments to return. If the time-out is set too high, we may wait an unnecessarily long time for dropped packets. If the time-out is too short, we may time out just before the acknowledgment arrives. The acknowledgment time-out should also be reasonable and responsive to changing network conditions.
確認が戻るまでの時間を決定する必要があります。 タイムアウトの設定が高すぎると、パケットがドロップされるまで不必要に長い時間待機する可能性があります。 タイムアウトが短すぎると、確認が届く直前にタイムアウトする可能性があります。 確認応答のタイムアウトも合理的であり、変化するネットワーク状態に対応する必要があります。
The suggested adaptive algorithm detailed below is based on the TCP 1989 implementation and is explained in [11]. 'n' means this iteration of the calculation, and 'n-1' refers to values from the last calculation.
以下に詳述する適応アルゴリズムは、TCP 1989実装に基づいており、[11]で説明されています。 「n」はこの計算の反復を意味し、「n-1」は最後の計算からの値を指します。
DIFF[n] = SAMPLE[n] - RTT[n-1]
DEV[n] = DEV[n-1] + (beta * (|DIFF[n]| - DEV[n-1]))
RTT[n] = RTT[n-1] + (alpha * DIFF[n])
ATO[n] = MAX (MinTimeOut, MIN (RTT[n] +
(chi * DEV[n]), MaxTimeOut))
DIFF represents the error between the last estimated round-trip
time and the measured time. DIFF is calculated on each iteration.
DIFFは、最後の推定往復時間と測定時間の間の誤差を表します。 DIFFは各反復で計算されます。
DEV is the estimated mean deviation. This approximates the
standard deviation. DEV is calculated on each iteration and
stored for use in the next iteration. Initially, it is set to 0.
DEVは推定平均偏差です。 これは、標準偏差を近似します。 DEVは各反復で計算され、次の反復で使用するために保存されます。 最初は0に設定されています。
RTT is the estimated round-trip time of an average packet. RTT is
ycalculated on each iteration and stored for use in the next
iteration. Initially, it is set to PPD.
RTTは、平均パケットの推定往復時間です。 RTTは各反復でy計算され、次の反復で使用するために保存されます。 最初は、PPDに設定されています。
ATO is the adaptive time-out for the next transmitted packet. ATO
is calculated on each iteration. Its value is limited, by the MIN
function, to be a maximum of the configured MaxTimeOut value.
ATOは、次に送信されるパケットの適応タイムアウトです。 ATOは各反復で計算されます。 その値は、MIN関数によって、構成されたMaxTimeOut値の最大値に制限されます。
Alpha is the gain for the average and is typically 1/8 (0.125).
アルファは平均のゲインで、通常は1/8（0.125）です。
Beta is the gain for the deviation and is typically 1/4 (0.250).
ベータは偏差のゲインで、通常は1/4（0.250）です。
Chi is the gain for the time-out and is typically set to 4.
Chiはタイムアウトのゲインであり、通常は4に設定されています。
Hamzeh, et al. Informational [Page 53] RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999 To eliminate division operations for fractional gain elements, the entire set of equations can be scaled. With the suggested gain constants, they should be scaled by 8 to eliminate all division. To simplify calculations, all gain values are kept to powers of two so that shift operations can be used in place of multiplication or division.
フラクショナルゲイン要素の除算演算を排除するために、方程式のセット全体をスケーリングできます。 推奨されるゲイン定数を使用して、すべての除算を排除するために、それらを8でスケーリングする必要があります。 計算を簡略化するために、すべてのゲイン値は2の累乗に保たれるため、乗算または除算の代わりにシフト演算を使用できます。
4.4.2. Congestion Control: Adjusting for Time-Out
4.4.2。 輻輳制御：タイムアウトの調整
This section describes how the calculation of ATO is modified in the case where a time-out does occur. When a time-out occurs, the time- out value should be adjusted rapidly upward. Although the GRE packets are not retransmitted when a time-out occurs, the time-out should be adjusted up toward a maximum limit. To compensate for shifting internetwork time delays, a strategy must be employed to increase the time-out when it expires (notice that in addition to increasing the time-out, we are also shrinking the size of the window as described in the next section). For an interval in which a time- out occurs, the new ATO is calculated as:
このセクションでは、タイムアウトが発生した場合のATOの計算の変更方法について説明します。 タイムアウトが発生した場合、タイムアウト値を急速に上方に調整する必要があります。 タイムアウトが発生してもGREパケットは再送信されませんが、タイムアウトは最大制限に向かって調整する必要があります。 インターネットワークの遅延時間のシフトを補正するには、タイムアウトが発生したときにタイムアウトを長くする戦略を採用する必要があります（タイムアウトの増加に加えて、次のセクションで説明するようにウィンドウのサイズも縮小していることに注意してください）。 。 タイムアウトが発生する間隔の場合、新しいATOは次のように計算されます。
RTT[n] = delta * RTT[n-1]
DEV[n] = DEV[n-1]
ATO[n] = MAX (MinTimeOut, MIN (RTT[n] +
(chi * DEV[n]), MaxTimeOut))
In this calculation of ATO, only the two values that both contribute
to ATO and are stored for the next iteration are calculated. RTT is
scaled by delta, and DEV is unmodified. DIFF is not carried forward
and is not used in this scenario. A value of 2 for Delta, the time-
out gain factor for RTT, is suggested.
このATOの計算では、ATOに寄与し、次の反復のために格納される2つの値のみが計算されます。 RTTはデルタによってスケーリングされ、DEVは変更されません。 DIFFは繰り越されず、このシナリオでは使用されません。 RTTのタイムアウトゲイン係数であるDeltaには2の値が推奨されます。
5. Security Considerations
5.セキュリティに関する考慮事項
The security of user data passed over the tunneled PPP connection is addressed by PPP, as is authentication of the PPP peers.
トンネルPPP接続を介して渡されるユーザーデータのセキュリティは、PPPピアの認証と同様に、PPPによって対処されます。
Because the PPTP control channel messages are neither authenticated nor integrity protected, it might be possible for an attacker to hijack the underlying TCP connection. It is also possible to manufacture false control channel messages and alter genuine messages in transit without detection.
PPTPコントロールチャネルメッセージは認証も完全性も保護されていないため、攻撃者が基になるTCP接続をハイジャックする可能性があります。 また、偽の制御チャネルメッセージを製造し、検出されずに送信中の本物のメッセージを変更することもできます。
The GRE packets forming the tunnel itself are not cryptographically protected. Because the PPP negotiations are carried out over the tunnel, it may be possible for an attacker to eavesdrop on and modify those negotiations.
トンネル自体を形成するGREパケットは、暗号的に保護されていません。 PPPネゴシエーションはトンネルを介して実行されるため、攻撃者がこれらのネゴシエーションを傍受して変更する可能性があります。
Hamzeh, et al. Informational [Page 54] RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999 Unless the PPP payload data is cryptographically protected, it can be captured and read or modified.
PPPペイロードデータが暗号で保護されていない限り、キャプチャして読み取りまたは変更できます。
6. Authors' Addresses
6.著者のアドレス
Kory Hamzeh Ascend Communications 1275 Harbor Bay Parkway Alameda, CA 94502 EMail: kory@ascend.com Gurdeep Singh Pall Microsoft Corporation Redmond, WA EMail: gurdeep@microsoft.com William Verthein U.S. Robotics/3Com Jeff Taarud Copper Mountain Networks W. Andrew Little ECI Telematics Glen Zorn Microsoft Corporation Redmond, WA EMail: glennz@microsoft.com Hamzeh, et al. Informational [Page 55] RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999 7. References
7.リファレンス
[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.
Hamzeh, et al. Informational [Page 56]
RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
8. Full Copyright Statement
8.完全な著作権表示
Copyright (C) The Internet Society (1999). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Hamzeh, et al. Informational [Page 57]