RFC2637 日本語訳
2637 Point-to-Point Tunneling Protocol (PPTP). K. Hamzeh, G. Pall, W.Verthein, J. Taarud, W. Little, G. Zorn. July 1999. (Format: TXT=132565 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
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
Hamzehがコメントのために要求するワーキンググループK.をネットワークでつないでください: 2637はコミュニケーションカテゴリを昇ります: 情報のG.のECIテレマティックスG.ゾルンマイクロソフト社祭服マイクロソフト社W.Verthein 3Com J.Taarudカッパーマウンテンネットワークw.リトル1999年7月
Point-to-Point Tunneling Protocol (PPTP)
二地点間トンネリングプロトコル(PPTP)
Status of this Memo
この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)インターネット協会(1999)。 All rights reserved。
IESG Note
IESG注意
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-
このドキュメントはPointプロトコル(PPP)へのPointがIPネットワークを通してトンネルを堀るプロトコルを指定します。 PPTPはPPPプロトコルへの少しの変化も指定しませんが、むしろPPPを運ぶための新車について説明します。 クライアント/サーバ構造は、現在のNetwork Access Servers(NAS)に存在する機能の衝撃を吸収して、Virtual兵士のNetworks(VPNs)を支持するために定義されます。 PPTP Network Server(PNS)はクライアントである間、汎用のオペレーティングシステムで動くために思い描かれます、PPTP Access Concentrator(PAC)がダイヤルアクセスプラットホームを作動させるのに言及されて。 PPTPはサーバがPSTNかISDNから発するダイヤルインのサーキット切り換えられた呼び出しのためのアクセスを制御するか、または外国行きのサーキットを開始する呼び出しコントロールと管理プロトコルを、指定します。
Hamzeh, et al. Informational [Page 1] RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
Hamzeh、他 1999年7月にプロトコル(PPTP)にトンネルを堀る情報[1ページ]のRFC2637ポイントツーポイント
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.
接続を切り換えました。 PPTPは、PPPパケットを運ぶための流れと混雑で制御された要約のデータグラムサービスを供給するのに高められたGRE(一般的なルート設定Encapsulation)メカニズムを使用します。
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].
そして、このドキュメント、「5月」というキーワードで「必須、「必須NOT」、「任意」の、そして、「お勧め」の“SHOULD"、「」、[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
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を制御してください。 コントロール接続要求を始めている.102.2。 スタートコントロール接続回答.122.3。 コントロール接続要求が止まっている.152.4。 停止コントロール接続回答.162.5。 エコー要求. . . . . . . . . . . . . . . . . . . . . . . 17 2.6。 エコー・リプライ. . . . . . . . . . . . . . . . . . . . . . . . 18 2.7。 送信する発呼要求.192.8。 外向的な呼び出し回答.222.9。 入って来る発呼要求.25 2.10。 入って来る呼び出し回答.28 2.11。 入って来る接続完了.29 2.12。 呼び出しの明確な要求.31 2.13。 呼び出し分離に通知している.32 2.14。 青白い誤りに通知している.33 2.15。 セットリンクインフォメーション.35 2.16。 一般誤りは.363をコード化します。 接続プロトコル操作. . . . . . . . . . . 36 3.1を制御してください。 コントロール接続は.1に.373.1を述べます。 Connection Originator(PACかPNSであるかもしれません).373.1.2を制御してください。 接続Receiver(PACかPNSであるかもしれない).39を制御してください。
Hamzeh, et al. Informational [Page 2] RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
Hamzeh、他 1999年7月にプロトコル(PPTP)にトンネルを堀る情報[2ページ]のRFC2637ポイントツーポイント
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
3.1.3. コントロール接続開始要求衝突. 40 3.1.4を始めてください。 アリフとタイマ. . . . . . . . . . . . . . . . . 40 3.2を保ってください。 呼び出し状態. . . . . . . . . . . . . . . . . . . . . . . 41 3.2.1。 問題. . . . . . . . . . . . . . . . . 41 3.2.2を調節します。 .3にID値. . . . . . . . . . . . . . . . . . . . . 41 3.2に電話をしてください。 入来は、.1に.413.2に.3人に電話をします。 PAC入って来る呼び出し状態. . . . . . . . . . . . . . . 42 3.2.3.2。 PNSの入って来る呼び出し状態. . . . . . . . . . . . . . . 43 3.2.4。 外向的である、.4に.1に.443.2人に電話をします。 PAC出発している呼び出し状態. . . . . . . . . . . . . . . 45 3.2.4.2。 PNS発信電話は.464を述べます。 プロトコル操作. . . . . . . . . . . . . . . . . 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は、クライアント/サーバ構造を使用することで既存のNetwork Access Server(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はレート適応を実行するかもしれません、A/D変換、async変換かデータ・ストリームの他の多くの変更への同時性。
Hamzeh, et al. Informational [Page 3] RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
Hamzeh、他 1999年7月にプロトコル(PPTP)にトンネルを堀る情報[3ページ]のRFC2637ポイントツーポイント
2) Logical termination of a Point-to-Point-Protocol (PPP) Link
Control Protocol (LCP) session.
2) Pointからポイントプロトコル(PPP)の論理的な終了 Controlプロトコル(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 Multilinkプロトコルのためのチャンネル集合とバンドル管理。
5) Logical termination of various PPP network control protocols
(NCP).
5) 様々なPPPネットワーク制御プロトコル(NCP)の論理的な終了。
6) Multiprotocol routing and bridging between NAS interfaces.
6) Multiprotocolルーティングと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プロトコルデータ単位(PDUs)、および呼び出しコントロールを運びました、そして、管理は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から役立たれている限り、彼らが異なったPACsにダイヤルするとき、ダイヤルインのユーザはただ一つの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の後ろでネットワークをネットワークでつなぎます。 これは、例えばIPだけプロバイダーを通してトンネルを堀られるためにAppletalkとIPXを許容します。 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で分類されるのを必要とします。 独身のPNSがマルチリンクPPPバンドルを扱うことができるので、バンドルを包括するチャンネルは複数のPACsの向こう側に広げられるかもしれません。
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
Hamzeh、他 1999年7月にプロトコル(PPTP)にトンネルを堀る情報[4ページ]のRFC2637ポイントツーポイント
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.
また、IPネットワークの上のPPPセッションにトンネルを堀るのにPPTPを使用できます。 この構成では、PPTPはトンネルを堀ります、そして、訪問者がPNSとして務めていて、PPPセッションは同じ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.
それは思い描かれます。PACsとPNSsの間には、多対多の関係があるでしょう。 PACは多くのPNSsに対するサービスを提供するかもしれません。 例えば、インターネット接続サービス業者は、多くの個人的なネットワーククライアントのためにPPTPを支持して、彼らのためにVPNsを作成するのを選ぶかもしれません。 それぞれの私設のネットワークは1PNSsを運用するかもしれません。 独身のPNSは、多くの地理的に多様なサイトからの交通を集結するために多くのPACsと交際するかもしれません。
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は、ユーザPPPパケットを運ぶのにGREの拡張版を使用します。 これらの増進は、低レベルである混雑とフロー制御がPACとPNSの間まで利用者データを運ぶのに使用されるトンネルの上で提供されるのを許容します。 このメカニズムは、トンネルに利用可能な帯域幅の効率的な使用を考慮して、不要なretransmisionsとバッファ超過を避けます。 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.1Khzオーディオを各方向に運ぶことを意図するサーキットで切り換えられた通信路。
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
Hamzeh、他 1999年7月にプロトコル(PPTP)にトンネルを堀る情報[5ページ]のRFC2637ポイントツーポイント
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操作と取り扱いができる1PSTNかISDN線にPPTPプロトコルを付けました。 PACは、1PNSsに交通を通り過ぎるために道具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に付けられている各ユーザのために状態を維持します。 終わりから終わりとのPPP接続がダイヤルユーザとPNSの間で試みられるとき、セッションは作成されます。 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) 同じPAC-PNSの間のTCPの上の組操作とIPトンネル操作あたり2が)対にする各PAC-PNSの間のGREを輸送するのに使用されるControl Connectionは組の間のユーザセッションのためにPPPパケットをカプセルに入れりました。
Hamzeh, et al. Informational [Page 6] RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
Hamzeh、他 1999年7月にプロトコル(PPTP)にトンネルを堀る情報[6ページ]のRFC2637ポイントツーポイント
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.
PPPトンネリングがPACとPNSの間に起こることができる前に、彼らの間でコントロール接続を確立しなければなりません。 コントロール接続はPPTPがコントロールと呼ぶ標準のTCPセッションです、そして、経営情報は通過されます。 コントロールセッションと、しかし、セッションにPPTPトンネルを通ってトンネルを堀られて、別々の状態で論理的に交際します。 それぞれのPAC-PNS組のために、トンネルとコントロール接続の両方がいます。 コントロール接続はトンネルを通って運ばれたセッションの設立、管理、およびリリースに責任があります。 それはPNSが関連PACでかかってきた電話について通知される手段です、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-コントロール接続要求と応答メッセージを使用することでコントロール接続を確立します。 また、これらのメッセージは、PACとPNSの基本的な操作能力に関して情報交換するのに使用されます。 コントロール接続がいったん確立されると、PACかPNSが、外国行きの呼び出しを要求するか、または本国行きの要求に応じることによって、セッションを開始するかもしれません。 コントロール接続はSetリンクインフォメーションメッセージとの個々のユーザセッションの操作の特性における変化を伝えるかもしれません。 個々のセッションはControl Connectionメッセージを通しても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.
コントロール接続に関しても青白い誤りに通知しているメッセージ。
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
Hamzeh、他 1999年7月にプロトコル(PPTP)にトンネルを堀る情報[7ページ]のRFC2637ポイントツーポイント
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はTCPデータとしてPNSと与えられたPACとのコントロール接続に送られた1セットのメッセージを定義します。 コントロール接続のためのTCPセッションは、1723[6]を移植するためにTCP接続を開始することによって、確立されます。 ソース港はどんな未使用のポートナンバーにも割り当てられます。
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 Control Connectionメッセージは8の八重奏の固定ヘッダー部分で始まります。 この固定ヘッダーは以下を含んでいます: メッセージ、PPTP Message Typeインディケータの全長、および「魔法クッキー。」
Two Control Connection message types are indicated by the PPTP Message Type field:
2つのControl ConnectionメッセージタイプがPPTP Message Type分野によって示されます:
1 - Control Message
2 - Management Message
1--コントロールメッセージ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.
一定の0x1A2B3C4DとしていつもマジックCookieを送ります。 基本的な目的は受信機が、それが適切に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.
明快ために、次のセクションのすべてのControl Connectionメッセージテンプレートが全体のPPTP Control Connectionメッセージヘッダーを含んでいます。 0xによって先行された数は16進値です。
Hamzeh, et al. Informational [Page 8] RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
Hamzeh、他 1999年7月にプロトコル(PPTP)にトンネルを堀る情報[8ページ]のRFC2637ポイントツーポイント
The currently defined Control Messages, grouped by function, are:
機能によって分類された現在定義されたControl Messagesは以下の通りです。
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
1つのコントロール接続要求を始めているスタートコントロール接続回答の2コントロール接続要求が止まっている3停止コントロール接続回答4エコー要求5エコー・リプライ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
送信する発呼要求7外向的な呼び出し回答8入って来る発呼要求9入って来る呼び出し回答10入って来る接続完了11呼び出しの明確な要求分離が通知する12呼び出し13
(Error Reporting)
(誤り報告)
WAN-Error-Notify 14
青白い誤りに通知している14
(PPP Session Control)
(pppセッション制御)
Set-Link-Info 15
セットリンクインフォメーション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プロトコルのどのバージョンが使用されるかを決定します。 これらのメッセージで運ばれたバージョンナンバーフィールドは高い八重奏におけるバージョン番号と低い八重奏における改訂番号から成ります。 バージョン取り扱いはセクション2で説明されます。 バージョンナンバーフィールドの現行価値はバージョン1、改正0のための0×0100です。
The use of the GRE-like header for the encapsulation of PPP user packets is specified in section 4.1.
GREのようなヘッダーのPPPユーザパケットのカプセル化の使用はセクション4.1で指定されます。
The MTU for the user data packets encapsulated in GRE is 1532 octets, not including the IP and GRE headers.
GREでカプセルに入れられたユーザデータ・パケットのためのMTUはIPとGREヘッダーを含んでいるのではなく、1532の八重奏です。
Hamzeh, et al. Informational [Page 9] RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
Hamzeh、他 1999年7月にプロトコル(PPTP)にトンネルを堀る情報[9ページ]のRFC2637ポイントツーポイント
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.
コントロールConnectionメッセージは、ユーザセッションを確立して、クリアするのに使用されます。 Control Connectionメッセージの第一セットは、コントロール接続自体を維持するのに使用されます。 彼らが基本的な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接続に関する利用者データが対にされるとき、以下のControl Connectionメッセージをすべて送ります。 すべての単語(2八重奏)とロングワード(4八重奏)値が適切な境界で始まるのを保証するために注意したことに注意してください。 ネットワークオーダーですべてのデータを送ります(高値は最初に、八重奏を命令します)。 プロトコル伸展性を考慮するために0つの値としてどんな「予約された」野原も送らなければなりません。
2.1. Start-Control-Connection-Request
2.1. コントロール接続要求を始めてください。
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コントロール接続要求はPNSとPACとのコントロール接続を証明するのに使用されるPPTPコントロールメッセージです。 それぞれのPNS-PAC組は、ひたむきなコントロール接続が確立されるのを必要とします。 いかなる他のPPTPメッセージも発行できる前にコントロール接続を確立しなければなりません。 PNSかPACのどちらかがコントロール接続の設立を開始できます。 PNSの間の衝突の発生を扱う手順と接続が要求するPAC Startコントロールはセクション3.1.3で説明されます。
Hamzeh, et al. Informational [Page 10] RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
Hamzeh、他 1999年7月にプロトコル(PPTP)にトンネルを堀る情報[10ページ]のRFC2637ポイントツーポイント
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) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 長さ| PPTPメッセージタイプ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 魔法クッキー| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | コントロールメッセージタイプ| Reserved0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | プロトコルバージョン| Reserved1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 縁どり能力| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 運搬人能力| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 最大のチャンネル| ファームウェア改正| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + ホストName(64の八重奏)+| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + ベンダーString(64の八重奏)+| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Length Total length in octets of this PPTP
message, including the entire PPTP
header.
全体のPPTPヘッダーを含むこのPPTPメッセージの八重奏における長さのTotalの長さ。
PPTP Message Type 1 for Control Message.
コントロールメッセージのためのPPTPメッセージタイプ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.
スタートコントロール接続要求のためのメッセージタイプ1を監督してください。
Reserved0 This field MUST be 0.
Reserved0 This分野は0であるに違いありません。
Protocol Version The version of the PPTP protocol that the
sender wishes to use.
バージョンについて議定書の中で述べてください。送付者が使用したがっているPPTPプロトコルのバージョン。
Reserved1 This field MUST be 0.
Reserved1 This分野は0であるに違いありません。
Hamzeh, et al. Informational [Page 11] RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
Hamzeh、他 1999年7月にプロトコル(PPTP)にトンネルを堀る情報[11ページ]のRFC2637ポイントツーポイント
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:
Aが設定したそれを縁どるタイプを示すビットのCapabilitiesを縁どっていて、このメッセージの送付者は提供できます。 現在定義された噛み付いている設定は以下の通りです。
1 - Asynchronous Framing supported
1--サポートされた非同期なFraming
2 - Synchronous Framing supported
2--サポートされた同期Framing
Bearer Capabilities A set of bits indicating the bearer
capabilities that the sender of this message
can provide. The currently defined bit
settings are:
Aが設定したこのメッセージの送付者が提供できる運搬人能力を示すビットの運搬人Capabilities。 現在定義された噛み付いている設定は以下の通りです。
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セッションの最大のChannels。 PNS、この値によって出された接続要求を制御しているStart SHOULDでは、0に設定されてください。 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.
ファームウェアRevision This分野はPAC、またはPNS PPTPドライバーのバージョンで発行されましたが、PNSによって発行されたいつという発行しているPACのファームウェア改訂番号を含んでいるか。
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.
DNS名(発行PACかPNS)を含むName A64八重奏分野を接待してください。 長さにおける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ソフトウェアのタイプについて説明するベンダーの特定のストリングを含むベンダーName A64八重奏分野。 長さにおける64未満の八重奏であるなら、この残りは価値0の八重奏で満たされた状態でSHOULDをさばきます。
2.2. Start-Control-Connection-Reply
2.2. スタートコントロール接続回答
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コントロール接続回答は受信されたStartコントロール接続要求メッセージに対して送られたPPTPコントロールメッセージです。 このメッセージはコントロールコネクション確立試みの結果を示す結果コードを含んでいます。
Hamzeh, et al. Informational [Page 12] RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
Hamzeh、他 1999年7月にプロトコル(PPTP)にトンネルを堀る情報[12ページ]のRFC2637ポイントツーポイント
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) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 長さ| PPTPメッセージタイプ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 魔法クッキー| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | コントロールメッセージタイプ| Reserved0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | プロトコルバージョン| 結果コード| エラーコード| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 縁どり能力| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 運搬人能力| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 最大のチャンネル| ファームウェア改正| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + ホストName(64の八重奏)+| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + ベンダーString(64の八重奏)+| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Length Total length in octets of this PPTP message,
including the entire PPTP header.
全体のPPTPヘッダーを含むこのPPTPメッセージの八重奏における長さのTotalの長さ。
PPTP Message Type 1 for Control Message.
コントロールメッセージのためのPPTPメッセージタイプ1。
Magic Cookie 0x1A2B3C4D.
魔法クッキー0x1A2B3C4D。
Control Message Type 2 for Start-Control-Connection-Reply.
スタートコントロール接続回答のためのメッセージタイプ2を監督してください。
Reserved0 This field MUST be 0.
Reserved0 This分野は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:
指揮系統設立の結果が試みる結果Code Indicates。 現在の有効なResult Code値は以下の通りです。
1 - Successful channel establishment
1--うまくいっているチャンネル設立
2 - General error -- Error Code
indicates the problem
2--一般誤り--誤りCodeは問題を示します。
Hamzeh, et al. Informational [Page 13] RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
Hamzeh、他 1999年7月にプロトコル(PPTP)にトンネルを堀る情報[13ページ]のRFC2637ポイントツーポイント
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.
「一般的なエラー」が存在していない場合、Code Thisがさばく誤りは0に設定されます、そして、その場合、Result Codeは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:
Aが設定したそれを縁どるタイプを示すビットのCapabilitiesを縁どっていて、このメッセージの送付者は提供できます。 現在定義された噛み付いている設定は以下の通りです。
1 - Asynchronous Framing supported
1--サポートされた非同期なFraming
2 - Synchronous Framing supported.
2--サポートされた同期Framing。
Bearer Capabilities A set of bits indicating the bearer
capabilities that the sender of this message
can provide. The currently defined bit
settings are:
Aが設定したこのメッセージの送付者が提供できる運搬人能力を示すビットの運搬人Capabilities。 現在定義された噛み付いている設定は以下の通りです。
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セッションの最大のChannels。 PACが0とそれへのセットを無視しなければならないというPNS、この値によって発行された接続回答を制御しているStart SHOULDではことになってください。 PNS MUST NOTは、PACが許容するPPPセッションの残っている数を追跡しようとするためにこの値を使用します。
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.
PNSによって発行されるなら、ファームウェアRevision This分野は発行しているPACのファームウェア改訂番号、またはPNS PPTPドライバーのバージョンを含んでいます。
Hamzeh, et al. Informational [Page 14] RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
Hamzeh、他 1999年7月にプロトコル(PPTP)にトンネルを堀る情報[14ページ]のRFC2637ポイントツーポイント
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.
DNS名(発行PACかPNS)を含むName A64八重奏分野を接待してください。 長さにおける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ソフトウェアのタイプについて説明するベンダーの特定のストリングを含むベンダーName A64八重奏分野。 長さにおける64未満の八重奏であるなら、この残りは価値0の八重奏で満たされた状態でSHOULDをさばきます。
2.3. Stop-Control-Connection-Request
2.3. コントロール接続要求を止めてください。
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コントロール接続要求はコントロール接続が閉店するべきであることをもう片方の同輩に知らせるためにPAC-PNSコントロール接続の1人の同輩によって送られたPPTPコントロールメッセージです。 コントロール接続を終えることに加えて、すべての活発なユーザ呼び出しがそれとなくクリアされます。 この要求を出す理由はReason分野で示されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | PPTP Message Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Magic Cookie |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Control Message Type | Reserved0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reason | Reserved1 | Reserved2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 長さ| PPTPメッセージタイプ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 魔法クッキー| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | コントロールメッセージタイプ| Reserved0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 理由| Reserved1| Reserved2| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Length Total length in octets of this PPTP message,
including the entire PPTP header.
全体のPPTPヘッダーを含むこのPPTPメッセージの八重奏における長さのTotalの長さ。
PPTP Message Type 1 for Control Message.
コントロールメッセージのためのPPTPメッセージタイプ1。
Magic Cookie 0x1A2B3C4D.
魔法クッキー0x1A2B3C4D。
Control Message Type 3 for Stop-Control-Connection-Request.
停止コントロール接続要求のためのメッセージタイプ3を監督してください。
Reserved0 This field MUST be 0.
Reserved0 This分野は0であるに違いありません。
Reason Indicates the reason for the control
connection being closed. Current valid
Reason values are:
コントロール接続存在の理由が閉じたIndicatesを推論してください。 現在の有効なReason値は以下の通りです。
Hamzeh, et al. Informational [Page 15] RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
Hamzeh、他 1999年7月にプロトコル(PPTP)にトンネルを堀る情報[15ページ]のRFC2637ポイントツーポイント
1 (None) - General request to clear
control connection
1(なにも)--コントロール接続をきれいにするという一般要求
2 (Stop-Protocol) - Can't support
peer's version of the protocol
2 (停止プロトコル)--同輩のプロトコルのバージョンをサポートすることができません。
3 (Stop-Local-Shutdown) - Requester is
being shut down
3(地方の閉鎖を止める)--リクエスタは止められています。
Reserved1, Reserved2 These fields MUST be 0.
Reserved1、Reserved2 These分野は0であるに違いありません。
2.4. Stop-Control-Connection-Reply
2.4. 停止コントロール接続回答
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コントロール接続回答はもう片方の同輩からのStopコントロール接続要求を受け取り次第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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Result Code | Error Code | Reserved1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 長さ| PPTPメッセージタイプ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 魔法クッキー| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | コントロールメッセージタイプ| Reserved0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 結果コード| エラーコード| Reserved1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Length Total length in octets of this PPTP message,
including the entire PPTP header.
全体のPPTPヘッダーを含むこのPPTPメッセージの八重奏における長さのTotalの長さ。
PPTP Message Type 1 for Control Message.
コントロールメッセージのためのPPTPメッセージタイプ1。
Magic Cookie 0x1A2B3C4D.
魔法クッキー0x1A2B3C4D。
Control Message Type 4 for Stop-Control-Connection-Reply.
停止コントロール接続回答のためのメッセージタイプ4を監督してください。
Reserved0 This field MUST be 0.
Reserved0 This分野は0であるに違いありません。
Result Code Indicates the result of the attempt to close
the control connection. Current valid Result
Code values are:
結果Code Indicates、コントロール接続を終える試みの結果。 現在の有効なResult Code値は以下の通りです。
Hamzeh, et al. Informational [Page 16] RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
Hamzeh、他 1999年7月にプロトコル(PPTP)にトンネルを堀る情報[16ページ]のRFC2637ポイントツーポイント
1 (OK) - Control connection closed
1(OK)--コントロール接続は閉じました。
2 (General Error) - Control connection
not closed for reason indicated in
Error Code
2(Error司令官)--Error Codeで示された理由に閉店しなかったコントロール接続
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.
「一般的なエラー」が存在していない場合、Code Thisがさばく誤りは0に設定されます、そして、その場合、Result Codeは2に用意ができています、そして、この分野はセクション2.2の指定されるとして一般的なエラー状態に対応する値に設定されます。
Reserved1 This field MUST be 0.
Reserved1 This分野は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.
Echo-要求はPAC-PNSコントロール接続のどちらの同輩によっても送られたPPTPコントロールメッセージです。 このコントロールメッセージはコントロール接続のための「生きているままでいてください」として使用されます。 受信同輩は受け取られた各Echo-要求にEcho-回答を発行します。 セクション3.1.4で指定されるように、送付者がEcho-要求に対応してEcho-回答を受け取らないと、それは結局、コントロール接続をきれいにするでしょう。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 長さ| PPTPメッセージタイプ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 魔法クッキー| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | コントロールメッセージタイプ| Reserved0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 識別子| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Length Total length in octets of this PPTP message,
including the entire PPTP header.
全体のPPTPヘッダーを含むこのPPTPメッセージの八重奏における長さのTotalの長さ。
PPTP Message Type 1 for Control Message.
コントロールメッセージのためのPPTPメッセージタイプ1。
Magic Cookie 0x1A2B3C4D.
魔法クッキー0x1A2B3C4D。
Control Message Type 5 for Echo-Request.
エコー要求のためのメッセージタイプ5を監督してください。
Reserved0 This field MUST be 0.
Reserved0 This分野は0であるに違いありません。
Hamzeh, et al. Informational [Page 17] RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
Hamzeh、他 1999年7月にプロトコル(PPTP)にトンネルを堀る情報[17ページ]のRFC2637ポイントツーポイント
Identifier A value set by the sender of the Echo-
Request that is used to match the reply with
the corresponding request.
識別子A価値は対応する要求に回答に合うのに使用されるEcho要求の送付者でセットしました。
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.
Echo-回答はEcho要求の領収書に対応して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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 長さ| PPTPメッセージタイプ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 魔法クッキー| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | コントロールメッセージタイプ| Reserved0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 識別子| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 結果コード| エラーコード| Reserved1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Length Total length in octets of this PPTP message,
including the entire PPTP header.
全体のPPTPヘッダーを含むこのPPTPメッセージの八重奏における長さのTotalの長さ。
PPTP Message Type 1 for Control Message.
コントロールメッセージのためのPPTPメッセージタイプ1。
Magic Cookie 0x1A2B3C4D.
魔法クッキー0x1A2B3C4D。
Control Message Type 6 for Echo-Reply.
エコー・リプライのためのメッセージタイプ6を監督してください。
Reserved0 This field MUST be 0.
Reserved0 This分野は0であるに違いありません。
Identifier The contents of the identify field from the
received Echo-Request is copied to this
field.
受信されたEcho-要求から分野を特定してください。識別子、コンテンツ、この分野にコピーされます。
Result Code Indicates the result of the receipt of the
Echo-Request. Current valid Result Code
values are:
結果Code Indicates、Echo-要求の領収書の結果。 現在の有効なResult Code値は以下の通りです。
1 (OK) - The Echo-Reply is valid
1(OK)--Echo-回答は有効です。
2 (General Error) - Echo-Request not
accepted for the reason indicated in
Error Code
2(Error司令官)--Error Codeで示された理由で受け入れられなかったエコー要求
Hamzeh, et al. Informational [Page 18] RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
Hamzeh、他 1999年7月にプロトコル(PPTP)にトンネルを堀る情報[18ページ]のRFC2637ポイントツーポイント
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.
「一般的なエラー」状態が存在していない場合、Code Thisがさばく誤りは0に設定されます、そして、その場合、Result Codeは2に用意ができています、そして、この分野はセクション2.2の指定されるとして一般的なエラー状態に対応する値に設定されます。
Reserved1 This field MUST be 0.
Reserved1 This分野は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呼び出し要求はPACからの外国行きの呼び出しが設立されることであることを示すためにPNSによってPACに送られたPPTPコントロールメッセージです。 この要求は電話をかけるのに必要である情報をPACに提供します。 また、それはそれがいったん設立されたあとにこのセッションのためにデータの伝達をPNSに規制するのに使用されるPACに情報を供給します。
Hamzeh, et al. Informational [Page 19] RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
Hamzeh、他 1999年7月にプロトコル(PPTP)にトンネルを堀る情報[19ページ]のRFC2637ポイントツーポイント
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) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 長さ| PPTPメッセージタイプ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 魔法クッキー| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | コントロールメッセージタイプ| Reserved0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IDに電話をしてください。| 通し番号に電話をしてください。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 最小のビーピーエス| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 最大のビーピーエス| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 運搬人タイプ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 縁どりタイプ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | パケットRecv。 ウィンドウサイズ| パケット処理遅れ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 電話番号の長さ| Reserved1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + 電話Number(64の八重奏)+| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Subaddress(64の八重奏)+| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Length Total length in octets of this PPTP message,
including the entire PPTP header.
全体のPPTPヘッダーを含むこのPPTPメッセージの八重奏における長さのTotalの長さ。
PPTP Message Type 1 for Control Message.
コントロールメッセージのためのPPTPメッセージタイプ1。
Magic Cookie 0x1A2B3C4D.
魔法クッキー0x1A2B3C4D。
Control Message Type 7 for Outgoing-Call-Request.
送信する発呼要求のためのメッセージタイプ7を監督してください。
Reserved0 This field MUST be 0.
Reserved0 This分野は0であるに違いありません。
Hamzeh, et al. Informational [Page 20] RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
Hamzeh、他 1999年7月にプロトコル(PPTP)にトンネルを堀る情報[20ページ]のRFC2637ポイントツーポイント
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組にユニークなユニークな識別子にID Aに電話をしてください。 それは多重送信するのに使用されました、そして、「反-マルチプレックス」データはこのセッションにかかわる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.
Serial Number Anを登録されたセッション情報におけるこの特定のセッションを特定する目的のためのこのセッションまでPNSによって割り当てられた識別子と呼んでください。 Call IDと異なって、PNSとPACの両方が同じCall Serial Numberを与えられたセッションに関連づけます。 IPの組み合わせは、通し番号をSHOULDと扱って、呼びます。ユニークであってください。
Minimum BPS The lowest acceptable line speed (in
bits/second) for this session.
このセッションのための最も低い許容できるライン・スピード(ビット/秒の)の最小のBPS。
Maximum BPS The highest acceptable line speed (in
bits/second) for this session.
このセッションのための最も高い許容できるライン・スピード(ビット/秒の)の最大のBPS。
Bearer Type A value indicating the bearer capability
required for this outgoing call. The
currently defined values are:
運搬人能力を示す運搬人Type A価値がこの発信電話に必要です。 現在定義された値は以下の通りです。
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縁どりのタイプを示すType A価値を縁どっています。
1 - Call to use Asynchronous framing
1--電話をして、Asynchronous縁どりを使用してください。
2 - Call to use Synchronous framing
2--電話をして、Synchronous縁どりを使用してください。
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.
パケットRecv。 Sizeに窓を付けてください。PNSがこのセッションのためにバッファリングする受信データパケットの数。
Hamzeh, et al. Informational [Page 21] RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
Hamzeh、他 1999年7月にプロトコル(PPTP)にトンネルを堀る情報[21ページ]のRFC2637ポイントツーポイント
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.
データに課されるかもしれないパケット処理遅れのパケットProcessing Delay A測定はPACからPNSに発信しました。 この値は1/10秒の単位で指定されます。 PNSに関しては、この数は非常に少ないはずです。 この値がどう決定して、使用されるかに関する記述に関してセクション4.4を見てください。
Phone Number Length The actual number of valid digits in the
Phone Number field.
電話Numberの数の有効なケタがさばく実際のNumber Lengthに電話をしてください。
Reserved1 This field MUST be 0.
Reserved1 This分野は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.
Numberに電話をしてください。外向的なセッションを確立するのにダイヤルされるべき数。 ISDNとアナログの呼び出しのために、この分野はASCIIストリングです。 電話Numberが長さが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.
Subaddress A64八重奏分野は以前はよく追加番号案内に電話をかけることを指定していました。 長い間「副-アドレス」が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呼び出し回答は受信されたOutgoing呼び出し要求メッセージに対応したPACによってPNSに送られたPPTPコントロールメッセージです。 回答は発信電話試みの結果を示します。 また、それは呼び出しに使用される特定のパラメタに関して情報をPNSに供給します。 それは、PNSがこのセッションのためにデータの伝達をPACに規制するのを許容するために情報を提供します。
Hamzeh, et al. Informational [Page 22] RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
Hamzeh、他 1999年7月にプロトコル(PPTP)にトンネルを堀る情報[22ページ]のRFC2637ポイントツーポイント
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 長さ| PPTPメッセージタイプ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 魔法クッキー| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | コントロールメッセージタイプ| Reserved0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IDに電話をしてください。| 同輩のCall ID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 結果コード| エラーコード| 原因コード| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 速度を接続してください。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | パケットRecv。 ウィンドウサイズ| パケット処理遅れ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 物理的なチャンネルID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Length Total length in octets of this PPTP message,
including the entire PPTP header.
全体のPPTPヘッダーを含むこのPPTPメッセージの八重奏における長さのTotalの長さ。
PPTP Message Type 1 for Control Message.
コントロールメッセージのためのPPTPメッセージタイプ1。
Magic Cookie 0x1A2B3C4D.
魔法クッキー0x1A2B3C4D。
Control Message Type 8 for Outgoing-Call-Reply.
外向的な呼び出し回答のためのメッセージタイプ8を監督してください。
Reserved0 This field MUST be 0.
Reserved0 This分野は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によって割り当てられたトンネルにID Aに電話をしてください。 それは多重送信するのに使用されました、そして、「反-マルチプレックス」データはこのセッションにかかわる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.
同輩のCall ID This分野は対応するOutgoing呼び出し要求メッセージのCall ID分野の対価領収に設定されます。 それは、それが出したOutgoing呼び出し要求にOutgoing呼び出し回答に合うのにPNSによって使用されます。 また、値がmux/demuxingのためにGREヘッダーを送ったので、それも使用されています。
Hamzeh, et al. Informational [Page 23] RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
Hamzeh、他 1999年7月にプロトコル(PPTP)にトンネルを堀る情報[23ページ]のRFC2637ポイントツーポイント
Result Code This value indicates the result of the
Outgoing-Call-Request attempt. Currently
valid values are:
結果Code This価値はOutgoing呼び出し要求試みの結果を示します。 現在の、有効値は以下の通りです。
1 (Connected) - Call established with
no errors
1(接続される)--誤りなしで確立された呼び出し
2 (General Error) - Outgoing Call not
established for the reason indicated
in Error Code
2(Error司令官)--Error Codeで示された理由で設立されなかった出発しているCall
3 (No Carrier) - Outgoing Call failed
due to no carrier detected
3(Carrierがない)--検出されなかったキャリヤーの全くため失敗された出発しているCall
4 (Busy) - Outgoing Call failed due to
detection of a busy signal
4(忙しい)--話中音の検出のため失敗された出発しているCall
5 (No Dial Tone) - Outgoing Call
failed due to lack of a dial tone
5(Dial利根がない)--ダイヤルトーンの不足のため失敗された出発しているCall
6 (Time-out) - Outgoing Call was not
established within time allotted by
PAC
6(タイムアウト)--出発しているCallはPACによって割り当てられた時中に設立されませんでした。
7 (Do Not Accept) - Outgoing Call
administratively prohibited
7(Not Acceptをする)--行政上禁止された出発しているCall
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.
「一般的なエラー」状態が存在していない場合、Code Thisがさばく誤りは0に設定されます、そして、その場合、Result Codeは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.
Code Thisがさばく原因は追加失敗情報を教えます。 試みられた呼び出しのタイプに頼っていて、値は異なることができます。 ISDN呼び出し試みのために、それはQ.931原因コードです。
Connect Speed The actual connection speed used, in
bits/second.
ビット/秒で使用される実際の接続速度のSpeedを接続してください。
Packet Recv. Window Size The number of received data packets the PAC
will buffer for this session.
パケットRecv。 Sizeに窓を付けてください。PACがこのセッションのためにバッファリングする受信データパケットの数。
Hamzeh, et al. Informational [Page 24] RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
Hamzeh、他 1999年7月にプロトコル(PPTP)にトンネルを堀る情報[24ページ]のRFC2637ポイントツーポイント
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.
データに課されるかもしれないパケット処理遅れのパケットProcessing Delay A測定は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.
Thisがさばく物理的なChannel IDはこの電話をするのに物理的な論理機番へのベンダーの特定の方法による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呼び出し要求は本国行きの呼び出しがPACから設立されることであることを示すためにPACによってPNSに送られたPPTPコントロールメッセージです。 この要求はかかってきた電話のためのパラメタ情報を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方向ハンドシェイク」で1番目です。 呼び出しが確立されるべきであるのを示すPNSからIncoming呼び出し回答を受け取るまで、PACは電話口に出ることを延期するかもしれません。 このメカニズムで、それが呼び出しが答えられるべきであるかどうか決定するために答えられる前にPNSは呼び出しに関する十分な情報を得ることができます。
Hamzeh, et al. Informational [Page 25] RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
Hamzeh、他 1999年7月にプロトコル(PPTP)にトンネルを堀る情報[25ページ]のRFC2637ポイントツーポイント
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) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 長さ| PPTPメッセージタイプ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 魔法クッキー| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | コントロールメッセージタイプ| Reserved0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IDに電話をしてください。| 通し番号に電話をしてください。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 運搬人タイプに電話をしてください。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 物理的なチャンネルID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ダイヤルされた数の長さ| 数の長さにダイヤルします。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + ダイヤルされたNumber(64の八重奏)+| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Number(64の八重奏)+にダイヤルすること。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Subaddress(64の八重奏)+| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Length Total length in octets of this PPTP message,
including the entire PPTP header.
全体のPPTPヘッダーを含むこのPPTPメッセージの八重奏における長さのTotalの長さ。
PPTP Message Type 1 for Control Message.
コントロールメッセージのためのPPTPメッセージタイプ1。
Magic Cookie 0x1A2B3C4D.
魔法クッキー0x1A2B3C4D。
Control Message Type 9 for Incoming-Call-Request.
入って来る発呼要求のためのメッセージタイプ9を監督してください。
Reserved0 This field MUST be 0.
Reserved0 This分野は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によって割り当てられたこのトンネルにID Aに電話をしてください。 それは多重送信するのに使用されました、そして、「反-マルチプレックス」データはこのセッションにかかわるPNSとPACの間のトンネルを移動しました。
Hamzeh, et al. Informational [Page 26] RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
Hamzeh、他 1999年7月にプロトコル(PPTP)にトンネルを堀る情報[26ページ]のRFC2637ポイントツーポイント
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.
Serial Number Anを登録されたセッション情報におけるこの特定のセッションを特定する目的のためのこのセッションまでPACによって割り当てられた識別子と呼んでください。 Call IDと異なって、PNSとPACの両方が与えられたセッションまで同じCall Serial Numberを関連づけます。 IPアドレスと呼び出し通し番号の組み合わせはユニークであるべきです。
Bearer Type A value indicating the bearer capability
used for this incoming call. Currently
defined values are:
このかかってきた電話に使用される運搬人能力を示す運搬人Type A価値。 現在定義された値は以下の通りです。
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.
Thisがさばく物理的なChannel IDはこの呼び出しが到着した物理的なチャンネルの数へのベンダーの特定の方法によるPACによるセットです。
Dialed Number Length The actual number of valid digits in the
Dialed Number field.
Dialed Numberの数の有効なケタがさばく実際のNumber Lengthにダイヤルしました。
Dialing Number Length The actual number of valid digits in the
Dialing Number field.
Number LengthにDialing Numberの有効なケタの実数がさばくダイヤルすること。
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.
Numberにダイヤルする、訪問者によってダイヤルされた番号。 ISDNとアナログの呼び出しのために、この分野はASCIIストリングです。 Dialed Numberが長さが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.
Numberにダイヤルする、電話が出された数。 ISDNとアナログの呼び出しのために、この分野はASCIIストリングです。 Dialing Numberが長さが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.
Subaddress A64八重奏分野は以前はよく追加番号案内に電話をかけることを指定していました。 長い間「副-アドレス」が64未満の八重奏であるなら、この分野の残りは価値0の八重奏で満たされます。
Hamzeh, et al. Informational [Page 27] RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
Hamzeh、他 1999年7月にプロトコル(PPTP)にトンネルを堀る情報[27ページ]のRFC2637ポイントツーポイント
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呼び出し回答は受信されたIncoming呼び出し要求メッセージに対応した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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 長さ| PPTPメッセージタイプ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 魔法クッキー| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | コントロールメッセージタイプ| Reserved0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IDに電話をしてください。| 同輩のCall ID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 結果コード| エラーコード| パケットRecv。 ウィンドウサイズ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | パケットは遅れを伝えます。| Reserved1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Length Total length in octets of this PPTP message,
including the entire PPTP header.
全体のPPTPヘッダーを含むこのPPTPメッセージの八重奏における長さのTotalの長さ。
PPTP Message Type 1 for Control Message.
コントロールメッセージのためのPPTPメッセージタイプ1。
Magic Cookie 0x1A2B3C4D.
魔法クッキー0x1A2B3C4D。
Control Message Type 10 for Incoming-Call-Reply.
入って来る呼び出し回答のためのメッセージタイプ10を監督してください。
Reserved0 This field MUST be 0.
Reserved0 This分野は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によって割り当てられたこのトンネルにID Aに電話をしてください。 それは多重送信するのに使用されました、そして、「反-マルチプレックス」データはこのセッションにかかわる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
同輩のCall ID This分野は対応するIncoming呼び出し要求メッセージのCall ID分野の対価領収に設定されます。 それは使用されます。
Hamzeh, et al. Informational [Page 28] RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
Hamzeh、他 1999年7月にプロトコル(PPTP)にトンネルを堀る情報[28ページ]のRFC2637ポイントツーポイント
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呼び出し要求にIncoming呼び出し回答に合うPAC。 この値はこのセッションのために伝えられたデータ・パケットのGREヘッダーに含まれています。
Result Code This value indicates the result of the
Incoming-Call-Request attempt. Current
valid Result Code values are:
結果Code This価値はIncoming呼び出し要求試みの結果を示します。 現在の有効なResult Code値は以下の通りです。
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(Error司令官)--Error Codeで示された理由のためIncoming Callを設立するべきではありません。
3 (Do Not Accept) - The PAC should not
accept the incoming call. It should
hang up or issue a busy indication
3 (Not Acceptをします)--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.
「一般的なエラー」状態が存在していない場合、Code Thisがさばく誤りは0に設定されます、そして、その場合、Result Codeは2に用意ができています、そして、この分野はセクション2.2の指定されるとして一般的なエラー状態に対応する値に設定されます。
Packet Recv. Window Size The number of received data packets the PAC
will buffer for this session.
パケットRecv。 Sizeに窓を付けてください。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.
データに課されるかもしれないパケット処理遅れのパケットTransmit Delay A測定はPNSからPACに発信しました。 この値は1/10秒の単位で指定されます。
Reserved1 This field MUST be 0.
Reserved1 This分野は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呼び出しが接続しているメッセージは容認されたIncoming呼び出し回答に対応した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
このメッセージはかかってきた電話を確立するのにPPTPによって使用された3方向ハンドシェイクで3番目です。 それは中の呼び出しに関する追加情報があるそうすることができないPNSを提供するのにメカニズムを提供します。
Hamzeh, et al. Informational [Page 29] RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
Hamzeh、他 1999年7月にプロトコル(PPTP)にトンネルを堀る情報[29ページ]のRFC2637ポイントツーポイント
general, be obtained at the time the Incoming-Call-Request is issued by the PAC.
一般、PACがIncoming呼び出し要求を出すとき、得てください。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 長さ| PPTPメッセージタイプ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 魔法クッキー| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | コントロールメッセージタイプ| Reserved0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 同輩のCall ID| Reserved1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 速度を接続してください。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | パケットRecv。 ウィンドウサイズ| パケットは遅れを伝えます。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 縁どりタイプ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Length Total length in octets of this PPTP message,
including the entire PPTP header.
全体のPPTPヘッダーを含むこのPPTPメッセージの八重奏における長さのTotalの長さ。
PPTP Message Type 1 for Control Message.
コントロールメッセージのためのPPTPメッセージタイプ1。
Magic Cookie 0x1A2B3C4D.
魔法クッキー0x1A2B3C4D。
Control Message Type 11 for Incoming-Call-Connected.
入って来る接続完了のためにメッセージタイプ11を監督してください。
Reserved0 This field MUST be 0.
Reserved0 This分野は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.
同輩のCall ID This分野は対応するIncoming呼び出し応答メッセージのCall ID分野の対価領収に設定されます。 それは、それが発行したIncoming呼び出し回答に接続されたIncoming呼び出しに合うのにPNSによって使用されます。
Connect Speed The actual connection speed used, in
bits/second.
ビット/秒で使用される実際の接続速度のSpeedを接続してください。
Packet Recv. Window Size The number of received data packets the PAC
will buffer for this session.
パケットRecv。 Sizeに窓を付けてください。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.
データに課されるかもしれないパケット処理遅れのパケットTransmit Delay A測定はPNSからPACに発信しました。 この値は1/10秒の単位で指定されます。
Hamzeh, et al. Informational [Page 30] RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
Hamzeh、他 1999年7月にプロトコル(PPTP)にトンネルを堀る情報[30ページ]のRFC2637ポイントツーポイント
Framing Type A value indicating the type of PPP framing
being used by this incoming call.
このかかってきた電話で使用されるPPP縁どりのタイプを示すType A価値を縁どっています。
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の明確な要求はPNSによって特定の呼び出しが切断されることであることを示すPACに送られたPPTPコントロールメッセージです。 クリアされる呼び出しは、どんな状態の入来か発信電話のどちらかであるかもしれません。 PACはCall-分離でこのメッセージに応じます。-メッセージに通知してください。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 長さ| PPTPメッセージタイプ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 魔法クッキー| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | コントロールメッセージタイプ| Reserved0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IDに電話をしてください。| Reserved1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Length Total length in octets of this PPTP message,
including the entire PPTP header.
全体のPPTPヘッダーを含むこのPPTPメッセージの八重奏における長さのTotalの長さ。
PPTP Message Type 1 for Control Message.
コントロールメッセージのためのPPTPメッセージタイプ1。
Magic Cookie 0x1A2B3C4D.
魔法クッキー0x1A2B3C4D。
Control Message Type 12 for Call-Clear-Request.
呼び出しの明確な要求のためのメッセージタイプ12を監督してください。
Reserved0 This field MUST be 0.
Reserved0 This分野は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によってこの呼び出しに割り当てられたCall IDにIDに電話をしてください。 呼び出し設立の間、呼び出しを中止しなければならないなら後者がPNSにおいて知られていないかもしれないので、この値はPeerのCall IDの代わりに使用されます。
Reserved1 This field MUST be 0.
Reserved1 This分野は0であるに違いありません。
Hamzeh, et al. Informational [Page 31] RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
Hamzeh、他 1999年7月にプロトコル(PPTP)にトンネルを堀る情報[31ページ]のRFC2637ポイントツーポイント
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分離に通知しているメッセージはPACによってPNSに送られたPPTPコントロールメッセージです。 呼び出し切断されるときはいつも、それは発行されます、Callの明確な要求のPACかいかなる他の理由による領収書のためも。 目的は断線とそれの理由の両方についてPNSに知らせることです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | PPTP Message Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Magic Cookie |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Control Message Type | Reserved0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Call ID | Result Code | Error Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cause Code | Reserved1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Call Statistics (128 octets) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 長さ| PPTPメッセージタイプ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 魔法クッキー| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | コントロールメッセージタイプ| Reserved0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IDに電話をしてください。| 結果コード| エラーコード| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 原因コード| Reserved1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + 呼び出しStatistics(128の八重奏)+| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Length Total length in octets of this PPTP message,
including the entire PPTP header.
全体のPPTPヘッダーを含むこのPPTPメッセージの八重奏における長さのTotalの長さ。
PPTP Message Type 1 for Control Message.
コントロールメッセージのためのPPTPメッセージタイプ1。
Magic Cookie 0x1A2B3C4D.
魔法クッキー0x1A2B3C4D。
Control Message Type 13 for Call-Disconnect-Notify.
分離が通知する呼び出しのためのメッセージタイプ13を監督してください。
Reserved0 This field MUST be 0.
Reserved0 This分野は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によってこの呼び出しに割り当てられたCall IDの値にIDに電話をしてください。 呼び出し設立の間、呼び出しを中止しなければならないなら後者がPNSにおいて知られていないかもしれないので、この値はPeerのCall IDの代わりに使用されます。
Hamzeh, et al. Informational [Page 32] RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
Hamzeh、他 1999年7月にプロトコル(PPTP)にトンネルを堀る情報[32ページ]のRFC2637ポイントツーポイント
Result Code This value indicates the reason for the
disconnect. Current valid Result Code values
are:
結果Code This価値は分離の理由を示します。 現在の有効なResult Code値は以下の通りです。
1 (Lost Carrier) - Call disconnected
due to loss of carrier
1(Carrierをなくす)--キャリヤーの損失のため切断された呼び出し
2 (General Error) - Call disconnected
for the reason indicated in Error
Code
2(Error司令官)--Error Codeで示された理由で切断された呼び出し
3 (Admin Shutdown) - Call disconnected
for administrative reasons
3(アドミンShutdown)--管理理由で切断された呼び出し
4 (Request) - Call disconnected due to
received Call-Clear-Request
4(要求する)--受信されたCall明確な要求のため切断された呼び出し
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.
「一般的なエラー」状態が存在していない場合、Code Thisがさばく誤りは0に設定されます、そして、その場合、Result Codeは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.
Code Thisがさばく原因は追加分離情報を教えます。 切断される呼び出しのタイプに頼っていて、値は異なります。 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.
呼び出しStatistics This分野は診断目的で登録できるベンダー特有の呼び出し統計を含むASCIIストリングです。 ストリングの長さが128未満であるなら、分野の残りは価値0の八重奏で満たされます。
2.14. WAN-Error-Notify
2.14. 青白い誤りに通知します。
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誤りに通知しているメッセージはWANエラー条件(PPPをサポートしながらインタフェースに現れる状態)を示すためにPACによってPNSに送られたPPTPコントロールメッセージです。 このメッセージのカウンタは累積しています。 それほどこのメッセージに60秒に一度送るだけでないべきです。 新しい呼び出しが確立されるとき、カウンタはリセットされます。
Hamzeh, et al. Informational [Page 33] RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
Hamzeh、他 1999年7月にプロトコル(PPTP)にトンネルを堀る情報[33ページ]のRFC2637ポイントツーポイント
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 長さ| PPTPメッセージタイプ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 魔法クッキー| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | コントロールMessageはタイプします。| Reserved0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 同輩のCall ID| Reserved1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CRC誤り| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 縁どり誤り| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ハードウェア超過| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | バッファ超過| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイムアウト誤り| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 整列誤り| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Length Total length in octets of this PPTP message,
including the entire PPTP header.
全体のPPTPヘッダーを含むこのPPTPメッセージの八重奏における長さのTotalの長さ。
PPTP Message Type 1 for Control Message.
コントロールメッセージのためのPPTPメッセージタイプ1。
Magic Cookie 0x1A2B3C4D.
魔法クッキー0x1A2B3C4D。
Control Message Type 14 for WAN-Error-Notify.
誤りが通知するWANのためにメッセージタイプ14を監督してください。
Reserved0 This field MUST be 0.
Reserved0 This分野は0であるに違いありません。
Peer's Call ID Th Call ID assigned by the PNS to this call.
IDがPNSでこれに割り当てた同輩のCall ID Th Callは呼びます。
CRC Errors Number of PPP frames received with CRC
errors since session was established.
セッションが確立されたので、PPPフレームのCRC Errors NumberはCRC誤りで受信しました。
Framing Errors Number of improperly framed PPP packets
received.
不適切に縁どられたPPPパケットの縁どりErrors Numberは受信しました。
Hardware Overruns Number of receive buffer over-runs since
session was established.
セッションが確立されたので、受信バッファのハードウェアOverruns Numberは氾濫します。
Buffer Overruns Number of buffer over-runs detected since
session was established.
セッション以来検出されたバッファ超過のバッファOverruns Numberは設立されました。
Hamzeh, et al. Informational [Page 34] RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
Hamzeh、他 1999年7月にプロトコル(PPTP)にトンネルを堀る情報[34ページ]のRFC2637ポイントツーポイント
Time-out Errors Number of time-outs since call was
established.
タイムアウトのErrors Numberが以来呼ぶタイムアウトは確立されました。
Alignment Errors Number of alignment errors since call was
established.
整列誤りのErrors Numberが以来呼ぶ整列は確立されました。
2.15. Set-Link-Info
2.15. リンクインフォメーションを設定してください。
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リンクインフォメーションメッセージはPPPによって交渉されたオプションを設定するためにPNSによってPACに送られた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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 長さ| PPTPメッセージタイプ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 魔法クッキー| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | コントロールMessageはタイプします。| Reserved0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 同輩のCall ID| Reserved1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ACCMを送ってください。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ACCMを受けてください。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Length Total length in octets of this PPTP message,
including the entire PPTP header.
全体のPPTPヘッダーを含むこのPPTPメッセージの八重奏における長さのTotalの長さ。
PPTP Message Type 1 for Control Message.
コントロールメッセージのためのPPTPメッセージタイプ1。
Magic Cookie 0x1A2B3C4D.
魔法クッキー0x1A2B3C4D。
Control Message Type 15 for Set-Link-Info.
セットリンクインフォメーションのためにメッセージタイプ15を監督してください。
Reserved0 This field MUST be 0.
Reserved0 This分野は0であるに違いありません。
Peer's Call ID The value of the Call ID assigned by the PAC
to this call.
Call IDの値がPACでこの呼び出しに割り当てた同輩のCall ID。
Reserved1 This field MUST be 0.
Reserved1 This分野は0であるに違いありません。
Hamzeh, et al. Informational [Page 35] RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
Hamzeh、他 1999年7月にプロトコル(PPTP)にトンネルを堀る情報[35ページ]のRFC2637ポイントツーポイント
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].
ACCMを送ってください、クライアントが外向的に処理するのに使用するべきであるACCM値にPPPパケットを送ってください。 このメッセージが受信されるまでクライアントによって使用されたデフォルト値は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].
ACCMを受けてください、クライアントが入って来る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回答が、Result Codeで一般的なエラーが起こったのを示すなら、値が調べられるべきである司令官のErrorは、誤りが何であるかを決定しました。 現在定義された一般Errorコードとそれらの意味は以下の通りです。
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(悪い形式)--長さが間違っているか、またはマジックCookie値は不正確です。
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)--Call IDはこのような関係においては無効です。
6 (PAC-Error) - A generic vendor-specific error occurred in
the PAC
6(PAC-誤り)--ジェネリックのベンダー特有の誤りは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コントロール接続機能とそれらをサポートするのに使用されるControl Connectionメッセージの操作について説明します。 TCPが信頼できる移送機構を提供するのに使用されるので、コントロール接続のプロトコル操作は簡易型です。 メッセージの注文と「再-トランスミッション」はこのレベルにおいて関心ではありません。 しかしながら、TCP接続自体はいつでも閉じることができます、そして、本件を扱うために適切なエラー回復メカニズムを提供しなければなりません。
Hamzeh, et al. Informational [Page 36] RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
Hamzeh、他 1999年7月にプロトコル(PPTP)にトンネルを堀る情報[36ページ]のRFC2637ポイントツーポイント
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.
無効の、または、奇形のControl Connectionメッセージの領収書が適切に登録されるべきであり、コントロール接続は、知られている状態に回復を確実にするために閉店して、再出発されるべきです。
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 |
+-----------------+
/がスタートコントロール接続要求+を送るというTCPの開いている指示-----------------+ +------------------------------------>| 待ち_ctl_回答| | +-----------------+ | 衝突/が見られる、(.3の)近いTCP V V Vが受け取る4.1はCtlを始動します。| +-------------------------------+ | | 接続回答| | | | バージョンOK^V| +に対して-----------------+はスタートCtlを受けます。| +-----------------+ | 怠けてください。| 接続回答| | 設立されます。| +-----------------+ OKではなく、バージョン| +-----------------+ ^ | 地方に対して、終わってください。| 停止コントロールを受けてください。| | /は停止を送ります。| 接続要求| | コントロール要求| /は停止コントロール回答V Vを送ります。| TCP+を閉じてください。-----------------+ +-------------------------------------| 待ち_停止_回答| +-----------------+
Hamzeh, et al. Informational [Page 37] RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
Hamzeh、他 1999年7月にプロトコル(PPTP)にトンネルを堀る情報[37ページ]のRFC2637ポイントツーポイント
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接続を同輩に公開するコントロール接続創始者試みを空費してください。 aはStart-コントロールを送ります。TCP接続がオープンであるときに、創始者が伝わる、-接続要求とその時は待ち_ctl_回答状態に入れます。
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接続が同じ同輩から要求されるなら、_創始者が見るためにチェックするctl_回答を待ってください。そうすれば、そうだとすれば、衝突状況が中で説明したハンドルは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コントロール接続回答が受け取られているとき、それはコンパチブルバージョンがないかどうか調べられます。 回答のバージョンがバージョンが要求を送ったより低いなら、それがサポートされるなら、より古い(下側の)バージョンは使用されるべきです。 バージョンが回答で、より初期でサポートされるなら、創始者は設立された状態に移行します。 _より早く、サポートされなかったバージョン、Stopコントロール接続要求SHOULDが同輩に送って待ちへの創始者移動であるなら、_回答状態を止めてください。
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.
確立したAn確立した接続はStopコントロール接続要求の現地の状況か領収書のどちらかで終えられるかもしれません。 地方の終了の場合、創始者は、Stopコントロール接続要求を送って、待ち_停止_回答州に入力しなければなりません。
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コントロール接続要求を受け取る、それ、SHOULDは適切にStopコントロール接続回答を送って、最終的なTCP情報を「押してあること」を確実にするTCP接続を終えます。
wait_stop_reply
If a Stop-Control-Connection-Reply is received, the TCP connection
SHOULD be closed and the control connection becomes idle.
受け取られたStopコントロール接続回答、_停止_回答If TCP接続SHOULDを待っています。閉じられてください。そうすれば、コントロール接続は活動していなくなります。
Hamzeh, et al. Informational [Page 38] RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
Hamzeh、他 1999年7月にプロトコル(PPTP)にトンネルを堀る情報[38ページ]のRFC2637ポイントツーポイント
3.1.2. Control connection Receiver (may be PAC or PNS)
3.1.2. コントロール接続Receiver(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
バージョンが誤り+とのスタートコントロール接続回答を承認するか、または送らないスタートコントロール接続要求を受け取ってください。--------+ | | コントロール接続要求Version OKを受けてください。| | /はスタートコントロール接続回答を送ります。| | +----------------------------------------+ ^ V ^ V +-----------------+はスタートCtl+を受けます。-----------------+ | 怠けてください。| 接続要求| 設立されます。| +-----------------+ /は停止回答+を送ります。-----------------+ ^ ^ Close TCP V V Local Terminate | +-------------------------------------+ | /は停止を送ります。| | コネチカット州を制御してください。 | V要求| +-----------------+ +-------------------------------------| 待ち停止回答| 停止コントロール+を受けてください。-----------------+ 接続の回答/近い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-コントロールであるときに、接続要求は受け取って、バージョン分野が調べられるべきであるということです。 バージョンが受信機で受信機のバージョンと以前のバージョンをサポートすることができるより初期であるなら、受信機SHOULDはStartコントロール接続回答を送ります。 バージョンが受信機のバージョンとバージョンをサポートすることができないより初期であるなら、受信機SHOULDはStart-接続応答メッセージを送って、TCP接続を終えて、活動していない州に残っています。 受信機のバージョンが同輩より早いのと同じであるなら、受信機SHOULDは受信機のバージョンがあるStartコントロール接続回答を送って、設立された状態に入れます。
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.
確立したAn確立した接続はStopコントロール接続要求の現地の状況かレセプションのどちらかによって終えられるかもしれません。 地方の終了の場合、創始者は、Stopコントロール接続要求を送って、待ち_停止_回答州に入力しなければなりません。
Hamzeh, et al. Informational [Page 39] RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
Hamzeh、他 1999年7月にプロトコル(PPTP)にトンネルを堀る情報[39ページ]のRFC2637ポイントツーポイント
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コントロール接続要求を受け取る、それ、SHOULDはStopコントロール接続回答を送って、TCP接続を終えます、適切に最終的なTCP情報を「押してあること」を確実にして。
wait_stop_reply
If a Stop-Control-Connection-Reply is received, the TCP connection
SHOULD be closed and the control connection becomes idle.
受け取られたStopコントロール接続回答、_停止_回答If 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が、同時にコントロール接続を互いに確立するのを試みるのは、可能です。 1つのTCP接続のときにStartコントロール接続要求を受け取って、既に別のStartコントロール接続要求を同じ同輩との別の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コントロール接続応答メッセージとの勝者の要求に応じるでしょう。 勝者は、それが開始した接続のときにStartコントロール接続回答を待って、また、敗者が開いた接続のときに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接続を終えながら閉じられて、Aは接続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. 中にコントロール接続がないなら、aによる60秒がStart-コントロール接続要求かコントロール接続Replyが通信させるStartを待ちながらじっと見た後に閉じられて、設立された状態(すなわち、接続が要求するStartコントロールとStart-コントロール接続回答は交換されていない)、aは接続SHOULDを制御します。
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-要求メッセージを送ります。 Echo-回答がEcho-要求メッセージ送信、コントロール接続SHOULDの60秒容認された後に閉じられないなら。
Hamzeh, et al. Informational [Page 40] RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
Hamzeh、他 1999年7月にプロトコル(PPTP)にトンネルを堀る情報[40ページ]のRFC2637ポイントツーポイント
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は閉じられて、再開されるべきです。 コントロール接続が始められるときはいつも、すべてのCall 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.
各同輩は、それが要求するそれぞれのユーザセッションまでCall ID価値を割り当てるか、または受け入れます。 それが属するPNSとPACの間のトンネルに、このCall ID価値はユニークであるに違いありません。 他の同輩へのTunnelsが同じCall ID番号を使用できるので、トンネルの上のパケットの受信機は、特定のトンネルとCall IDとのユーザセッションを関連づける必要があります。 各トンネルへの潜在的Call ID値の数が呼び出しの最大数が与えられたトンネルの上で予想したより少なくとも2倍大きいと示唆されます。
A session is defined by the triple (PAC, PNS, Call ID).
三重(PAC、PNS、Call 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
関連電話回線が鳴るとき、Incoming呼び出し要求メッセージはPACによって生成されます。 PACはCall IDと通し番号を選択して、呼び出し運搬人タイプを示します。 モデムはいつもアナログの呼び出しタイプを示すはずです。 ISDN呼び出しは、デジタルか無制限なデジタルサービスであるならレート適応が中古であって、アナログであることを示すべきです。
Hamzeh, et al. Informational [Page 41] RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
Hamzeh、他 1999年7月にプロトコル(PPTP)にトンネルを堀る情報[41ページ]のRFC2637ポイントツーポイント
digital modems are involved. Dialing number, dialed number, and subaddress may be included in the message if they are available from the telephone network.
デジタル・モデムはかかわります。 それらが電話網から利用可能であるなら、数、ダイヤルされた数、および「副-アドレス」にダイヤルするのはメッセージに含まれるかもしれません。
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がいったんIncoming呼び出し要求を送ると、それは、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が、呼び出しを受け入れるのを選ぶなら、それはまた、ウィンドウサイズを示すIncoming呼び出し回答で応じます(セクション4.2を見てください)。 PACがOutgoing呼び出し回答を受け取るとき、起呼側がハングアップしていないと仮定して、それは、呼び出しを接続するのを試みます。 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分離に通知しているメッセージを送ります。 PNSが呼び出しをクリアしたいなら、それは、Callの明確な要求メッセージを送って、分離が通知するCallを待っています。
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
入って来る発呼要求+を鳴らすか、または送ってください。-----------------+ +----------------------------------------->| 待ち_回答| | +-----------------+ | かかってきた電話回答V V Vを受けてください。| 受け入れません。| | | 入来を受けてください。| +--------------------------------+ | | 呼び出し回答は受け入れます。| | +------------------------------+ | ing/答えは呼びます。 | | | 呼び出しを中止になるか、または送ってください。| V分離が接続+に対して通知する呼び出し^Vを送ってください。-----------------+ +-----------------+ | 怠けてください。| <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、| 設立されます。| +-----------------+は明確な発呼要求+を受け取ります。-----------------+か通信業者呼び出しが低下したか、または地方の分離/はCall Disconnect Notifyを送ります。
Hamzeh, et al. Informational [Page 42] RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
Hamzeh、他 1999年7月にプロトコル(PPTP)にトンネルを堀る情報[42ページ]のRFC2637ポイントツーポイント
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を空費してください。通信業者インタフェースの1つにかかってきた電話を検出します。 通常、これが、アナログの線が鳴っていることを意味するか、またはISDN TEは入って来るQ.931 SETUPメッセージを検出しました。 PACはIncoming呼び出し要求メッセージを送って、待ち_回答状態に動きます。
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呼び出し応答メッセージを受け取る待ち_回答が呼び出しを受け入れる、(一般的なエラー、受け入れないでください、)、そして、活動していない状態への移動。 応答メッセージが、呼び出しが受け入れられるのを示すなら、PACはIncoming-呼び出しで接続されたメッセージを送って、設立された状態に入力します。
established
Data is exchanged over the tunnel. The call may be cleared
following:
確立したDataをトンネルの上と交換します。 呼び出しは続くのがクリアされるかもしれません:
An event on the telco connection. The PAC sends a
Call-Disconnect-Notify message
通信業者接続での出来事。 PACはCall分離に通知しているメッセージを送ります。
Receipt of a Call-Clear-Request. The PAC sends a
Call-Disconnect-Notify message
呼び出しの明確な要求の領収書。 PACはCall分離に通知しているメッセージを送ります。
A local reason. The PAC sends a Call-Disconnect-Notify message.
ローカルの理由。 PACはCall分離に通知しているメッセージを送ります。
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
/がかかってきた電話回答+を送る入って来る発呼要求を受け取ってください。-----------------+ 誤りであるなら、受け入れません。| 待つ接続してください。| +-----+ +-----------------+ | | かかってきた電話Reqを受けてください。 ^V V| | /はかかってきた電話Reply OKを送ります。| | | 入来を受けてください。| | +--------------------------------+ | | 呼び出しは^V^Vを接続します。------------------------------+ +に対して-----------------+は呼び出し分離+を受けます。-----------------+ | 怠けてください。| +に通知してください。| 設立されます。| +-----------------+ | +-----------------+ ^ ^ | 地方に対して、終わってください。| +----------------------------+ | /ははっきりと呼び出しを送ります。| 呼び出し分離を受けてください。| 要求| Vに通知してください。| +-----------------+ +--------------------------------------| 待ち分離| 呼び出し分離+を受けてください。-----------------+は通知します。
Hamzeh, et al. Informational [Page 43] RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
Hamzeh、他 1999年7月にプロトコル(PPTP)にトンネルを堀る情報[43ページ]のRFC2637ポイントツーポイント
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.
無駄なAn Incoming呼び出し要求メッセージは受信されています。 要求が許容できないなら、PACはIncoming呼び出し回答に送り返されます、そして、PNSは活動していない州に残っています。 Incoming呼び出し要求メッセージが許容できるなら、Incoming呼び出し回答に結果コードで受け入れるように示させます。 待ち_へのセッション移動は状態をつなげます。
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.
待ち_はIfを接続します。セッションはPACに接続されて、PACはその時設立された状態に動くPNSへのメッセージを呼び出しが接続する入来に送ります。 PACは、電話をかけてきた人に接できなかったのを示すために、分離が通知するCallを送るかもしれません。 例えば、電話ユーザが事故に呼ばれたモデムで握手失敗をもたらす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.
設立されて、セッションはCall PACからメッセージに通知しているか、または発信しているaを連絡を断たせているCall明確な要求の領収書で終えられます。 いったんCallの明確な要求を送ると、セッションは待ち_分離状態に入ります。
wait_disconnect
Once a Call-Disconnect-Notify is received the session moves back
to the idle state.
分離が通知する待ち_分離Once a Callによる受け取って、セッションが活動していない状態に延ばされるということです。
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に命令します。 発信電話への2つのメッセージしかありません: 送信する発呼要求と外向的な呼び出し回答。 PNSはOutgoing呼び出し要求に速度と窓のパラメタと同様にダイヤルされたパーティーの電話番号と「副-アドレス」を指定させます。 PACが、以下のことをいったん決定すると、PAC MUSTはOutgoingが、Outgoing-呼び出し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
Hamzeh、他 1999年7月にプロトコル(PPTP)にトンネルを堀る情報[44ページ]のRFC2637ポイントツーポイント
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
間違った/が誤りとの発信電話回答を送る送信する発呼要求を受け取ってください。|--------+ | | 外向的な発呼要求いいえ誤りを受けてください。| | フックの/。 ダイヤル| | +----------------------------------------- ^V^対+-----------------+ 不完全な呼び出し+-----------------+ | 怠けてください。| /は発信電話を送ります。| __Cs ansを待ってください。| +-----------------+ 誤り+との回答-----------------+ ^ ^ or Recv. 明確なReqに電話をしてください。 V V通信業者答え| | /が分離を送る、通知| | /は外向的に発信します。| +-------------------------------------+ | 回答に電話をしてください。 | V| +-----------------+ +-------------------------------------| 設立されます。| 呼び出しの明確な要求+を受け取ってください。-----------------+かローカルが終わるか、通信業者分離/ハングアップは、呼んで、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.
Received Outgoing呼び出し要求を空費してください。 これを間違って受け取るなら、エラー条件セットによるOutgoing呼び出し回答で、応じてください。 さもなければ、ダイヤルにオンな物理的なチャンネルを割り当ててください。 外国行きの電話をしてください、そして、接続を待ってください、そして、待ち_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.
_Cs_ans Ifを待ってください。呼び出しは不完全であり、非ゼロError CodeとのOutgoing呼び出し回答を送ってください。 タイマが外国行きの呼び出しのときに期限が切れるなら、非ゼロError CodeとのOutgoing呼び出し回答を返送してください。 回線交換接続が確立されるなら、Outgoing呼び出し回答に成功を示させてください。
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.
確立したIf a Call明確な要求が受信されている、通信業者はリリースされたCall分離に適切な手段とaを通して通知しているメッセージがPNSに送られたSHOULD BEであったならSHOULDと呼びます。 呼び出しが外されるなら、クライアントか通信業者インタフェース、分離が通知するCallで、SHOULDを通信させてください。PNSに送ります。
Hamzeh, et al. Informational [Page 45] RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
Hamzeh、他 1999年7月にプロトコル(PPTP)にトンネルを堀る情報[45ページ]のRFC2637ポイントツーポイント
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 |<---------+
+-----------------+
開いている指示は、発信電話の呼び出しの明確な要求+を中止になるか、送る、または送ります。-----------------+ 要求+-------------------------------->| 待ち回答|----------+ | +-----------------+ | | 外向的にVが受け取る発信電話回答Vを受け取ってください。| | 誤りで| | 呼び出し回答| | +-------------------------------+ | 誤りがありません。| ^V V| +-----------------+ +-----------------+ | | 怠けてください。| <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、| 設立されます。| | +-----------------+は呼び出し分離+を受けます。-----------------+ | ^ローカルが終えるVに通知してください。| | | /ははっきりと呼び出しを送ります。| | | 要求| | 呼び出し分離Vを受けてください。| | +に通知してください。-----------------+ | +---------------------------------| 待ち分離| <、-、-、-、-、-、-、-、--+ +-----------------+
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.
無駄なAn Outgoing呼び出し要求メッセージをPACに送ります、そして、セッションは待ち_回答状態に動きます。
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.
待ち_回答An Outgoing呼び出し回答は受け取られています(誤りを示します)。 セッションは戻って、状態を空費します。 どんな通信業者呼び出しも活発ではありません。 Outgoing呼び出し回答が誤りを示さないなら、通信業者呼び出しは関連しています、そして、セッションは設立された状態に動きます。
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.
分離が通知する確立したIf a Callが受け取られている、通信業者呼び出しはResultとCause Codesで示された理由で終えられました。 セッションは活動していない状態に延ばされます。 PNSが、セッションを終えるのを選ぶなら、それは、Callの明確な要求をPACに送って、待ち_分離状態に入力します。
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.
待ち_分離Aセッション断線は、PACによって確認されるのを待っています。 PNSがいったんCall分離に通知しているメッセージを受け取ると、セッションは活動していない状態に入ります。
Hamzeh, et al. Informational [Page 46] RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
Hamzeh、他 1999年7月にプロトコル(PPTP)にトンネルを堀る情報[46ページ]のRFC2637ポイントツーポイント
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パケットは順番にIPの上まで運ばれるGREパケットで要約されたPACとPNSの間まで運ばれます。 要約のPPPパケットは本質的にはPPPよりデータ・パケット以下です。どんなメディア詳細縁どり要素。 HDLC旗、噛み付いている挿入、制御文字、またはどんな制御文字エスケープも含まれていません。 トンネルを通してCRCsを全く送りません。 パケットがPACとPNSの間のトンネルの上で送ったIPは以下の一般構造体を持っています:
+--------------------------------+
| Media Header |
+--------------------------------+
| IP Header |
+--------------------------------+
| GRE Header |
+--------------------------------+
| PPP Packet |
+--------------------------------+
+--------------------------------+ | メディアヘッダー| +--------------------------------+ | IPヘッダー| +--------------------------------+ | GREヘッダー| +--------------------------------+ | pppパケット| +--------------------------------+
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]で指定されたそれから高められます。 主な違いは新しいAcknowledgment Number分野の定義にかかわります、特定のGREパケットか1セットのパケットがトンネルのリモートエンドに到着したかどうか決定するのにおいて、使用されています。 このAcknowledgment能力はユーザデータ・パケットのどんな「再-トランスミッション」に関連して使用されません。 それは、ユーザデータ・パケットが与えられたユーザセッションのためにトンネルの上に送られることになっているレートを測定するのに代わりに使用されます。 高められた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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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|再発してください。|A| 旗| Ver| プロトコルタイプ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 主要な(HW)ペイロード長| 主要な(LW)Call ID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 一連番号(任意の)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 確認応答番号(任意の)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Hamzeh, et al. Informational [Page 47] RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
Hamzeh、他 1999年7月にプロトコル(PPTP)にトンネルを堀る情報[47ページ]のRFC2637ポイントツーポイント
C
(Bit 0) Checksum Present. Set to zero (0).
C(ビット0)チェックサムプレゼント。 セットして、(0)のゼロを合わせてください。
R
(Bit 1) Routing Present. Set to zero (0).
R(ビット1)ルート設定プレゼント。 セットして、(0)のゼロを合わせてください。
K
(Bit 2) Key Present. Set to one (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).
K(ビット2)の主要なプレゼント。 1つ(1)にセットしてください。 S(ビット3)一連番号プレゼント。 ペイロード(データ)パケットが存在しているなら、1つ(1)にセットしてください。 ペイロードが存在していないなら(GREパケットはAcknowledgment専用です)セットして、(0)のゼロを合わせてください。
s
(Bit 4) Strict source route present. Set to zero (0).
現在のs(ビット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)承認一連番号プレゼント。 パケットが以前に伝えられたデータを承認するのに使用されるべきAcknowledgment Numberを含むなら、1つ(1)にセットしてください。
Flags
(Bits 9-12) Must be set to zero (0).
(0)のゼロを合わせるように旗(ビット9-12)を設定しなければなりません。
Ver
(Bits 13-15) Must contain 1 (enhanced GRE).
Ver(ビット13-15)は1(GREを高める)を含まなければなりません。
Protocol Type
Set to hex 880B [8].
Type Setについて議定書の中で述べて、880B[8]に魔法をかけてください。
Key
Use of the Key field is up to the implementation. PPTP uses it as
follows:
Payload Length
(High 2 octets of Key) Size of the payload, not including
the GRE header
Key分野の主要なUseは実現まで達しています。 PPTPは以下の通りそれを使用します: GREヘッダーを含まないペイロードの有効搭載量Length(Keyの高い2つの八重奏)サイズ
Call ID
(Low 2 octets) Contains the Peer's Call ID for the session
to which this packet belongs.
呼び出しID(低い2つの八重奏)はこのパケットが属するセッションのためにPeerのCall IDを含んでいます。
Sequence Number
Contains the sequence number of the payload. Present if S
bit (Bit 3) is one (1).
ペイロードの一連番号の系列Number Contains。 Sが(ビット3)に噛み付いたなら、プレゼントは1つ(1)です。
Hamzeh, et al. Informational [Page 48] RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
Hamzeh、他 1999年7月にプロトコル(PPTP)にトンネルを堀る情報[48ページ]のRFC2637ポイントツーポイント
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パケットの一連番号の承認Number Containsはこのユーザセッションのために送付同輩のそばで受信しました。 Aが(ビット8)に噛み付いたなら、プレゼントは1つ(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.
側が最大サイズを示したそれぞれ、それ、窓を受けてください、そして、データを送り始めるとき、a保守的なアプローチを取るのはお勧めです。 送信機の上の初期のウィンドウサイズは受信機が要求した最大のサイズの半分に設定されます、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
Hamzeh、他 1999年7月にプロトコル(PPTP)にトンネルを堀る情報[49ページ]のRFC2637ポイントツーポイント
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時までに上向きに適応して、調節してください、タイムアウトなしですべて承認されるパケットで満たされた状態で窓を伝えてください。
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.
Acknowledgmentが受け取られているときだけ、適応型のタイムアウト計算は実行されます。 マルチパケット承認が使用されているとき、適応型のタイムアウトアルゴリズムのオーバーヘッドは下げられます。 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
Hamzeh、他 1999年7月にプロトコル(PPTP)にトンネルを堀る情報[50ページ]のRFC2637ポイントツーポイント
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 MUSTの間の系列パケットから静かに捨てられている状態で、対処するというわけではありませんし、また彼らは受信機によって再命令されるかもしれません。パケット5が入るとき、PACに最後の最も高いパケットであった4より高い一連番号を承認させるので、それは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は、タイムアウトが低下しているデータか確認応答パケットから回復するのに使用されるのを必要とします。 タイムアウトの正確な実現は業者特有です。 適応型のタイムアウトが輻輳制御のためにbackoffで実行されることが提案されます。 ここで提案されたタイムアウトメカニズムは以下の特性を持っています:
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.
スループットを変えるのを代償される適応型のタイムアウトメカニズム。 パケット処理オーバヘッドを下げるために、業者はあらゆる容認された承認のための適応型のタイムアウトをどんなrecomputeにも選ばないかもしれません。 この頭上の減少の結果はタイムアウトが同じくらいはやく急速なネットワーク変化に応じないということです。
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.
混雑を抑える外の時のタイマbackoff。 引き返しているタイマ値は構成可能な最大のタイムアウト値によって制限されます。 承認タイムアウトが起こるときはいつも、タイマbackoffをします。
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
Hamzeh、他 1999年7月にプロトコル(PPTP)にトンネルを堀る情報[51ページ]のRFC2637ポイントツーポイント
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.
パケットProcessing Delay(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.
サンプルはパケットのための承認を受けながら被られた実際の時間です。 Sampleは計算されるのではなく、測定されます。
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.
丸い旅行Time(RTT)はAcknowledgmentが与えられた伝えられたパケットのために受け取られるおよそ往復の時間です。 ネットワークリンクが企業内情報通信網であるときに、この遅れは最小限でしょう(まして、ゼロ)。 ネットワークリンクがインターネットであるときに、この遅れは、実質的であり、ばらつきが大きいことができました。 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.
外の適応型のTime(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:
Packet Processing Delay(PPD)パラメタは1秒(6.4秒の64の手段)の10分の1を表すCall Control段階の間に交換された16ビットの単語です。 プロトコルはパラメタを交換して、どう計算されるかを指定しないと指定するだけです。 PPDのための値が計算される方法は、実現依存していて、可変である必要はありません(静的なタイムアウトは許容されています)。 実現で一定のままで残っても、PPDによる交換して、呼び出しでは、系列が接続するということでなければなりません。 PPDについて計算する1つの可能な方法は以下の通りです。
PPD' = ((PPP_MAX_DATA_MTU - Header) * WindowSize * 8) / ConnectRate PPD = PPD' + PACFudge
'PPD'=(_ppp_マックス_データMTU--ヘッダー)*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は八重奏をビットに変換します(bpsにはConnectRateを仮定するのがあります)。 ConnectRateが1秒あたりのバイトであるなら、8を省略してください。 PACFudgeを必要ではありませんが、PACの総合的な処理オーバヘッドを考慮に入れるのに使用できます。
Hamzeh, et al. Informational [Page 52] RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
Hamzeh、他 1999年7月にプロトコル(PPTP)にトンネルを堀る情報[52ページ]のRFC2637ポイントツーポイント
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.
以下で詳細な提案された適応型のアルゴリズムは、TCP1989実現に基づいていて、[11]で説明されます。 そして、''計算のこの繰り返しを意味する、-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))
デフ[n]はサンプル[n]と等しいです--RTT[n-1]DEV[n]がDEV[n-1]+と等しい、(ベータ*、(| デフ[n]|、--、DEV[n-1)RTT[n]がRTT[n-1]+と等しい(アルファ*デフ[n])ATO[n]=は最大限にします。(MinTimeOut、分(RTT[n]+(キー*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は各繰り返しのときにycalculatedされて、次の繰り返しにおける使用のために格納されます。 初めは、それは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.
キーは、タイムアウトのための利得であり、4に通常設定されます。
Hamzeh, et al. Informational [Page 53] RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
Hamzeh、他 1999年7月にプロトコル(PPTP)にトンネルを堀る情報[53ページ]のRFC2637ポイントツーポイント
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))
RTT[n]=デルタ*RTT[n-1]DEV[n]=DEV[n-1]ATO[n]はMAXと等しいです。(MinTimeOut、分(RTT[n]+(キー*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は進展しないで、またこのシナリオで使用されません。 デルタのための2の値(RTTのための時間の出ている利得要素)は示されます。
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
Hamzeh、他 1999年7月にプロトコル(PPTP)にトンネルを堀る情報[54ページ]のRFC2637ポイントツーポイント
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
コーリーHamzehはParkwayアラメダ、コミュニケーション1275港Bayカリフォルニア 94502を昇ります。
EMail: kory@ascend.com
メール: kory@ascend.com
Gurdeep Singh Pall Microsoft Corporation Redmond, WA
Gurdeepシン・祭服マイクロソフト社レッドモンド(ワシントン)
EMail: gurdeep@microsoft.com
メール: gurdeep@microsoft.com
William Verthein U.S. Robotics/3Com
ウィリアムVerthein USロボティックス/3Com
Jeff Taarud Copper Mountain Networks
ジェフTaarudカッパーマウンテンネットワーク
W. Andrew Little ECI Telematics
W.アンドリューリトルECIテレマティックス
Glen Zorn Microsoft Corporation Redmond, WA
谷間ゾルン・マイクロソフト社レッドモンド(ワシントン)
EMail: glennz@microsoft.com
メール: glennz@microsoft.com
Hamzeh, et al. Informational [Page 55] RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
Hamzeh、他 1999年7月にプロトコル(PPTP)にトンネルを堀る情報[55ページ]のRFC2637ポイントツーポイント
7. References
7. 参照
[1] Hanks, S., Li, T., Farinacci, D. and P. Traina, "Generic Routing
Encapsulation (GRE)", RFC 1701, October 1994.
[1]一かせとS.と李とT.とファリナッチとD.とP.Traina、「一般ルーティングのカプセル化(GRE)」、RFC1701 1994年10月。
[2] Hanks, S., Li, T., Farinacci, D. and P. Traina, "Generic Routing
Encapsulation (GRE) over IPv4 Networks", RFC 1702, October 1994.
[2] ハンクスとS.と李とT.とファリナッチとD.とP.Traina、「IPv4ネットワークの上の一般ルーティングのカプセル化(GRE)」、RFC1702、1994年10月。
[3] Lloyd, B. and W. Simpson, "PPP Authentication Protocols", RFC
1334, October 1992.
[3] ロイドとB.とW.シンプソン、「ppp認証プロトコル」、RFC1334、1992年10月。
[4] Postel, J., "Transmission Control Protocol", STD 7, RFC 793,
September 1981.
[4] ポステル、J.、「通信制御プロトコル」、STD7、RFC793、1981年9月。
[5] Postel, J., "User Data Protocol", STD 6, RFC 768, August 1980.
[5] ポステル、J.、「利用者データプロトコル」、STD6、RFC768、1980年8月。
[6] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700,
October 1994. See also: http://www.iana.org/numbers.html
[6] レイノルズとJ.とJ.ポステル、「規定番号」、STD2、RFC1700、1994年10月。 参照: http://www.iana.org/numbers.html
[7] Simpson, W., editor, "The Point-to-Point Protocol (PPP)", STD
51, RFC 1661, July 1994.
[7] シンプソン、W.、エディタ、「二地点間プロトコル(ppp)」、STD51、RFC1661、1994年7月。
[8] Ethertype for PPP, Reserved with Xerox Corporation.
[8] ゼロックス社と共に予約されたpppのためのEthertype。
[9] Simpson, W., "PPP Challenge Handshake Authentication Protocol
(CHAP)", RFC 1994, August 1996.
[9] シンプソン、W.、「pppチャレンジハンドシェイク式認証プロトコル(やつ)」、RFC1994、1996年8月。
[10] Blunk, L. and J Vollbrecht, "PPP Extensible Authentication
Protocol (EAP)", RFC 2284, March 1998.
[10]BlunkとL.と1998年のJ Vollbrecht、「ppp拡張認証プロトコル(EAP)」、RFC2284行進。
[11] Stevens, R., "TCP/IP Illustrated, Volume 1", p. 300, Addison-
Wesley, 1994.
[11] スティーブンス、R.、「イラスト入りのTCP/IPボリューム1インチ、p。」 300 アディソンウエスリー、1994。
[12] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[12] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
Hamzeh, et al. Informational [Page 56] RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
Hamzeh、他 1999年7月にプロトコル(PPTP)にトンネルを堀る情報[56ページ]のRFC2637ポイントツーポイント
8. Full Copyright Statement
8. 完全な著作権宣言文
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright(C)インターネット協会(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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
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.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Hamzeh, et al. Informational [Page 57]
Hamzeh、他 情報[57ページ]
一覧
スポンサーリンク
