diff options
Diffstat (limited to 'doc/rfc2637.txt')
| -rw-r--r-- | doc/rfc2637.txt | 3195 |
1 files changed, 3195 insertions, 0 deletions
diff --git a/doc/rfc2637.txt b/doc/rfc2637.txt new file mode 100644 index 00000000..56e9e0f5 --- /dev/null +++ b/doc/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] + |