summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc2637.txt
diff options
context:
space:
mode:
authorThomas Voss <mail@thomasvoss.com> 2024-11-27 20:54:24 +0100
committerThomas Voss <mail@thomasvoss.com> 2024-11-27 20:54:24 +0100
commit4bfd864f10b68b71482b35c818559068ef8d5797 (patch)
treee3989f47a7994642eb325063d46e8f08ffa681dc /doc/rfc/rfc2637.txt
parentea76e11061bda059ae9f9ad130a9895cc85607db (diff)
doc: Add RFC documents
Diffstat (limited to 'doc/rfc/rfc2637.txt')
-rw-r--r--doc/rfc/rfc2637.txt3195
1 files changed, 3195 insertions, 0 deletions
diff --git a/doc/rfc/rfc2637.txt b/doc/rfc/rfc2637.txt
new file mode 100644
index 0000000..56e9e0f
--- /dev/null
+++ b/doc/rfc/rfc2637.txt
@@ -0,0 +1,3195 @@
+
+
+
+
+
+
+Network Working Group K. Hamzeh
+Request for Comments: 2637 Ascend Communications
+Category: Informational G. Pall
+ Microsoft Corporation
+ W. Verthein
+ 3Com
+ J. Taarud
+ Copper Mountain Networks
+ W. Little
+ ECI Telematics
+ G. Zorn
+ Microsoft Corporation
+ July 1999
+
+
+ Point-to-Point Tunneling Protocol (PPTP)
+
+Status of this Memo
+
+ This memo provides information for the Internet community. It does
+ not specify an Internet standard of any kind. Distribution of this
+ memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (1999). All Rights Reserved.
+
+IESG Note
+
+ The PPTP protocol was developed by a vendor consortium. The
+ documentation of PPTP is provided as information to the Internet
+ community. The PPP WG is currently defining a Standards Track
+ protocol (L2TP) for tunneling PPP across packet-switched networks.
+
+Abstract
+
+ This document specifies a protocol which allows the Point to Point
+ Protocol (PPP) to be tunneled through an IP network. PPTP does not
+ specify any changes to the PPP protocol but rather describes a new
+ vehicle for carrying PPP. A client-server architecture is defined in
+ order to decouple functions which exist in current Network Access
+ Servers (NAS) and support Virtual Private Networks (VPNs). The PPTP
+ Network Server (PNS) is envisioned to run on a general purpose
+ operating system while the client, referred to as a PPTP Access
+ Concentrator (PAC) operates on a dial access platform. PPTP
+ specifies a call-control and management protocol which allows the
+ server to control access for dial-in circuit switched calls
+ originating from a PSTN or ISDN or to initiate outbound circuit-
+
+
+
+Hamzeh, et al. Informational [Page 1]
+
+RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
+
+
+ switched connections. PPTP uses an enhanced GRE (Generic Routing
+ Encapsulation) mechanism to provide a flow- and congestion-controlled
+ encapsulated datagram service for carrying PPP packets.
+
+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].
+
+ 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.
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 1.1. Protocol Goals and Assumptions . . . . . . . . . . . . . . 4
+ 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
+ 1.3. Protocol Overview . . . . . . . . . . . . . . . . . . . . 6
+ 1.3.1. Control Connection Overview . . . . . . . . . . . . . . 7
+ 1.3.2. Tunnel Protocol Overview . . . . . . . . . . . . . . . . 7
+ 1.4. Message Format and Protocol Extensibility . . . . . . . . 8
+ 2. Control Connection Protocol Specification . . . . . . . . . 10
+ 2.1. Start-Control-Connection-Request . . . . . . . . . . . . . 10
+ 2.2. Start-Control-Connection-Reply . . . . . . . . . . . . . . 12
+ 2.3. Stop-Control-Connection-Request . . . . . . . . . . . . . 15
+ 2.4. Stop-Control-Connection-Reply . . . . . . . . . . . . . . 16
+ 2.5. Echo-Request . . . . . . . . . . . . . . . . . . . . . . . 17
+ 2.6. Echo-Reply . . . . . . . . . . . . . . . . . . . . . . . . 18
+ 2.7. Outgoing-Call-Request . . . . . . . . . . . . . . . . . . 19
+ 2.8. Outgoing-Call-Reply . . . . . . . . . . . . . . . . . . . 22
+ 2.9. Incoming-Call-Request . . . . . . . . . . . . . . . . . . 25
+ 2.10. Incoming-Call-Reply . . . . . . . . . . . . . . . . . . . 28
+ 2.11. Incoming-Call-Connected . . . . . . . . . . . . . . . . . 29
+ 2.12. Call-Clear-Request . . . . . . . . . . . . . . . . . . . 31
+ 2.13. Call-Disconnect-Notify . . . . . . . . . . . . . . . . . 32
+ 2.14. WAN-Error-Notify . . . . . . . . . . . . . . . . . . . . 33
+ 2.15. Set-Link-Info . . . . . . . . . . . . . . . . . . . . . . 35
+ 2.16. General Error Codes . . . . . . . . . . . . . . . . . . . 36
+ 3. Control Connection Protocol Operation . . . . . . . . . . . 36
+ 3.1. Control Connection States . . . . . . . . . . . . . . . . 37
+ 3.1.1. Control Connection Originator (may be PAC or PNS) . . . 37
+ 3.1.2. Control connection Receiver (may be PAC or PNS) . . . . 39
+
+
+
+Hamzeh, et al. Informational [Page 2]
+
+RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
+
+
+ 3.1.3. Start Control Connection Initiation Request Collision . 40
+ 3.1.4. Keep Alives and Timers . . . . . . . . . . . . . . . . . 40
+ 3.2. Call States . . . . . . . . . . . . . . . . . . . . . . . 41
+ 3.2.1. Timing considerations . . . . . . . . . . . . . . . . . 41
+ 3.2.2. Call ID Values . . . . . . . . . . . . . . . . . . . . . 41
+ 3.2.3. Incoming Calls . . . . . . . . . . . . . . . . . . . . . 41
+ 3.2.3.1. PAC Incoming Call States . . . . . . . . . . . . . . . 42
+ 3.2.3.2. PNS Incoming Call States . . . . . . . . . . . . . . . 43
+ 3.2.4. Outgoing Calls . . . . . . . . . . . . . . . . . . . . . 44
+ 3.2.4.1. PAC Outgoing Call States . . . . . . . . . . . . . . . 45
+ 3.2.4.2. PNS Outgoing Call States . . . . . . . . . . . . . . . 46
+ 4. Tunnel Protocol Operation . . . . . . . . . . . . . . . . . 47
+ 4.1. Enhanced GRE header . . . . . . . . . . . . . . . . . . . 47
+ 4.2. Sliding Window Protocol . . . . . . . . . . . . . . . . . 49
+ 4.2.1. Initial Window Size . . . . . . . . . . . . . . . . . . 49
+ 4.2.2. Closing the Window . . . . . . . . . . . . . . . . . . . 49
+ 4.2.3. Opening the Window . . . . . . . . . . . . . . . . . . . 50
+ 4.2.4. Window Overflow . . . . . . . . . . . . . . . . . . . . 50
+ 4.2.5. Multi-packet Acknowledgment . . . . . . . . . . . . . . 50
+ 4.3. Out-of-sequence Packets . . . . . . . . . . . . . . . . . 50
+ 4.4. Acknowledgment Time-Outs . . . . . . . . . . . . . . . . . 51
+ 4.4.1. Calculating Adaptive Acknowledgment Time-Out . . . . . . 53
+ 4.4.2. Congestion Control: Adjusting for Time-Out . . . . . . . 54
+ 5. Security Considerations . . . . . . . . . . . . . . . . . . 54
+ 6. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 55
+ 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 56
+ 8. Full Copyright Statement . . . . . . . . . . . . . . . . . . 57
+
+1. Introduction
+
+ 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:
+
+ 1) Physical native interfacing to PSTN or ISDN and control of
+ external modems or terminal adapters.
+
+ 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.
+
+ 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.
+
+
+
+
+
+Hamzeh, et al. Informational [Page 3]
+
+RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
+
+
+ 2) Logical termination of a Point-to-Point-Protocol (PPP) Link
+ Control Protocol (LCP) session.
+
+ 3) Participation in PPP authentication protocols [3,9,10].
+
+ 4) Channel aggregation and bundle management for PPP Multilink
+ Protocol.
+
+ 5) Logical termination of various PPP network control protocols
+ (NCP).
+
+ 6) Multiprotocol routing and bridging between NAS interfaces.
+
+ 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.
+
+ The decoupling of NAS functions offers these benefits:
+
+ 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.
+
+ 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.
+
+ 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.
+
+1.1. Protocol Goals and Assumptions
+
+ 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.
+
+
+
+
+
+Hamzeh, et al. Informational [Page 4]
+
+RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
+
+
+ PPTP can also be used to tunnel a PPP session over an IP network. In
+ this configuration the PPTP tunnel and the PPP session runs between
+ the same two machines with the caller acting as a PNS.
+
+ 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.
+
+ 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.
+
+1.2. Terminology
+
+ Analog Channel
+
+ A circuit-switched communication path which is intended to carry
+ 3.1 Khz audio in each direction.
+
+ 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.
+
+ 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.
+
+
+
+
+
+
+Hamzeh, et al. Informational [Page 5]
+
+RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
+
+
+ Dial User
+
+ An end-system or router attached to an on-demand PSTN or ISDN
+ which is either the initiator or recipient of a call.
+
+ Network Access Server (NAS)
+
+ A device providing temporary, on-demand network access to users.
+ This access is point-to-point using PSTN or ISDN lines.
+
+ PPTP Access Concentrator (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.
+
+ PPTP Network Server (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.
+
+ 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.
+
+ 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.
+
+1.3. Protocol Overview
+
+ 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.
+
+
+
+Hamzeh, et al. Informational [Page 6]
+
+RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
+
+
+1.3.1. Control Connection Overview
+
+ 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.
+
+ 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.
+
+ 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
+
+ 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.
+
+1.3.2. Tunnel Protocol Overview
+
+ 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.
+
+
+
+
+
+
+Hamzeh, et al. Informational [Page 7]
+
+RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
+
+
+ In this manner, PPP packets are multiplexed and demultiplexed over a
+ single tunnel between a given PNS-PAC pair. The value to use in the
+ key field is established by the call establishment procedure which
+ takes place on the control connection.
+
+ 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.
+
+1.4. Message Format and Protocol Extensibility
+
+ 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.
+
+ 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".
+
+ Two Control Connection message types are indicated by the PPTP
+ Message Type field:
+
+ 1 - Control Message
+ 2 - Management Message
+
+ 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.
+
+ 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.
+
+
+
+
+Hamzeh, et al. Informational [Page 8]
+
+RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
+
+
+The currently defined Control Messages, grouped by function, are:
+
+ Control Message Message Code
+
+ (Control Connection Management)
+
+ Start-Control-Connection-Request 1
+ Start-Control-Connection-Reply 2
+ Stop-Control-Connection-Request 3
+ Stop-Control-Connection-Reply 4
+ Echo-Request 5
+ Echo-Reply 6
+
+ (Call Management)
+
+ Outgoing-Call-Request 7
+ Outgoing-Call-Reply 8
+ Incoming-Call-Request 9
+ Incoming-Call-Reply 10
+ Incoming-Call-Connected 11
+ Call-Clear-Request 12
+ Call-Disconnect-Notify 13
+
+ (Error Reporting)
+
+ WAN-Error-Notify 14
+
+ (PPP Session Control)
+
+ Set-Link-Info 15
+
+ The Start-Control-Connection-Request and -Reply messages determine
+ which version of the Control Connection protocol will be used. The
+ version number field carried in these messages consists of a version
+ number in the high octet and a revision number in the low octet.
+ Version handling is described in section 2. The current value of the
+ version number field is 0x0100 for version 1, revision 0.
+
+ The use of the GRE-like header for the encapsulation of PPP user
+ packets is specified in section 4.1.
+
+ The MTU for the user data packets encapsulated in GRE is 1532 octets,
+ not including the IP and GRE headers.
+
+
+
+
+
+
+
+
+Hamzeh, et al. Informational [Page 9]
+
+RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
+
+
+2. Control Connection Protocol Specification
+
+ 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.
+
+ 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.
+
+2.1. Start-Control-Connection-Request
+
+ The Start-Control-Connection-Request is a PPTP control message used
+ to establish the control connection between a PNS and a PAC. Each
+ PNS-PAC pair requires a dedicated control connection to be
+ established. A control connection must be established before any
+ other PPTP messages can be issued. The establishment of the control
+ connection can be initiated by either the PNS or PAC. A procedure
+ which handles the occurrence of a collision between PNS and PAC
+ Start-Control-Connection-Requests is described in section 3.1.3.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hamzeh, et al. Informational [Page 10]
+
+RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
+
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Length | PPTP Message Type |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Magic Cookie |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Control Message Type | Reserved0 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Protocol Version | Reserved1 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Framing Capabilities |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Bearer Capabilities |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Maximum Channels | Firmware Revision |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | |
+ + Host Name (64 octets) +
+ | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | |
+ + Vendor String (64 octets) +
+ | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Length Total length in octets of this PPTP
+ message, including the entire PPTP
+ header.
+
+ PPTP Message Type 1 for Control Message.
+
+ Magic Cookie 0x1A2B3C4D. This constant value is used
+ as a sanity check on received messages
+ (see section 1.4).
+
+ Control Message Type 1 for Start-Control-Connection-Request.
+
+ Reserved0 This field MUST be 0.
+
+ Protocol Version The version of the PPTP protocol that the
+ sender wishes to use.
+
+ Reserved1 This field MUST be 0.
+
+
+
+
+
+
+
+Hamzeh, et al. Informational [Page 11]
+
+RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
+
+
+ Framing Capabilities A set of bits indicating the type of framing
+ that the sender of this message can provide.
+ The currently defined bit settings are:
+
+ 1 - Asynchronous Framing supported
+
+ 2 - Synchronous Framing supported
+
+ Bearer Capabilities A set of bits indicating the bearer
+ capabilities that the sender of this message
+ can provide. The currently defined bit
+ settings are:
+
+ 1 - Analog access supported
+
+ 2 - Digital access supported
+
+ 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.
+
+ 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.
+
+ 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.
+
+ 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.
+
+2.2. Start-Control-Connection-Reply
+
+ The Start-Control-Connection-Reply is a PPTP control message sent in
+ reply to a received Start-Control-Connection-Request message. This
+ message contains a result code indicating the result of the control
+ connection establishment attempt.
+
+
+
+Hamzeh, et al. Informational [Page 12]
+
+RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
+
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Length | PPTP Message Type |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Magic Cookie |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Control Message Type | Reserved0 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Protocol Version | Result Code | Error Code |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Framing Capability |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Bearer Capability |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Maximum Channels | Firmware Revision |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | |
+ + Host Name (64 octets) +
+ | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | |
+ + Vendor String (64 octets) +
+ | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Length Total length in octets of this PPTP message,
+ including the entire PPTP header.
+
+ PPTP Message Type 1 for Control Message.
+
+ Magic Cookie 0x1A2B3C4D.
+
+ Control Message Type 2 for Start-Control-Connection-Reply.
+
+ Reserved0 This field MUST be 0.
+
+ Protocol Version The version of the PPTP protocol that the
+ sender wishes to use.
+
+ Result Code Indicates the result of the command channel
+ establishment attempt. Current valid Result
+ Code values are:
+
+ 1 - Successful channel establishment
+
+ 2 - General error -- Error Code
+ indicates the problem
+
+
+
+Hamzeh, et al. Informational [Page 13]
+
+RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
+
+
+ 3 - Command channel already exists;
+
+ 4 - Requester is not authorized to
+ establish a command channel
+
+ 5 - The protocol version of the
+ requester is not supported
+
+ 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.
+
+ Framing Capabilities A set of bits indicating the type of framing
+ that the sender of this message can provide.
+ The currently defined bit settings are:
+
+ 1 - Asynchronous Framing supported
+
+ 2 - Synchronous Framing supported.
+
+ Bearer Capabilities A set of bits indicating the bearer
+ capabilities that the sender of this message
+ can provide. The currently defined bit
+ settings are:
+
+ 1 - Analog access supported
+
+ 2 - Digital access supported
+
+ 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.
+
+ 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.
+
+
+
+
+
+
+
+
+Hamzeh, et al. Informational [Page 14]
+
+RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
+
+
+ Host Name A 64 octet field containing the DNS name of
+ the issuing PAC or PNS. If less than 64
+ octets in length, the remainder of this
+ field SHOULD be filled with octets of value
+ 0.
+
+ 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.
+
+2.3. Stop-Control-Connection-Request
+
+ The Stop-Control-Connection-Request is a PPTP control message sent by
+ one peer of a PAC-PNS control connection to inform the other peer
+ that the control connection should be closed. In addition to closing
+ the control connection, all active user calls are implicitly cleared.
+ The reason for issuing this request is indicated in the Reason field.
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Length | PPTP Message Type |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Magic Cookie |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Control Message Type | Reserved0 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Reason | Reserved1 | Reserved2 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Length Total length in octets of this PPTP message,
+ including the entire PPTP header.
+
+ PPTP Message Type 1 for Control Message.
+
+ Magic Cookie 0x1A2B3C4D.
+
+ Control Message Type 3 for Stop-Control-Connection-Request.
+
+ Reserved0 This field MUST be 0.
+
+ Reason Indicates the reason for the control
+ connection being closed. Current valid
+ Reason values are:
+
+
+
+Hamzeh, et al. Informational [Page 15]
+
+RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
+
+
+ 1 (None) - General request to clear
+ control connection
+
+ 2 (Stop-Protocol) - Can't support
+ peer's version of the protocol
+
+ 3 (Stop-Local-Shutdown) - Requester is
+ being shut down
+
+ Reserved1, Reserved2 These fields MUST be 0.
+
+2.4. Stop-Control-Connection-Reply
+
+ The Stop-Control-Connection-Reply is a PPTP control message sent by
+ one peer of a PAC-PNS control connection upon receipt of a Stop-
+ Control-Connection-Request from the other peer.
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Length | PPTP Message Type |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Magic Cookie |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Control Message Type | Reserved0 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Result Code | Error Code | Reserved1 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Length Total length in octets of this PPTP message,
+ including the entire PPTP header.
+
+ PPTP Message Type 1 for Control Message.
+
+ Magic Cookie 0x1A2B3C4D.
+
+ Control Message Type 4 for Stop-Control-Connection-Reply.
+
+ Reserved0 This field MUST be 0.
+
+ Result Code Indicates the result of the attempt to close
+ the control connection. Current valid Result
+ Code values are:
+
+
+
+
+
+
+
+
+Hamzeh, et al. Informational [Page 16]
+
+RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
+
+
+ 1 (OK) - Control connection closed
+
+ 2 (General Error) - Control connection
+ not closed for reason indicated in
+ 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.
+
+ Reserved1 This field MUST be 0.
+
+2.5. Echo-Request
+
+ 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.
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Length | PPTP Message Type |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Magic Cookie |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Control Message Type | Reserved0 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Identifier |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Length Total length in octets of this PPTP message,
+ including the entire PPTP header.
+
+ PPTP Message Type 1 for Control Message.
+
+ Magic Cookie 0x1A2B3C4D.
+
+ Control Message Type 5 for Echo-Request.
+
+ Reserved0 This field MUST be 0.
+
+
+
+
+
+
+Hamzeh, et al. Informational [Page 17]
+
+RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
+
+
+ Identifier A value set by the sender of the Echo-
+ Request that is used to match the reply with
+ the corresponding request.
+
+2.6. Echo-Reply
+
+ 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.
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Length | PPTP Message Type |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Magic Cookie |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Control Message Type | Reserved0 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Identifier |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Result Code | Error Code | Reserved1 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Length Total length in octets of this PPTP message,
+ including the entire PPTP header.
+
+ PPTP Message Type 1 for Control Message.
+
+ Magic Cookie 0x1A2B3C4D.
+
+ Control Message Type 6 for Echo-Reply.
+
+ Reserved0 This field MUST be 0.
+
+ Identifier The contents of the identify field from the
+ received Echo-Request is copied to this
+ field.
+
+ Result Code Indicates the result of the receipt of the
+ Echo-Request. Current valid Result Code
+ values are:
+
+ 1 (OK) - The Echo-Reply is valid
+
+ 2 (General Error) - Echo-Request not
+ accepted for the reason indicated in
+ Error Code
+
+
+
+Hamzeh, et al. Informational [Page 18]
+
+RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
+
+
+ Error Code This field is set to 0 unless a "General
+ Error" condition exists, in which case
+ Result Code is set to 2 and this field is
+ set to the value corresponding to the
+ general error condition as specified in
+ section 2.2.
+
+ Reserved1 This field MUST be 0.
+
+2.7. Outgoing-Call-Request
+
+ 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hamzeh, et al. Informational [Page 19]
+
+RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
+
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Length | PPTP Message Type |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Magic Cookie |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Control Message Type | Reserved0 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Call ID | Call Serial Number |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Minimum BPS |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Maximum BPS |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Bearer Type |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Framing Type |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Packet Recv. Window Size | Packet Processing Delay |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Phone Number Length | Reserved1 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | |
+ + Phone Number (64 octets) +
+ | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | |
+ + Subaddress (64 octets) +
+ | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Length Total length in octets of this PPTP message,
+ including the entire PPTP header.
+
+ PPTP Message Type 1 for Control Message.
+
+ Magic Cookie 0x1A2B3C4D.
+
+ Control Message Type 7 for Outgoing-Call-Request.
+
+ Reserved0 This field MUST be 0.
+
+
+
+
+
+
+
+
+
+Hamzeh, et al. Informational [Page 20]
+
+RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
+
+
+ Call ID A unique identifier, unique to a particular
+ PAC-PNS pair assigned by the PNS to this
+ session. It is used to multiplex and
+ demultiplex data sent over the tunnel
+ between the PNS and PAC involved in this
+ session.
+
+ 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.
+
+ Minimum BPS The lowest acceptable line speed (in
+ bits/second) for this session.
+
+ Maximum BPS The highest acceptable line speed (in
+ bits/second) for this session.
+
+ Bearer Type A value indicating the bearer capability
+ required for this outgoing call. The
+ currently defined values are:
+
+ 1 - Call to be placed on an analog
+ channel
+
+ 2 - Call to be placed on a digital
+ channel
+
+ 3 - Call can be placed on any type of
+ channel
+
+ Framing Type A value indicating the type of PPP framing
+ to be used for this outgoing call.
+
+ 1 - Call to use Asynchronous framing
+
+ 2 - Call to use Synchronous framing
+
+ 3 - Call can use either type of
+ framing
+
+ Packet Recv. Window Size The number of received data packets the PNS
+ will buffer for this session.
+
+
+
+
+Hamzeh, et al. Informational [Page 21]
+
+RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
+
+
+ Packet Processing Delay A measure of the packet processing delay
+ that might be imposed on data sent to the
+ PNS from the PAC. This value is specified
+ in units of 1/10 seconds. For the PNS this
+ number should be very small. See section
+ 4.4 for a description of how this value is
+ determined and used.
+
+ Phone Number Length The actual number of valid digits in the
+ Phone Number field.
+
+ Reserved1 This field MUST be 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.
+
+ 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.
+
+2.8. Outgoing-Call-Reply
+
+ 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hamzeh, et al. Informational [Page 22]
+
+RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
+
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Length | PPTP Message Type |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Magic Cookie |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Control Message Type | Reserved0 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Call ID | Peer's Call ID |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Result Code | Error Code | Cause Code |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Connect Speed |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Packet Recv. Window Size | Packet Processing Delay |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Physical Channel ID |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Length Total length in octets of this PPTP message,
+ including the entire PPTP header.
+
+ PPTP Message Type 1 for Control Message.
+
+ Magic Cookie 0x1A2B3C4D.
+
+ Control Message Type 8 for Outgoing-Call-Reply.
+
+ Reserved0 This field MUST be 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.
+
+ 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.
+
+
+
+
+
+
+
+Hamzeh, et al. Informational [Page 23]
+
+RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
+
+
+ Result Code This value indicates the result of the
+ Outgoing-Call-Request attempt. Currently
+ valid values are:
+
+ 1 (Connected) - Call established with
+ no errors
+
+ 2 (General Error) - Outgoing Call not
+ established for the reason indicated
+ in Error Code
+
+ 3 (No Carrier) - Outgoing Call failed
+ due to no carrier detected
+
+ 4 (Busy) - Outgoing Call failed due to
+ detection of a busy signal
+
+ 5 (No Dial Tone) - Outgoing Call
+ failed due to lack of a dial tone
+
+ 6 (Time-out) - Outgoing Call was not
+ established within time allotted by
+ PAC
+
+ 7 (Do Not Accept) - Outgoing Call
+ administratively prohibited
+
+ 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.
+
+ 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.
+
+ Connect Speed The actual connection speed used, in
+ bits/second.
+
+ Packet Recv. Window Size The number of received data packets the PAC
+ will buffer for this session.
+
+
+
+
+
+
+
+Hamzeh, et al. Informational [Page 24]
+
+RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
+
+
+ Packet Processing Delay A measure of the packet processing delay
+ that might be imposed on data sent to the
+ PAC from the PNS. This value is specified
+ in units of 1/10 seconds. For the PAC, this
+ number is related to the size of the buffer
+ used to hold packets to be sent to the
+ client and to the speed of the link to the
+ client. This value should be set to the
+ maximum delay that can normally occur
+ between the time a packet arrives at the PAC
+ and is delivered to the client. See section
+ 4.4 for an example of how this value is
+ determined and used.
+
+ 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.
+
+2.9. Incoming-Call-Request
+
+ 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.
+
+ 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hamzeh, et al. Informational [Page 25]
+
+RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
+
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Length | PPTP Message Type |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Magic Cookie |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Control Message Type | Reserved0 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Call ID | Call Serial Number |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Call Bearer Type |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Physical Channel ID |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Dialed Number Length | Dialing Number Length |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | |
+ + Dialed Number (64 octets) +
+ | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | |
+ + Dialing Number (64 octets) +
+ |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | |
+ + Subaddress (64 octets) +
+ | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Length Total length in octets of this PPTP message,
+ including the entire PPTP header.
+
+ PPTP Message Type 1 for Control Message.
+
+ Magic Cookie 0x1A2B3C4D.
+
+ Control Message Type 9 for Incoming-Call-Request.
+
+ Reserved0 This field MUST be 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.
+
+
+
+
+
+Hamzeh, et al. Informational [Page 26]
+
+RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
+
+
+ Call Serial Number An identifier assigned by the PAC to this
+ session for the purpose of identifying this
+ particular session in logged session
+ information. Unlike the Call ID, both the
+ PNS and PAC associate the same Call Serial
+ Number to a given session. The combination
+ of IP address and call serial number should
+ be unique.
+
+ Bearer Type A value indicating the bearer capability
+ used for this incoming call. Currently
+ defined values are:
+
+ 1 - Call is on an analog channel
+
+ 2 - Call is on a digital channel
+
+ 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.
+
+ Dialed Number Length The actual number of valid digits in the
+ Dialed Number field.
+
+ Dialing Number Length The actual number of valid digits in the
+ Dialing Number field.
+
+ Dialed Number The number that was dialed by the caller.
+ For ISDN and analog calls this field is an
+ ASCII string. If the Dialed Number is less
+ than 64 octets in length, the remainder of
+ this field is filled with octets of value 0.
+
+ 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.
+
+ 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.
+
+
+
+
+
+
+
+
+Hamzeh, et al. Informational [Page 27]
+
+RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
+
+
+2.10. Incoming-Call-Reply
+
+ 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.
+
+ 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.
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Length | PPTP Message Type |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Magic Cookie |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Control Message Type | Reserved0 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Call ID | Peer's Call ID |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Result Code | Error Code | Packet Recv. Window Size |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Packet Transmit Delay | Reserved1 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Length Total length in octets of this PPTP message,
+ including the entire PPTP header.
+
+ PPTP Message Type 1 for Control Message.
+
+ Magic Cookie 0x1A2B3C4D.
+
+ Control Message Type 10 for Incoming-Call-Reply.
+
+ Reserved0 This field MUST be 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.
+
+ Peer's Call ID This field is set to the value received in
+ the Call ID field of the corresponding
+ Incoming-Call-Request message. It is used by
+
+
+
+Hamzeh, et al. Informational [Page 28]
+
+RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
+
+
+ the PAC to match the Incoming-Call-Reply
+ with the Incoming-Call-Request it issued.
+ This value is included in the GRE header of
+ transmitted data packets for this session.
+
+ Result Code This value indicates the result of the
+ Incoming-Call-Request attempt. Current
+ valid Result Code values are:
+
+ 1 (Connect) - The PAC should answer
+ the incoming call
+
+ 2 (General Error) - The Incoming Call
+ should not be established due to the
+ reason indicated in Error Code
+
+ 3 (Do Not Accept) - The PAC should not
+ accept the incoming call. It should
+ hang up or issue a busy indication
+
+ 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.
+
+ Packet Recv. Window Size The number of received data packets the PAC
+ will buffer for this session.
+
+ 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.
+
+ Reserved1 This field MUST be 0.
+
+2.11. Incoming-Call-Connected
+
+ 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.
+
+ This message is the third in the three-way handshake used by PPTP for
+ establishing incoming calls. It provides a mechanism for providing
+ the PNS with additional information about the call that cannot, in
+
+
+
+Hamzeh, et al. Informational [Page 29]
+
+RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
+
+
+ general, be obtained at the time the Incoming-Call-Request is issued
+ by the PAC.
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Length | PPTP Message Type |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Magic Cookie |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Control Message Type | Reserved0 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Peer's Call ID | Reserved1 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Connect Speed |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Packet Recv. Window Size | Packet Transmit Delay |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Framing Type |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Length Total length in octets of this PPTP message,
+ including the entire PPTP header.
+
+ PPTP Message Type 1 for Control Message.
+
+ Magic Cookie 0x1A2B3C4D.
+
+ Control Message Type 11 for Incoming-Call-Connected.
+
+ Reserved0 This field MUST be 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.
+
+ Connect Speed The actual connection speed used, in
+ bits/second.
+
+ Packet Recv. Window Size The number of received data packets the PAC
+ will buffer for this session.
+
+ 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.
+
+
+
+Hamzeh, et al. Informational [Page 30]
+
+RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
+
+
+ Framing Type A value indicating the type of PPP framing
+ being used by this incoming call.
+
+ 1 - Call uses asynchronous framing
+
+ 2 - Call uses synchronous framing
+
+2.12. Call-Clear-Request
+
+ 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.
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Length | PPTP Message Type |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Magic Cookie |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Control Message Type | Reserved0 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Call ID | Reserved1 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Length Total length in octets of this PPTP message,
+ including the entire PPTP header.
+
+ PPTP Message Type 1 for Control Message.
+
+ Magic Cookie 0x1A2B3C4D.
+
+ Control Message Type 12 for Call-Clear-Request.
+
+ Reserved0 This field MUST be 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.
+
+ Reserved1 This field MUST be 0.
+
+
+
+
+
+
+Hamzeh, et al. Informational [Page 31]
+
+RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
+
+
+2.13. Call-Disconnect-Notify
+
+ 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.
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Length | PPTP Message Type |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Magic Cookie |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Control Message Type | Reserved0 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Call ID | Result Code | Error Code |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Cause Code | Reserved1 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | |
+ + Call Statistics (128 octets) +
+ | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Length Total length in octets of this PPTP message,
+ including the entire PPTP header.
+
+ PPTP Message Type 1 for Control Message.
+
+ Magic Cookie 0x1A2B3C4D.
+
+ Control Message Type 13 for Call-Disconnect-Notify.
+
+ Reserved0 This field MUST be 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.
+
+
+
+
+
+
+
+
+
+Hamzeh, et al. Informational [Page 32]
+
+RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
+
+
+ Result Code This value indicates the reason for the
+ disconnect. Current valid Result Code values
+ are:
+
+ 1 (Lost Carrier) - Call disconnected
+ due to loss of carrier
+
+ 2 (General Error) - Call disconnected
+ for the reason indicated in Error
+ Code
+
+ 3 (Admin Shutdown) - Call disconnected
+ for administrative reasons
+
+ 4 (Request) - Call disconnected due to
+ received Call-Clear-Request
+
+ Error Code This field is set to 0 unless a "General
+ Error" condition exists, in which case the
+ Result Code is set to 2 and this field is
+ set to the value corresponding to the
+ general error condition as specified in
+ section 2.2.
+
+ 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.
+
+ 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.
+
+2.14. WAN-Error-Notify
+
+ 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.
+
+
+
+
+
+
+
+Hamzeh, et al. Informational [Page 33]
+
+RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
+
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Length | PPTP Message Type |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Magic Cookie |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Control Message type | Reserved0 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Peer's Call ID | Reserved1 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | CRC Errors |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Framing Errors |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Hardware Overruns |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Buffer Overruns |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Time-out Errors |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Alignment Errors |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Length Total length in octets of this PPTP message,
+ including the entire PPTP header.
+
+ PPTP Message Type 1 for Control Message.
+
+ Magic Cookie 0x1A2B3C4D.
+
+ Control Message Type 14 for WAN-Error-Notify.
+
+ Reserved0 This field MUST be 0.
+
+ Peer's Call ID Th Call ID assigned by the PNS to this call.
+
+ CRC Errors Number of PPP frames received with CRC
+ errors since session was established.
+
+ Framing Errors Number of improperly framed PPP packets
+ received.
+
+ Hardware Overruns Number of receive buffer over-runs since
+ session was established.
+
+ Buffer Overruns Number of buffer over-runs detected since
+ session was established.
+
+
+
+Hamzeh, et al. Informational [Page 34]
+
+RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
+
+
+ Time-out Errors Number of time-outs since call was
+ established.
+
+ Alignment Errors Number of alignment errors since call was
+ established.
+
+2.15. Set-Link-Info
+
+ 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.
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Length | PPTP Message Type |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Magic Cookie |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Control Message type | Reserved0 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Peer's Call ID | Reserved1 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Send ACCM |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Receive ACCM |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Length Total length in octets of this PPTP message,
+ including the entire PPTP header.
+
+ PPTP Message Type 1 for Control Message.
+
+ Magic Cookie 0x1A2B3C4D.
+
+ Control Message Type 15 for Set-Link-Info.
+
+ Reserved0 This field MUST be 0.
+
+ Peer's Call ID The value of the Call ID assigned by the PAC
+ to this call.
+
+ Reserved1 This field MUST be 0.
+
+
+
+
+
+
+Hamzeh, et al. Informational [Page 35]
+
+RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
+
+
+ Send ACCM The send ACCM value the client should use to
+ process outgoing PPP packets. The default
+ value used by the client until this message
+ is received is 0XFFFFFFFF. See [7].
+
+ 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].
+
+2.16. General Error Codes
+
+ 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:
+
+ 0 (None) - No general error
+
+ 1 (Not-Connected) - No control connection exists yet for this
+ PAC-PNS pair
+
+ 2 (Bad-Format) - Length is wrong or Magic Cookie value is
+ incorrect
+
+ 3 (Bad-Value) - One of the field values was out of range or
+ reserved field was non-zero
+
+ 4 (No-Resource) - Insufficient resources to handle this command
+ now
+
+ 5 (Bad-Call ID) - The Call ID is invalid in this context
+
+ 6 (PAC-Error) - A generic vendor-specific error occurred in
+ the PAC
+
+3. Control Connection Protocol Operation
+
+ 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.
+
+
+
+Hamzeh, et al. Informational [Page 36]
+
+RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
+
+
+ Some error recovery procedures are common to all states of the
+ control connection. If an expected reply does not arrive within 60
+ seconds, the control connection is closed, unless otherwise
+ specified. Appropriate logging should be implemented for easy
+ determination of the problems and the reasons for closing the control
+ connection.
+
+ Receipt of an invalid or malformed Control Connection message should
+ be logged appropriately, and the control connection should be closed
+ and restarted to ensure recovery into a known state.
+
+3.1. Control Connection States
+
+ 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.
+
+3.1.1. Control Connection Originator (may be PAC or PNS)
+
+ TCP Open Indication
+ /Send Start Control
+ Connection Request +-----------------+
+ +------------------------------------>| wait_ctl_reply |
+ | +-----------------+
+ | Collision/See (4.1.3) Close TCP V V V Receive Start Ctl
+ | +-------------------------------+ | | Connection Reply
+ | | | | Version OK
+ ^ V | V
++-----------------+ Receive Start Ctl | +-----------------+
+| idle | Connection Reply | | established |
++-----------------+ Version Not OK | +-----------------+
+ ^ | V Local Terminate
+ | Receive Stop Control | | /Send Stop
+ | Connection Request | | Control Request
+ | /Send Stop Control Reply V V
+ | Close TCP +-----------------+
+ +-------------------------------------| wait_stop_reply |
+ +-----------------+
+
+
+
+
+
+
+
+
+
+Hamzeh, et al. Informational [Page 37]
+
+RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
+
+
+ idle
+ The control connection originator attempts to open a TCP
+ connection to the peer during idle state. When the TCP connection
+ is open, the originator transmits a send Start-Control-
+ Connection-Request and then enters the wait_ctl_reply state.
+
+ 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.
+
+ 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.
+
+ 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.
+
+ 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.
+
+ wait_stop_reply
+ If a Stop-Control-Connection-Reply is received, the TCP connection
+ SHOULD be closed and the control connection becomes idle.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hamzeh, et al. Informational [Page 38]
+
+RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
+
+
+3.1.2. Control connection Receiver (may be PAC or PNS)
+
+Receive Start Control Connection Request
+Version Not OK/Send Start Control Connection
+Reply with Error
+ +--------+
+ | | Receive Control Connection Request Version OK
+ | | /Send Start Control Connection Reply
+ | | +----------------------------------------+
+ ^ V ^ V
++-----------------+ Receive Start Ctl +-----------------+
+| Idle | Connection Request | Established |
++-----------------+ /Send Stop Reply +-----------------+
+ ^ ^ Close TCP V V Local Terminate
+ | +-------------------------------------+ | /Send Stop
+ | | Control Conn.
+ | V Request
+ | +-----------------+
+ +-------------------------------------| Wait-Stop-Reply |
+ Receive Stop Control +-----------------+
+ Connection Reply
+ /Close TCP
+
+ idle
+ The control connection receiver waits for a TCP open attempt on
+ port 1723. When notified of an open TCP connection, it should
+ prepare to receive PPTP messages. When a Start-Control-
+ Connection-Request is received its version field should be
+ examined. If the version is earlier than the receiver's version
+ and the earlier version can be supported by the receiver, the
+ receiver SHOULD send a Start-Control-Connection-Reply. If the
+ version is earlier than the receiver's version and the version
+ cannot be supported, the receiver SHOULD send a Start-Connection-
+ Reply message, close the TCP connection and remain in the idle
+ state. If the receiver's version is the same as earlier than the
+ peer's, the receiver SHOULD send a Start-Control-Connection-Reply
+ with the receiver's version and enter the established state.
+
+ 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.
+
+
+
+
+
+
+
+Hamzeh, et al. Informational [Page 39]
+
+RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
+
+
+ If the originator receives a Stop-Control-Connection-Request it
+ SHOULD send a Stop-Control-Connection-Reply and close the TCP
+ connection, making sure that the final TCP information has been
+ "pushed" properly.
+
+ wait_stop_reply
+ If a Stop-Control-Connection-Reply is received, the TCP connection
+ SHOULD be closed and the control connection becomes idle.
+
+3.1.3. Start Control Connection Initiation Request Collision
+
+ 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.
+
+ 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.
+
+3.1.4. Keep Alives and Timers
+
+ A control connection SHOULD be closed by closing the underlying TCP
+ connection under the following circumstances:
+
+ 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.
+
+ 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.
+
+
+
+
+
+Hamzeh, et al. Informational [Page 40]
+
+RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
+
+
+3.2. Call States
+
+3.2.1. Timing considerations
+
+ 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.
+
+ 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.
+
+ 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.
+
+3.2.2. Call ID Values
+
+ 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.
+
+ A session is defined by the triple (PAC, PNS, Call ID).
+
+3.2.3. Incoming Calls
+
+ An Incoming-Call-Request message is generated by the PAC when an
+ associated telephone line rings. The PAC selects a Call ID and serial
+ number and indicates the call bearer type. Modems should always
+ indicate analog call type. ISDN calls should indicate digital when
+ unrestricted digital service or rate adaption is used and analog if
+
+
+
+
+
+Hamzeh, et al. Informational [Page 41]
+
+RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
+
+
+ digital modems are involved. Dialing number, dialed number, and
+ subaddress may be included in the message if they are available from
+ the telephone network.
+
+ 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:
+
+ - 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.
+
+ 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.
+
+3.2.3.1. PAC Incoming Call States
+
+ Ring/Send Incoming Call Request +-----------------+
+ +----------------------------------------->| wait_reply |
+ | +-----------------+
+ | Receive Incoming Call Reply V V V
+ | Not Accepting | | | Receive Incoming
+ | +--------------------------------+ | | Call Reply Accept-
+ | | +------------------------------+ | ing/Answer call;
+ | | | Abort/Send Call | Send Call
+ ^ V V Disconnect Notify V Connected
++-----------------+ +-----------------+
+| idle |<-----------------------------| established |
++-----------------+ Receive Clear Call Request +-----------------+
+ or telco call dropped
+ or local disconnect
+ /Send Call Disconnect Notify
+
+
+
+
+
+
+Hamzeh, et al. Informational [Page 42]
+
+RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
+
+
+The states associated with the PAC for incoming calls are:
+
+ 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.
+
+ 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.
+
+ established
+ Data is exchanged over the tunnel. The call may be cleared
+ following:
+
+ An event on the telco connection. The PAC sends a
+ Call-Disconnect-Notify message
+
+ Receipt of a Call-Clear-Request. The PAC sends a
+ Call-Disconnect-Notify message
+
+ A local reason. The PAC sends a Call-Disconnect-Notify message.
+
+3.2.3.2. PNS Incoming Call States
+
+ Receive Incoming Call Request
+ /Send Incoming Call Reply +-----------------+
+ Not Accepting if Error | Wait-Connect |
+ +-----+ +-----------------+
+ | | Receive Incoming Call Req. ^ V V
+ | | /Send Incoming Call Reply OK | | | Receive Incoming
+ | | +--------------------------------+ | | Call Connect
+ ^ V ^ V------------------------------+ V
++-----------------+ Receive Call Disconnect +-----------------+
+| Idle | Notify +- | Established |
++-----------------+ | +-----------------+
+ ^ ^ | V Local Terminate
+ | +----------------------------+ | /Send Call Clear
+ | Receive Call Disconnect | Request
+ | Notify V
+ | +-----------------+
+ +--------------------------------------| Wait-Disconnect |
+ Receive Call Disconnect +-----------------+
+ Notify
+
+
+
+Hamzeh, et al. Informational [Page 43]
+
+RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
+
+
+The states associated with the PNS for incoming calls are:
+
+ 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.
+
+ 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.
+
+ 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.
+
+ wait_disconnect
+ Once a Call-Disconnect-Notify is received the session moves back
+ to the idle state.
+
+3.2.4. Outgoing Calls
+
+ 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:
+
+ The call has been successfully connected
+
+ A call failure has occurred for reasons such as: no interfaces are
+ available for dial-out, the called party is busy or does not
+ answer, or no dial tone is detected on the interface chosen for
+ dialing
+
+
+
+
+
+
+Hamzeh, et al. Informational [Page 44]
+
+RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
+
+
+3.2.4.1. PAC Outgoing Call States
+
+Receive Outgoing Call Request in Error
+/Send Outgoing Call Reply with Error
+ |--------+
+ | | Receive Outgoing Call Request No Error
+ | | /Off Hook; Dial
+ | | +-----------------------------------------
+ ^ V ^ V
++-----------------+ Incomplete Call +-----------------+
+| idle | /Send Outgoing Call | wait_cs_ans |
++-----------------+ Reply with Error +-----------------+
+ ^ ^ or Recv. Call Clear Req. V V Telco Answer
+ | | /Send Disconnect Notify| | /Send Outgoing
+ | +-------------------------------------+ | Call Reply.
+ | V
+ | +-----------------+
+ +-------------------------------------| established |
+ Receive Call Clear Request +-----------------+
+ or local terminate
+ or telco disconnect
+ /Hangup call and send
+ Call Disconnect Notify
+
+ The states associated with the PAC for outgoing calls are:
+
+ 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.
+
+ 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.
+
+ 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.
+
+
+
+
+
+Hamzeh, et al. Informational [Page 45]
+
+RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
+
+
+3.2.4.2. PNS Outgoing Call States
+
+ Open Indication Abort/Send
+ /Send Outgoing Call Call Clear
+ Request +-----------------+Request
+ +-------------------------------->| Wait-Reply |----------+
+ | +-----------------+ |
+ | Receive Outgoing Call Reply V V Receive Outgoing |
+ | with Error | | Call Reply |
+ | +-------------------------------+ | No Error |
+ ^ V V |
++-----------------+ +-----------------+ |
+| Idle |<-----------------------------| Established | |
++-----------------+ Receive Call Disconnect +-----------------+ |
+ ^ Notify V Local Terminate |
+ | | /Send Call Clear |
+ | | Request |
+ | Receive Call Disconnect V |
+ | Notify +-----------------+ |
+ +---------------------------------| Wait-Disconnect |<---------+
+ +-----------------+
+
+The states associated with the PNS for outgoing calls are:
+
+ idle
+ An Outgoing-Call-Request message is sent to the PAC and the
+ session moves into the wait_reply state.
+
+ 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.
+
+ 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.
+
+ 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.
+
+
+
+
+
+
+Hamzeh, et al. Informational [Page 46]
+
+RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
+
+
+4. Tunnel Protocol Operation
+
+ 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:
+
+ +--------------------------------+
+ | Media Header |
+ +--------------------------------+
+ | IP Header |
+ +--------------------------------+
+ | GRE Header |
+ +--------------------------------+
+ | PPP Packet |
+ +--------------------------------+
+
+4.1. Enhanced GRE header
+
+ 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:
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |C|R|K|S|s|Recur|A| Flags | Ver | Protocol Type |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Key (HW) Payload Length | Key (LW) Call ID |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Sequence Number (Optional) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Acknowledgment Number (Optional) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+
+
+
+
+Hamzeh, et al. Informational [Page 47]
+
+RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
+
+
+ C
+ (Bit 0) Checksum Present. Set to zero (0).
+
+ R
+ (Bit 1) Routing Present. Set to zero (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).
+
+ s
+ (Bit 4) Strict source route present. Set to zero (0).
+
+ Recur
+ (Bits 5-7) Recursion control. Set to zero (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.
+
+ Flags
+ (Bits 9-12) Must be set to zero (0).
+
+ Ver
+ (Bits 13-15) Must contain 1 (enhanced GRE).
+
+ Protocol Type
+ Set to hex 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
+
+ Call ID
+ (Low 2 octets) Contains the Peer's Call ID for the session
+ to which this packet belongs.
+
+ Sequence Number
+ Contains the sequence number of the payload. Present if S
+ bit (Bit 3) is one (1).
+
+
+
+
+Hamzeh, et al. Informational [Page 48]
+
+RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
+
+
+ Acknowledgment Number
+ Contains the sequence number of the highest numbered GRE
+ packet received by the sending peer for this user session.
+ Present if A bit (Bit 8) is one (1).
+
+ The payload section contains a PPP data packet without any
+ media specific framing elements.
+
+ 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.
+
+ 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
+
+ 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.
+
+4.2.1. Initial Window Size
+
+ 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.
+
+4.2.2. Closing the Window
+
+ 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.
+
+
+
+Hamzeh, et al. Informational [Page 49]
+
+RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
+
+
+4.2.3. Opening the Window
+
+ 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.
+
+4.2.4. Window Overflow
+
+ 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
+
+ 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.
+
+ 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.
+
+4.3. Out-of-sequence Packets
+
+ 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.
+
+
+
+
+
+
+Hamzeh, et al. Informational [Page 50]
+
+RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
+
+
+ When the PAC does receive packet 3, it MUST not attempt to transmit
+ it to the corresponding PPP client. To do so could cause problems,
+ as proper PPP protocol operation is premised upon receiving packets
+ in sequence. PPP does properly deal with the loss of packets, but
+ not with reordering so out of sequence packets between the PNS and
+ PAC MUST be silently discarded, or they may be reordered by the
+ receiver. When packet 5 comes in, it is acknowledged by the PAC
+ since it has a higher sequence number than 4, which was the last
+ highest packet acknowledged by the PAC. Packets with duplicate
+ sequence numbers should never occur since the PAC and PNS never
+ retransmit GRE packets. A robust implementation will silently
+ discard duplicate GRE packets, should it receive any.
+
+4.4. Acknowledgment Time-Outs
+
+ 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:
+
+ Independent time-outs for each session. A device (PAC or PNS) will
+ have to maintain and calculate time-outs for every active session.
+
+ An administrator-adjustable maximum time-out, MaxTimeOut, unique
+ to each device.
+
+ An adaptive time-out mechanism that compensates for changing
+ throughput. To reduce packet processing overhead, vendors may
+ choose not to recompute the adaptive time-out for every received
+ acknowledgment. The result of this overhead reduction is that the
+ time-out will not respond as quickly to rapid network changes.
+
+ Timer backoff on time-out to reduce congestion. The backed-off
+ timer value is limited by the configurable maximum time-out value.
+ Timer backoff is done every time an acknowledgment time-out
+ occurs.
+
+ In general, this mechanism has the desirable behavior of quickly
+ backing off upon a time-out and of slowly decreasing the time-out
+ value as packets are delivered without time-outs.
+
+
+
+
+
+
+Hamzeh, et al. Informational [Page 51]
+
+RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
+
+
+ Some definitions:
+
+ Packet Processing Delay (PPD) is the amount of time required for
+ each side to process the maximum amount of data buffered in their
+ receive packet sliding window. The PPD is the value exchanged
+ between the PAC and PNS when a call is established. For the PNS,
+ this number should be small. For a PAC making modem connections,
+ this number could be significant.
+
+ Sample is the actual amount of time incurred receiving an
+ acknowledgment for a packet. The Sample is measured, not
+ calculated.
+
+ Round-Trip Time (RTT) is the estimated round-trip time for an
+ Acknowledgment to be received for a given transmitted packet. When
+ the network link is a local network, this delay will be minimal
+ (if not zero). When the network link is the Internet, this delay
+ could be substantial and vary widely. RTT is adaptive: it will
+ adjust to include the PPD and whatever shifting network delays
+ contribute to the time between a packet being transmitted and
+ receiving its acknowledgment.
+
+ 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.
+
+ The Packet Processing Delay (PPD) parameter is a 16-bit word
+ exchanged during the Call Control phase that represents tenths of a
+ second (64 means 6.4 seconds). The protocol only specifies that the
+ parameter is exchanged, it does not specify how it is calculated. The
+ way values for PPD are calculated is implementation-dependent and
+ need not be variable (static time-outs are allowed). The PPD must be
+ exchanged in the call connect sequences, even if it remains constant
+ in an implementation. One possible way to calculate the PPD is:
+
+ PPD' = ((PPP_MAX_DATA_MTU - Header) * WindowSize * 8) / ConnectRate
+ PPD = PPD' + PACFudge
+
+ Header is the total size of the IP and GRE headers, which is 36. The
+ MTU is the overall MTU for the internetwork link between the PAC and
+ PNS. WindowSize represents the number of packets in the sliding
+ window, and is implementation-dependent. The latency of the
+ internetwork could be used to pick a window size sufficient to keep
+ the current session's pipe full. The constant 8 converts octets to
+ bits (assuming ConnectRate is in bits per second). If ConnectRate is
+ in bytes per second, omit the 8. PACFudge is not required but can be
+ used to take overall processing overhead of the PAC into account.
+
+
+
+
+Hamzeh, et al. Informational [Page 52]
+
+RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
+
+
+ The value of PPD is used to seed the adaptive algorithm with the
+ initial RTT[n-1] value.
+
+4.4.1. Calculating Adaptive Acknowledgment Time-Out
+
+ 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.
+
+ DIFF[n] = SAMPLE[n] - RTT[n-1]
+ DEV[n] = DEV[n-1] + (beta * (|DIFF[n]| - DEV[n-1]))
+ RTT[n] = RTT[n-1] + (alpha * DIFF[n])
+ ATO[n] = MAX (MinTimeOut, MIN (RTT[n] +
+ (chi * DEV[n]), MaxTimeOut))
+
+ DIFF represents the error between the last estimated round-trip
+ time and the measured time. DIFF is calculated on each iteration.
+
+ 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.
+
+ 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.
+
+ 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.
+
+ Alpha is the gain for the average and is typically 1/8 (0.125).
+
+ Beta is the gain for the deviation and is typically 1/4 (0.250).
+
+ Chi is the gain for the time-out and is typically set to 4.
+
+
+
+
+
+
+
+
+Hamzeh, et al. Informational [Page 53]
+
+RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
+
+
+ To eliminate division operations for fractional gain elements, the
+ entire set of equations can be scaled. With the suggested gain
+ constants, they should be scaled by 8 to eliminate all division. To
+ simplify calculations, all gain values are kept to powers of two so
+ that shift operations can be used in place of multiplication or
+ division.
+
+4.4.2. Congestion Control: Adjusting for Time-Out
+
+ 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:
+
+ RTT[n] = delta * RTT[n-1]
+ DEV[n] = DEV[n-1]
+ ATO[n] = MAX (MinTimeOut, MIN (RTT[n] +
+ (chi * DEV[n]), MaxTimeOut))
+
+ In this calculation of ATO, only the two values that both contribute
+ to ATO and are stored for the next iteration are calculated. RTT is
+ scaled by delta, and DEV is unmodified. DIFF is not carried forward
+ and is not used in this scenario. A value of 2 for Delta, the time-
+ out gain factor for RTT, is suggested.
+
+5. Security Considerations
+
+ The security of user data passed over the tunneled PPP connection is
+ addressed by PPP, as is authentication of the PPP peers.
+
+ 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.
+
+ 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.
+
+
+
+
+Hamzeh, et al. Informational [Page 54]
+
+RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
+
+
+ Unless the PPP payload data is cryptographically protected, it can be
+ captured and read or modified.
+
+6. Authors' Addresses
+
+ Kory Hamzeh
+ Ascend Communications
+ 1275 Harbor Bay Parkway
+ Alameda, CA 94502
+
+ EMail: kory@ascend.com
+
+
+ Gurdeep Singh Pall
+ Microsoft Corporation
+ Redmond, WA
+
+ EMail: gurdeep@microsoft.com
+
+
+ William Verthein
+ U.S. Robotics/3Com
+
+
+ Jeff Taarud
+ Copper Mountain Networks
+
+
+ W. Andrew Little
+ ECI Telematics
+
+
+ Glen Zorn
+ Microsoft Corporation
+ Redmond, WA
+
+ EMail: glennz@microsoft.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hamzeh, et al. Informational [Page 55]
+
+RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
+
+
+7. References
+
+ [1] Hanks, S., Li, T., Farinacci, D. and P. Traina, "Generic Routing
+ Encapsulation (GRE)", RFC 1701, October 1994.
+
+ [2] Hanks, S., Li, T., Farinacci, D. and P. Traina, "Generic Routing
+ Encapsulation (GRE) over IPv4 Networks", RFC 1702, October 1994.
+
+ [3] Lloyd, B. and W. Simpson, "PPP Authentication Protocols", RFC
+ 1334, October 1992.
+
+ [4] Postel, J., "Transmission Control Protocol", STD 7, RFC 793,
+ September 1981.
+
+ [5] Postel, J., "User Data Protocol", STD 6, RFC 768, August 1980.
+
+ [6] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700,
+ October 1994. See also: http://www.iana.org/numbers.html
+
+ [7] Simpson, W., editor, "The Point-to-Point Protocol (PPP)", STD
+ 51, RFC 1661, July 1994.
+
+ [8] Ethertype for PPP, Reserved with Xerox Corporation.
+
+ [9] Simpson, W., "PPP Challenge Handshake Authentication Protocol
+ (CHAP)", RFC 1994, August 1996.
+
+ [10] Blunk, L. and J Vollbrecht, "PPP Extensible Authentication
+ Protocol (EAP)", RFC 2284, March 1998.
+
+ [11] Stevens, R., "TCP/IP Illustrated, Volume 1", p. 300, Addison-
+ Wesley, 1994.
+
+ [12] Bradner, S., "Key words for use in RFCs to Indicate Requirement
+ Levels", BCP 14, RFC 2119, March 1997.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hamzeh, et al. Informational [Page 56]
+
+RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
+
+
+8. Full Copyright Statement
+
+ Copyright (C) The Internet Society (1999). All Rights Reserved.
+
+ This document and translations of it may be copied and furnished to
+ others, and derivative works that comment on or otherwise explain it
+ or assist in its implementation may be prepared, copied, published
+ and distributed, in whole or in part, without restriction of any
+ kind, provided that the above copyright notice and this paragraph are
+ included on all such copies and derivative works. However, this
+ document itself may not be modified in any way, such as by removing
+ the copyright notice or references to the Internet Society or other
+ Internet organizations, except as needed for the purpose of
+ developing Internet standards in which case the procedures for
+ copyrights defined in the Internet Standards process must be
+ followed, or as required to translate it into languages other than
+ English.
+
+ The limited permissions granted above are perpetual and will not be
+ revoked by the Internet Society or its successors or assigns.
+
+ This document and the information contained herein is provided on an
+ "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+ TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+ BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+ HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+ MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hamzeh, et al. Informational [Page 57]
+