| blob | f58701b31357207c39a72e7d99b4e62dfd4fabef |
2 Internet Draft Kory Hamzeh
3 Ascend Communications
4 Gurdeep Singh Pall
5 Microsoft Corporation
6 William Verthein
7 U.S. Robotics/3Com
8 Jeff Taarud
9 Copper Mountain Networks
10 W. Andrew Little
11 ECI Telematics
12 July 1997
13 Expire in six months
16 Point-to-Point Tunneling Protocol--PPTP
17 draft-ietf-pppext-pptp-02.txt
19 Status of this Memo
21 This document is an Internet-Draft. Internet-Drafts are working
22 documents of the Internet Engineering Task Force (IETF), its areas,
23 and its working groups. Note that other groups may also distribute
24 working documents as Internet-Drafts.
26 Internet-Drafts are draft documents valid for a maximum of six months
27 and may be updated, replaced, or obsoleted by other documents at any
28 time. It is inappropriate to use Internet-Drafts as reference
29 material or to cite them other than as "work in progress."
31 To learn the current status of any Internet-Draft, please check the
32 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
33 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
34 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
35 ftp.isi.edu (US West Coast).
37 Abstract
39 This document specifies a protocol which allows the Point
40 to Point Protocol (PPP) to be tunneled through an IP
41 network. PPTP does not specify any changes to the PPP
42 protocol but rather describes a new vehicle for carrying
43 PPP. A client-server architecture is defined in order to
44 decouple functions which exist in current Network Access
45 Servers (NAS) and support Virtual Private Networks (VPNs).
46 The PPTP Network Server (PNS) is envisioned to run on a
47 general purpose operating system while the client, referred
48 to as a PPTP Access Concentrator (PAC) operates on a dial
49 access platform. PPTP specifies a call-control and
53 Hamzeh, et al [Page 1]
55 Internet Draft PPTP July 1997
58 management protocol which allows the server to control
59 access for dial-in circuit switched calls originating from
60 a PSTN or ISDN or to initiate outbound circuit-switched
61 connections. PPTP uses an enhanced GRE (Generic Routing
62 Encapsulation) mechanism to provide a flow- and
63 congestion-controlled encapsulated datagram service for
64 carrying PPP packets.
66 1. Introduction
68 PPTP allows existing Network Access Server (NAS) functions to be
69 separated using a client-server architecture. Traditionally, the
70 following functions are implemented by a NAS:
72 1) Physical native interfacing to PSTN or ISDN and control of
73 external modems or terminal adapters.
75 A NAS may interface directly to a telco analog or digital circuit
76 or attach via an external modem or terminal adapter. Control of a
77 circuit-switched connection is accomplished with either modem
78 control or DSS1 ISDN call control protocols.
80 The NAS, in conjunction with the modem or terminal adapters, may
81 perform rate adaption, analog to digital conversion, sync to async
82 conversion or a number of other alterations of data streams.
84 2) Logical termination of a Point-to-Point-Protocol (PPP) Link
85 Control Protocol (LCP) session.
87 3) Participation in PPP authentication protocols [3].
89 4) Channel aggregation and bundle management for PPP Multilink
90 Protocol.
92 5) Logical termination of various PPP network control protocols
93 (NCP).
95 6) Multiprotocol routing and bridging between NAS interfaces.
97 PPTP divides these functions between the PAC and PNS. The PAC is
98 responsible for functions 1, 2, and possibly 3. The PNS may be
99 responsible for function 3 and is responsible for functions 4, 5, and
100 6. The protocol used to carry PPP protocol data units (PDUs) between
101 the PAC and PNS, as well as call control and management is addressed
102 by PPTP.
104 The decoupling of NAS functions offers these benefits:
109 Hamzeh, et al [Page 2]
111 Internet Draft PPTP July 1997
114 Flexible IP address management. Dial-in users may maintain a
115 single IP address as they dial into different PACs as long as they
116 are served from a common PNS. If an enterprise network uses
117 unregistered addresses, a PNS associated with the enterprise
118 assigns addresses meaningful to the private network.
120 Support of non-IP protocols for dial networks behind IP networks.
121 This allows Appletalk and IPX, for example to be tunneled through
122 an IP-only provider. The PAC need not be capable of processing
123 these protocols.
125 A solution to the "multilink hunt-group splitting" problem.
126 Multilink PPP, typically used to aggregate ISDN B channels,
127 requires that all of the channels composing a multilink bundle be
128 grouped at a single NAS. Since a multilink PPP bundle can be
129 handled by a single PNS, the channels comprising the bundle may be
130 spread across multiple PACs.
133 1.1 Protocol Goals and Assumptions
135 The PPTP protocol is implemented only by the PAC and PNS. No other
136 systems need to be aware of PPTP. Dial networks may be connected to a
137 PAC without being aware of PPTP. Standard PPP client software should
138 continue to operate on tunneled PPP links.
140 PPTP can also be used to tunnel a PPP session over an IP network. In
141 this configuration the PPTP tunnel and the PPP session runs between
142 the same two machines with the caller acting as a PNS.
144 It is envisioned that there will be a many-to-many relationship
145 between PACs and PNSs. A PAC may provide service to many PNSs. For
146 example, an Internet service provider may choose to support PPTP for
147 a number of private network clients and create VPNs for them. Each
148 private network may operate one or more PNSs. A single PNS may
149 associate with many PACs to concentrate traffic from a large number
150 of geographically diverse sites.
152 PPTP uses an extended version of GRE to carry user PPP packets. These
153 enhancements allow for low-level congestion and flow control to be
154 provided on the tunnels used to carry user data between PAC and PNS.
155 This mechanism allows for efficient use of the bandwidth available
156 for the tunnels and avoids unnecessary retransmisions and buffer
157 overruns. PPTP does not dictate the particular algorithms to be used
158 for this low level control but it does define the parameters that
159 must be communicated in order to allow such algorithms to work.
160 Suggested algorithms are included in Appendix A.
163 1.2 Terminology
166 Hamzeh, et al [Page 3]
168 Internet Draft PPTP July 1997
171 Analog Channel
173 A circuit-switched communication path which is intended to
174 carry 3.1 Khz audio in each direction.
176 Digital Channel
178 A circuit-switched communication path which is intended to
179 carry digital information in each direction.
181 Call
183 A connection or attempted connection between two terminal
184 endpoints on a PSTN or ISDN--for example, a telephone call
185 between two modems.
187 Control Connection
189 A control connection is created for each PAC, PNS pair and
190 operates over TCP [4]. The control connection governs aspects
191 of the tunnel and of sessions assigned to the tunnel.
193 Dial User
195 An end-system or router attached to an on-demand PSTN or ISDN
196 which is either the initiator or recipient of a call.
198 Network Access Server (NAS)
200 A device providing temporary, on-demand network access to
201 users. This access is point-to-point using PSTN or ISDN lines.
203 PPTP Access Concentrator (PAC)
205 A device attached to one or more PSTN or ISDN lines capable of
206 PPP operation and of handling the PPTP protocol. The PAC need
207 only implement TCP/IP to pass traffic to one or more PNSs. It
208 may also tunnel non-IP protocols.
210 PPTP Network Server (PNS)
212 A PNS is envisioned to operate on general-purpose
213 computing/server platforms. The PNS handles the server side of
214 the PPTP protocol. Since PPTP relies completely on TCP/IP and
215 is independent of the interface hardware, the PNS may use any
216 combination of IP interface hardware including LAN and WAN
217 devices.
222 Hamzeh, et al [Page 4]
224 Internet Draft PPTP July 1997
227 Session
229 PPTP is connection-oriented. The PNS and PAC maintain state for
230 each user that is attached to a PAC. A session is created when
231 end-to-end PPP connection is attempted between a dial user and
232 the PNS. The datagrams related to a session are sent over the
233 tunnel between the PAC and PNS.
235 Tunnel
237 A tunnel is defined by a PNS-PAC pair. The tunnel protocol is
238 defined by a modified version of GRE [1,2]. The tunnel carries
239 PPP datagrams between the PAC and the PNS. Many sessions are
240 multiplexed on a single tunnel. A control connection operating
241 over TCP controls the establishment, release, and maintenance
242 of sessions and of the tunnel itself.
244 1.3 Protocol Overview
246 There are two parallel components of PPTP: 1) a Control Connection
247 between each PAC-PNS pair operating over TCP and 2) an IP tunnel
248 operating between the same PAC-PNS pair which is used to transport
249 GRE encapsulated PPP packets for user sessions between the pair.
251 1.3.1 Control Connection Overview
253 Before PPP tunneling can occur between a PAC and PNS, a control
254 connection must be established between them. The control connection
255 is a standard TCP session over which PPTP call control and management
256 information is passed. The control session is logically associated
257 with, but separate from, the sessions being tunneled through a PPTP
258 tunnel. For each PAC-PNS pair both a tunnel and a control connection
259 exist. The control connection is responsible for establishment,
260 management, and release of sessions carried through the tunnel. It is
261 the means by which a PNS is notified of an incoming call at an
262 associated PAC, as well as the means by which a PAC is instructed to
263 place an outgoing dial call.
265 A control connection can be established by either the PNS or the PAC.
266 Following the establishment of the required TCP connection, the PNS
267 and PAC establish the control connection using the Start-Control-
268 Connection-Request and -Reply messages. These messages are also used
269 to exchange information about basic operating capabilities of the PAC
270 and PNS. Once the control connection is established, the PAC or PNS
271 may initiate sessions by requesting outbound calls or responding to
272 inbound requests. The control connection may communicate changes in
273 operating characteristics of an individual user session with a Set-
274 Link-Info message. Individual sessions may be released by either the
278 Hamzeh, et al [Page 5]
280 Internet Draft PPTP July 1997
283 PAC or PNS, also through Control Connection messages.
285 The control connection itself is maintained by keep-alive echo
286 messages. This ensures that a connectivity failure between the PNS
287 and the PAC can be detected in a timely manner. Other failures can be
288 reported via the Wan-Error-Notify message, also on the control
289 connection.
291 It is intended that the control connection will also carry management
292 related messages in the future, such as a message allowing the PNS to
293 request the status of a given PAC; these message types have not yet
294 been defined.
296 1.3.2 Tunnel Protocol Overview
298 PPTP requires the establishment of a tunnel for each communicating
299 PNS-PAC pair. This tunnel is used to carry all user session PPP
300 packets for sessions involving a given PNS-PAC pair. A key which is
301 present in the GRE header indicates which session a particular PPP
302 packet belongs to. In this manner, PPP packets are multiplexed and
303 demultiplexed over a single tunnel between a given PNS-PAC pair. The
304 value to use in the key field is established by the call
305 establishment procedure which takes place on the control connection.
307 The GRE header also contains acknowledgment and sequencing
308 information that is used to perform some level of congestion-control
309 and error detection over the tunnel. Again the control connection is
310 used to determine rate and buffering parameters that are used to
311 regulate the flow of PPP packets for a particular session over the
312 tunnel. PPTP does not specify the particular algorithms to use for
313 congestion-control and flow-control. Suggested algorithms for the
314 determination of adaptive time-outs to recover from dropped data or
315 acknowledgments on the tunnel are included in Appendix A of this
316 document.
318 1.4 Specification Language
320 In this document, several words are used to signify the requirements
321 of the specification. These words are often capitalized.
323 MUST This word, or the adjective "required", means
324 that the definition is an absolute requirement
325 of the specification.
327 MUST NOT This phrase means that the definition is an
328 absolute prohibition of the specification.
330 SHOULD This word, or the adjective "recommended",
334 Hamzeh, et al [Page 6]
336 Internet Draft PPTP July 1997
339 means that, in some circumstances, valid
340 reasons may exist to ignore this item, but the
341 full implications must be understood and
342 carefully weighed before choosing a different
343 course. Unexpected results may result
344 otherwise.
346 MAY This word, or the adjective "optional", means
347 that this item is one of an allowed set of
348 alternatives. An implementation which does
349 not include this option MUST be prepared to
350 interoperate with another implementation which
351 does include the option.
353 silently discard The implementation discards the datagram
354 without further processing, and without
355 indicating an error to the sender. The
356 implementation SHOULD provide the capability
357 of logging the error, including the contents
358 of the discarded datagram, and SHOULD record
359 the event in a statistics counter.
362 1.5 Message Format and Protocol Extensibility
364 PPTP defines a set of messages sent as TCP data on the control
365 connection between a PNS and a given PAC. The TCP session for the
366 control connection is established by initiating a TCP connection to
367 port 1723 [6]. The source port is assigned to any unused port number.
369 Each PPTP Control Connection message begins with an 8 octet fixed
370 header portion. This fixed header contains the following: the total
371 length of the message, the PPTP Message Type indicator, and a "Magic
372 Cookie".
374 Two Control Connection message types are indicated by the PPTP
375 Message Type field:
377 1 - Control Message
378 2 - Management Message
380 Management messages are currently not defined.
382 The Magic Cookie is always sent as the constant 0x1A2B3C4D. Its
383 basic purpose is to allow the receiver to ensure that it is properly
384 synchronized with the TCP data stream. It should not be used as a
385 means for resynchronizing the TCP data stream in the event that a
386 transmitter issues an improperly formatted message. Loss of
390 Hamzeh, et al [Page 7]
392 Internet Draft PPTP July 1997
395 synchronization must result in immediate closing of the control
396 connection's TCP session.
398 For clarity, all Control Connection message templates in the next
399 section include the entire PPTP Control Connection message header.
400 Numbers preceded by 0x are hexadecimal values.
402 The currently defined Control Messages, grouped by function, are:
404 Control Message Message Code
406 (Control Connection Management)
408 Start-Control-Connection-Request 1
409 Start-Control-Connection-Reply 2
410 Stop-Control-Connection-Request 3
411 Stop-Control-Connection-Reply 4
412 Echo-Request 5
413 Echo-Reply 6
415 (Call Management)
417 Outgoing-Call-Request 7
418 Outgoing-Call-Reply 8
419 Incoming-Call-Request 9
420 Incoming-Call-Reply 10
421 Incoming-Call-Connected 11
422 Call-Clear-Request 12
423 Call-Disconnect-Notify 13
425 (Error Reporting)
427 WAN-Error-Notify 14
429 (PPP Session Control)
431 Set-Link-Info 15
434 The Start-Control-Connection-Request and -Reply messages determine
435 which version of the Control Connection protocol will be used. The
436 version number field carried in these messages consists of a version
437 number in the high octet and a revision number in the low octet.
438 Version handling is described in Section 3. The current value of the
439 version number field is 0x0100 for version 1, revision 0.
441 The use of the GRE-like header for the encapsulation of PPP user
442 packets is specified in Section 4.
446 Hamzeh, et al [Page 8]
448 Internet Draft PPTP July 1997
451 The MTU for the user data packets encapsulated in GRE is 1532 octets,
452 not including the IP and GRE headers.
454 2.0 Control Connection Protocol Specification
457 Control Connection messages are used to establish and clear user
458 sessions. The first set of Control Connection messages are used to
459 maintain the control connection itself. The control connection is
460 initiated by either the PNS or PAC after they establish the
461 underlying TCP connection. The procedure and configuration
462 information required to determine which TCP connections are
463 established is not covered by this protocol.
465 The following Control Connection messages are all sent as user data
466 on the established TCP connection between a given PNS-PAC pair. Note
467 that care has been taken to ensure that all word (2 octet) and
468 longword (4 octet) values begin on appropriate boundaries. All data
469 is sent in network order (high order octets first). Any "reserved"
470 fields MUST be sent as 0 values to allow for protocol extensibility.
472 The TCP header is followed by the PPTP fields shown in the following:
502 Hamzeh, et al [Page 9]
504 Internet Draft PPTP July 1997
507 2.1 Start-Control-Connection-Request
509 The Start-Control-Connection-Request is a PPTP control message used
510 to establish the control connection between a PNS and a PAC. Each
511 PNS-PAC pair requires a dedicated control connection to be
512 established. A control connection must be established before any
513 other PPTP messages can be issued. The establishment of the control
514 connection can be initiated by either the PNS or PAC. A procedure
515 which handles the occurrence of a collision between PNS and PAC
516 Start-Control-Connection-Requests is described in Section 3.
518 0 1 2 3
519 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
520 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
521 | Length | PPTP Message Type |
522 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
523 | Magic Cookie |
524 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
525 | Control Message Type | Reserved0 |
526 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
527 | Protocol Version | Reserved1 |
528 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
529 | Framing Capabilities |
530 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
531 | Bearer Capabilities |
532 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
533 | Maximum Channels | Firmware Revision |
534 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
535 | |
536 + Host Name (64 octets) +
537 | |
538 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
539 | |
540 + Vendor String (64 octets) +
541 | |
542 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
546 Length Total length in octets of this PPTP
547 message, including the entire PPTP
548 header.
550 PPTP Message Type 1 for Control Message.
552 Magic Cookie 0x1A2B3C4D. This constant value is used
553 as a sanity check on received messages
554 (see Section 1.5).
558 Hamzeh, et al [Page 10]
560 Internet Draft PPTP July 1997
563 Control Message Type 1 for Start-Control-Connection-Request.
565 Reserved0 This field MUST be 0.
567 Protocol Version The version of the PPTP protocol that the
568 sender wishes to use.
570 Reserved1 This field MUST be 0.
572 Framing Capabilities A set of bits indicating the type of
573 framing that the sender of this message
574 can provide. The currently defined bit
575 settings are:
577 1 - Asynchronous Framing supported
579 2 - Synchronous Framing supported
581 Bearer Capabilities A set of bits indicating the bearer
582 capabilities that the sender of this
583 message can provide. The currently
584 defined bit settings are:
586 1 - Analog access supported
588 2 - Digital access supported
590 Maximum Channels The total number of individual PPP
591 sessions this PAC can support. In
592 Start-Control-Connection-Requests issued
593 by the PNS, this value SHOULD be set to
594 0. It MUST be ignored by the PAC.
596 Firmware Revision This field contains the firmware revision
597 number of the issuing PAC, when issued by
598 the PAC, or the version of the PNS PPTP
599 driver if issued by the PNS.
601 Host Name A 64 octet field containing the DNS name
602 of the issuing PAC or PNS. If less than
603 64 octets in length, the remainder of
604 this field SHOULD be filled with octets
605 of value 0.
607 Vendor Name A 64 octet field containing a vendor
608 specific string describing the type of
609 PAC being used, or the type of PNS
610 software being used if this request is
614 Hamzeh, et al [Page 11]
616 Internet Draft PPTP July 1997
619 issued by the PNS. If less than 64
620 octets in length, the remainder of this
621 field SHOULD be filled with octets of
622 value 0.
670 Hamzeh, et al [Page 12]
672 Internet Draft PPTP July 1997
675 2.2 Start-Control-Connection-Reply
677 The Start-Control-Connection-Reply is a PPTP control message sent in
678 reply to a received Start-Control-Connection-Request message. This
679 message contains a result code indicating the result of the control
680 connection establishment attempt.
682 0 1 2 3
683 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
684 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
685 | Length | PPTP Message Type |
686 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
687 | Magic Cookie |
688 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
689 | Control Message Type | Reserved0 |
690 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
691 | Protocol Version | Result Code | Error Code |
692 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
693 | Framing Capability |
694 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
695 | Bearer Capability |
696 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
697 | Maximum Channels | Firmware Revision |
698 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
699 | |
700 + Host Name (64 octets) +
701 | |
702 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
703 | |
704 + Vendor String (64 octets) +
705 | |
706 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
710 Length Total length in octets of this PPTP
711 message, including the entire PPTP
712 header.
714 PPTP Message Type 1 for Control Message.
716 Magic Cookie 0x1A2B3C4D.
718 Control Message Type 2 for Start-Control-Connection-Reply.
720 Reserved0 This field MUST be 0.
722 Protocol Version The version of the PPTP protocol that the
726 Hamzeh, et al [Page 13]
728 Internet Draft PPTP July 1997
731 sender wishes to use.
733 Result Code Indicates the result of the command
734 channel establishment attempt. Current
735 valid Result Code values are:
737 1 - Successful channel establishment
739 2 - General error -- Error Code
740 indicates the problem
742 3 - Command channel already exists;
744 4 - Requester is not authorized to
745 establish a command channel
747 5 - The protocol version of the
748 requester is not supported
750 Error Code This field is set to 0 unless a "General
751 Error" exists, in which case Result Code
752 is set to 2 and this field is set to the
753 value corresponding to the general error
754 condition as specified in Section 2.16.
756 Framing Capabilities A set of bits indicating the type of
757 framing that the sender of this message
758 can provide. The currently defined bit
759 settings are:
761 1 - Asynchronous Framing supported
763 2 - Synchronous Framing supported.
765 Bearer Capabilities A set of bits indicating the bearer
766 capabilities that the sender of this
767 message can provide. The currently
768 defined bit settings are:
770 1 - Analog access supported
772 2 - Digital access supported
774 Maximum Channels The total number of individual PPP
775 sessions this PAC can support. In a
776 Start-Control-Connection-Reply issued by
777 the PNS, this value SHOULD be set to 0
778 and it must be ignored by the PAC. The
782 Hamzeh, et al [Page 14]
784 Internet Draft PPTP July 1997
787 PNS MUST NOT use this value to try to
788 track the remaining number of PPP
789 sessions that the PAC will allow.
791 Firmware Revision This field contains the firmware revision
792 number of the issuing PAC, or the version
793 of the PNS PPTP driver if issued by the
794 PNS.
796 Host Name A 64 octet field containing the DNS name
797 of the issuing PAC or PNS. If less than
798 64 octets in length, the remainder of
799 this field SHOULD be filled with octets
800 of value 0.
802 Vendor Name A 64 octet field containing a vendor
803 specific string describing the type of
804 PAC being used, or the type of PNS
805 software being used if this request is
806 issued by the PNS. If less than 64
807 octets in length, the remainder of this
808 field SHOULD be filled with octets of
809 value 0.
838 Hamzeh, et al [Page 15]
840 Internet Draft PPTP July 1997
843 2.3 Stop-Control-Connection-Request
845 The Stop-Control-Connection-Request is a PPTP control message sent by
846 one peer of a PAC-PNS control connection to inform the other peer
847 that the control connection should be closed. In addition to closing
848 the control connection, all active user calls are implicitly cleared.
849 The reason for issuing this request is indicated in the Reason field.
851 0 1 2 3
852 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
853 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
854 | Length | PPTP Message Type |
855 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
856 | Magic Cookie |
857 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
858 | Control Message Type | Reserved0 |
859 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
860 | Reason | Reserved1 | Reserved2 |
861 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
865 Length Total length in octets of this PPTP
866 message, including the entire PPTP
867 header.
869 PPTP Message Type 1 for Control Message.
871 Magic Cookie 0x1A2B3C4D.
873 Control Message Type 3 for Stop-Control-Connection-Request.
875 Reserved0 This field MUST be 0.
877 Reason Indicates the reason for the control
878 connection being closed. Current valid
879 Reason values are:
881 1 (None) - General request to clear
882 control connection
884 2 (Stop-Protocol) - Can't support
885 peer's version of the protocol
887 3 (Stop-Local-Shutdown) - Requester is
888 being shut down
890 Reserved1, Reserved2 These fields MUST be 0.
894 Hamzeh, et al [Page 16]
896 Internet Draft PPTP July 1997
899 2.4 Stop-Control-Connection-Reply
901 The Stop-Control-Connection-Reply is a PPTP control message sent by
902 one peer of a PAC-PNS control connection upon receipt of a Stop-
903 Control-Connection-Request from the other peer.
905 0 1 2 3
906 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
907 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
908 | Length | PPTP Message Type |
909 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
910 | Magic Cookie |
911 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
912 | Control Message Type | Reserved0 |
913 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
914 | Result Code | Error Code | Reserved1 |
915 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
918 Length Total length in octets of this PPTP
919 message, including the entire PPTP
920 header.
922 PPTP Message Type 1 for Control Message.
924 Magic Cookie 0x1A2B3C4D.
926 Control Message Type 4 for Stop-Control-Connection-Reply.
928 Reserved0 This field MUST be 0.
930 Result Code Indicates the result of the attempt to
931 close the control connection. Current
932 valid Result Code values are:
934 1 (OK) - Control connection closed
936 2 (General Error) - Control connection
937 not closed for reason indicated in
938 Error Code
940 Error Code This field is set to 0 unless a "General
941 Error" exists, in which case Result Code
942 is set to 2 and this field is set to the
943 value corresponding to the general error
944 condition as specified in Section 2.16.
946 Reserved1 This field MUST be 0.
950 Hamzeh, et al [Page 17]
952 Internet Draft PPTP July 1997
955 2.5 Echo-Request
957 The Echo-Request is a PPTP control message sent by either peer of a
958 PAC-PNS control connection. This control message is used as a "keep-
959 Alive" for the control connection. The receiving peer issues an
960 Echo-Reply to each Echo-Request received. As specified in Section 3,
961 if the sender does not receive an Echo Reply in response to an Echo-
962 Request, it will eventually clear the control connection.
964 0 1 2 3
965 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
966 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
967 | Length | PPTP Message Type |
968 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
969 | Magic Cookie |
970 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
971 | Control Message Type | Reserved0 |
972 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
973 | Identifier |
974 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
977 Length Total length in octets of this PPTP
978 message, including the entire PPTP
979 header.
981 PPTP Message Type 1 for Control Message.
983 Magic Cookie 0x1A2B3C4D.
985 Control Message Type 5 for Echo-Request.
987 Reserved0 This field MUST be 0.
989 Identifier A value set by the sender of the Echo-
990 Request that is used to match the reply
991 with the corresponding request.
1006 Hamzeh, et al [Page 18]
1008 Internet Draft PPTP July 1997
1011 2.6 Echo-Reply
1013 The Echo-Reply is a PPTP control message sent by either peer of a
1014 PAC-PNS control connection in response to the receipt of an Echo-
1015 Request.
1017 0 1 2 3
1018 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
1019 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1020 | Length | PPTP Message Type |
1021 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1022 | Magic Cookie |
1023 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1024 | Control Message Type | Reserved0 |
1025 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1026 | Identifier |
1027 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1028 | Result Code | Error Code | Reserved1 |
1029 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1032 Length Total length in octets of this PPTP
1033 message, including the entire PPTP
1034 header.
1036 PPTP Message Type 1 for Control Message.
1038 Magic Cookie 0x1A2B3C4D.
1040 Control Message Type 6 for Echo-Reply.
1042 Reserved0 This field MUST be 0.
1044 Identifier The contents of the identify field from
1045 the received Echo-Request is copied to
1046 this field.
1048 Result Code Indicates the result of the receipt of
1049 the Echo-Request. Current valid Result
1050 Code values are:
1052 1 (OK) - The Echo-Reply is valid
1054 2 (General Error) - Echo-Request not
1055 accepted for the reason indicated in
1056 Error Code
1058 Error Code This field is set to 0 unless a "General
1062 Hamzeh, et al [Page 19]
1064 Internet Draft PPTP July 1997
1067 Error" condition exists, in which case
1068 Result Code is set to 2 and this field is
1069 set to the value corresponding to the
1070 general error condition as specified in
1071 Section 2.16.
1073 Reserved1 This field MUST be 0.
1118 Hamzeh, et al [Page 20]
1120 Internet Draft PPTP July 1997
1123 2.7 Outgoing-Call-Request
1125 The Outgoing-Call-Request is a PPTP control message sent by the PNS
1126 to the PAC to indicate that an outbound call from the PAC is to be
1127 established. This request provides the PAC with information required
1128 to make the call. It also provides information to the PAC that is
1129 used to regulate the transmission of data to the PNS for this session
1130 once it is established.
1132 0 1 2 3
1133 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
1134 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1135 | Length | PPTP Message Type |
1136 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1137 | Magic Cookie |
1138 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1139 | Control Message Type | Reserved0 |
1140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1141 | Call ID | Call Serial Number |
1142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1143 | Minimum BPS |
1144 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1145 | Maximum BPS |
1146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1147 | Bearer Type |
1148 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1149 | Framing Type |
1150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1151 | Packet Recv. Window Size | Packet Processing Delay |
1152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1153 | Phone Number Length | Reserved1 |
1154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1155 | |
1156 + Phone Number (64 octets) +
1157 | |
1158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1159 | |
1160 + Subaddress (64 octets) +
1161 | |
1162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1165 Length Total length in octets of this PPTP
1166 message, including the entire PPTP
1167 header.
1169 PPTP Message Type 1 for Control Message.
1174 Hamzeh, et al [Page 21]
1176 Internet Draft PPTP July 1997
1179 Magic Cookie 0x1A2B3C4D.
1181 Control Message Type 7 for Outgoing-Call-Request.
1183 Reserved0 This field MUST be 0.
1185 Call ID A unique identifier, unique to a
1186 particular PAC-PNS pair assigned by the
1187 PNS to this session. It is used to
1188 multiplex and demultiplex data sent over
1189 the tunnel between the PNS and PAC
1190 involved in this session.
1192 Call Serial Number An identifier assigned by the PNS to this
1193 session for the purpose of identifying
1194 this particular session in logged session
1195 information. Unlike the Call ID, both
1196 the PNS and PAC associate the same Call
1197 Serial Number with a given session. The
1198 combination of IP address and call serial
1199 number SHOULD be unique.
1201 Minimum BPS The lowest acceptable line speed (in
1202 bits/second) for this session.
1204 Maximum BPS The highest acceptable line speed (in
1205 bits/second) for this session.
1207 Bearer Type A value indicating the bearer capability
1208 required for this outgoing call. The
1209 currently defined values are:
1211 1 - Call to be placed on an analog
1212 channel
1214 2 - Call to be placed on a digital
1215 channel
1217 3 - Call can be placed on any type of
1218 channel
1220 Framing Type A value indicating the type of PPP
1221 framing to be used for this outgoing
1222 call.
1224 1 - Call to use Asynchronous framing
1226 2 - Call to use Synchronous framing
1230 Hamzeh, et al [Page 22]
1232 Internet Draft PPTP July 1997
1235 3 - Call can use either type of
1236 framing
1238 Packet Recv. Window Size The number of received data packets the
1239 PNS will buffer for this session.
1241 Packet Processing Delay A measure of the packet processing delay
1242 that might be imposed on data sent to the
1243 PNS from the PAC. This value is
1244 specified in units of 1/10 seconds. For
1245 the PNS this number should be very small.
1246 See appendix A for a description of how
1247 this value is determined and used.
1249 Phone Number Length The actual number of valid digits in the
1250 Phone Number field.
1252 Reserved1 This field MUST be 0.
1254 Phone Number The number to be dialed to establish the
1255 outgoing session. For ISDN and analog
1256 calls this field is an ASCII string. If
1257 the Phone Number is less than 64 octets
1258 in length, the remainder of this field is
1259 filled with octets of value 0.
1261 Subaddress A 64 octet field used to specify
1262 additional dialing information. If the
1263 subaddress is less than 64 octets long,
1264 the remainder of this field is filled
1265 with octets of value 0.
1286 Hamzeh, et al [Page 23]
1288 Internet Draft PPTP July 1997
1291 2.8 Outgoing-Call-Reply
1293 The Outgoing-Call-Reply is a PPTP control message sent by the PAC to
1294 the PNS in response to a received Outgoing-Call-Request message. The
1295 reply indicates the result of the outgoing call attempt. It also
1296 provides information to the PNS about particular parameters used for
1297 the call. It provides information to allow the PNS to regulate the
1298 transmission of data to the PAC for this session.
1300 0 1 2 3
1301 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
1302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1303 | Length | PPTP Message Type |
1304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1305 | Magic Cookie |
1306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1307 | Control Message Type | Reserved0 |
1308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1309 | Call ID | Peer's Call ID |
1310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1311 | Result Code | Error Code | Cause Code |
1312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1313 | Connect Speed |
1314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1315 | Packet Recv. Window Size | Packet Processing Delay |
1316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1317 | Physical Channel ID |
1318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1321 Length Total length in octets of this PPTP
1322 message, including the entire PPTP
1323 header.
1325 PPTP Message Type 1 for Control Message.
1327 Magic Cookie 0x1A2B3C4D.
1329 Control Message Type 8 for Outgoing-Call-Reply.
1331 Reserved0 This field MUST be 0.
1333 Call ID A unique identifier for the tunnel,
1334 assigned by the PAC to this session. It
1335 is used to multiplex and demultiplex data
1336 sent over the tunnel between the PNS and
1337 PAC involved in this session.
1342 Hamzeh, et al [Page 24]
1344 Internet Draft PPTP July 1997
1347 Peer's Call ID This field is set to the value received
1348 in the Call ID field of the corresponding
1349 Outgoing-Call-Request message. It is
1350 used by the PNS to match the Outgoing-
1351 Call-Reply with the Outgoing-Call-Request
1352 it issued. It also is used as the value
1353 sent in the GRE header for mux/demuxing.
1355 Result Code This value indicates the result of the
1356 Outgoing-Call-Request attempt. Currently
1357 valid values are:
1359 1 (Connected) - Call established with
1360 no errors
1362 2 (General Error) - Outgoing Call not
1363 established for the reason indicated
1364 in Error Code
1366 3 (No Carrier) - Outgoing Call failed
1367 due to no carrier detected
1369 4 (Busy) - Outgoing Call failed due to
1370 detection of a busy signal
1372 5 (No Dial Tone) - Outgoing Call
1373 failed due to lack of a dial tone
1375 6 (Time-out) - Outgoing Call was not
1376 established within time allotted by
1377 PAC
1379 7 (Do Not Accept) - Outgoing Call
1380 administratively prohibited
1382 Error Code This field is set to 0 unless a "General
1383 Error" condition exists, in which case
1384 Result Code is set to 2 and this field is
1385 set to the value corresponding to the
1386 general error condition as specified in
1387 Section 2.16.
1389 Cause Code This field gives additional failure
1390 information. Its value can vary
1391 depending upon the type of call
1392 attempted. For ISDN call attempts it is
1393 the Q.931 cause code.
1398 Hamzeh, et al [Page 25]
1400 Internet Draft PPTP July 1997
1403 Connect Speed The actual connection speed used, in
1404 bits/second.
1406 Packet Recv. Window Size The number of received data packets the
1407 PAC will buffer for this session.
1409 Packet Processing Delay A measure of the packet processing delay
1410 that might be imposed on data sent to the
1411 PAC from the PNS. This value is
1412 specified in units of 1/10 seconds. For
1413 the PAC, this number is related to the
1414 size of the buffer used to hold packets
1415 to be sent to the client and to the speed
1416 of the link to the client. This value
1417 should be set to the maximum delay that
1418 can normally occur between the time a
1419 packet arrives at the PAC and is
1420 delivered to the client. See Appendix A
1421 for an example of how this value is
1422 determined and used.
1424 Physical Channel ID This field is set by the PAC in a
1425 vendor-specific manner to the physical
1426 channel number used to place this call.
1427 It is used for logging purposes only.
1454 Hamzeh, et al [Page 26]
1456 Internet Draft PPTP July 1997
1459 2.9 Incoming-Call-Request
1461 The Incoming-Call-Request is a PPTP control message sent by the PAC
1462 to the PNS to indicate that an inbound call is to be established from
1463 the PAC. This request provides the PNS with parameter information
1464 for the incoming call.
1466 This message is the first in the "three-way handshake" used by PPTP
1467 for establishing incoming calls. The PAC may defer answering the
1468 call until it has received an Incoming-Call-Reply from the PNS
1469 indicating that the call should be established. This mechanism allows
1470 the PNS to obtain sufficient information about the call before it is
1471 answered to determine whether the call should be answered or not.
1473 0 1 2 3
1474 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
1475 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1476 | Length | PPTP Message Type |
1477 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1478 | Magic Cookie |
1479 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1480 | Control Message Type | Reserved0 |
1481 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1482 | Call ID | Call Serial Number |
1483 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1484 | Call Bearer Type |
1485 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1486 | Physical Channel ID |
1487 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1488 | Dialed Number Length | Dialing Number Length |
1489 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1490 | |
1491 + Dialed Number (64 octets) +
1492 | |
1493 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1494 | |
1495 + Dialing Number (64 octets) +
1496 | |
1497 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1498 | |
1499 + Subaddress (64 octets) +
1500 | |
1501 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1504 Length Total length in octets of this PPTP
1505 message, including the entire PPTP
1506 header.
1510 Hamzeh, et al [Page 27]
1512 Internet Draft PPTP July 1997
1515 PPTP Message Type 1 for Control Message.
1517 Magic Cookie 0x1A2B3C4D.
1519 Control Message Type 9 for Incoming-Call-Request.
1521 Reserved0 This field MUST be 0.
1523 Call ID A unique identifier for this tunnel,
1524 assigned by the PAC to this session. It
1525 is used to multiplex and demultiplex data
1526 sent over the tunnel between the PNS and
1527 PAC involved in this session.
1529 Call Serial Number An identifier assigned by the PAC to this
1530 session for the purpose of identifying
1531 this particular session in logged session
1532 information. Unlike the Call ID, both
1533 the PNS and PAC associate the same Call
1534 Serial Number to a given session. The
1535 combination of IP address and call serial
1536 number should be unique.
1538 Bearer Type A value indicating the bearer capability
1539 used for this incoming call. Currently
1540 defined values are:
1542 1 - Call is on an analog channel
1544 2 - Call is on a digital channel
1546 Physical Channel ID This field is set by the PAC in a
1547 vendor-specific manner to the number of
1548 the physical channel this call arrived
1549 on.
1551 Dialed Number Length The actual number of valid digits in the
1552 Dialed Number field.
1554 Dialing Number Length The actual number of valid digits in the
1555 Dialing Number field.
1557 Dialed Number The number that was dialed by the caller.
1558 For ISDN and analog calls this field is
1559 an ASCII string. If the Dialed Number is
1560 less than 64 octets in length, the
1561 remainder of this field is filled with
1562 octets of value 0.
1566 Hamzeh, et al [Page 28]
1568 Internet Draft PPTP July 1997
1571 Dialing Number The number from which the call was
1572 placed. For ISDN and analog calls this
1573 field is an ASCII string. If the Dialing
1574 Number is less than 64 octets in length,
1575 the remainder of this field is filled
1576 with octets of value 0.
1578 Subaddress A 64 octet field used to specify
1579 additional dialing information. If the
1580 subaddress is less than 64 octets long,
1581 the remainder of this field is filled
1582 with octets of value 0.
1622 Hamzeh, et al [Page 29]
1624 Internet Draft PPTP July 1997
1627 2.10 Incoming-Call-Reply
1629 The Incoming-Call-Reply is a PPTP control message sent by the PNS to
1630 the PAC in response to a received Incoming-Call-Request message. The
1631 reply indicates the result of the incoming call attempt. It also
1632 provides information to allow the PAC to regulate the transmission of
1633 data to the PNS for this session.
1635 This message is the second in the three-way handshake used by PPTP
1636 for establishing incoming calls. It indicates to the PAC whether the
1637 call should be answered or not.
1639 0 1 2 3
1640 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
1641 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1642 | Length | PPTP Message Type |
1643 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1644 | Magic Cookie |
1645 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1646 | Control Message Type | Reserved0 |
1647 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1648 | Call ID | Peer's Call ID |
1649 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1650 | Result Code | Error Code | Packet Recv. Window Size |
1651 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1652 | Packet Transmit Delay | Reserved1 |
1653 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1656 Length Total length in octets of this PPTP
1657 message, including the entire PPTP
1658 header.
1660 PPTP Message Type 1 for Control Message.
1662 Magic Cookie 0x1A2B3C4D.
1664 Control Message Type 10 for Incoming-Call-Reply.
1666 Reserved0 This field MUST be 0.
1668 Call ID A unique identifier for this tunnel
1669 assigned by the PAC to this session. It
1670 is used to multiplex and demultiplex data
1671 sent over the tunnel between the PNS and
1672 PAC involved in this session.
1674 Peer's Call ID This field is set to the value received
1678 Hamzeh, et al [Page 30]
1680 Internet Draft PPTP July 1997
1683 in the Call ID field of the corresponding
1684 Incoming-Call-Request message. It is used
1685 by the PAC to match the Incoming-Call-
1686 Reply with the Incoming-Call-Request it
1687 issued. This value is included in the GRE
1688 header of transmitted data packets for
1689 this session.
1691 Result Code This value indicates the result of the
1692 Incoming-Call-Request attempt. Current
1693 valid Result Code values are:
1695 1 (Connect) - The PAC should answer
1696 the incoming call
1698 2 (General Error) - The Incoming Call
1699 should not be established due to the
1700 reason indicated in Error Code
1702 3 (Do Not Accept) - The PAC should not
1703 accept the incoming call. It should
1704 hang up or issue a busy indication
1706 Error Code This field is set to 0 unless a "General
1707 Error" condition exists, in which case
1708 Result Code is set to 2 and this field is
1709 set to the value corresponding to the
1710 general error condition as specified in
1711 Section 2.16.
1713 Packet Recv. Window Size The number of received data packets the
1714 PAC will buffer for this session.
1716 Packet Transmit Delay A measure of the packet processing delay
1717 that might be imposed on data sent to the
1718 PAC from the PNS. This value is
1719 specified in units of 1/10 seconds. See
1720 Appendix A for a description of how this
1721 value is determined and used.
1723 Reserved1 This field MUST be 0.
1734 Hamzeh, et al [Page 31]
1736 Internet Draft PPTP July 1997
1739 2.11 Incoming-Call-Connected
1741 The Incoming-Call-Connected message is a PPTP control message sent by
1742 the PAC to the PNS in response to a received Incoming-Call-Reply. It
1743 provides information to the PNS about particular parameters used for
1744 the call. It also provides information to allow the PNS to regulate
1745 the transmission of data to the PAC for this session.
1747 This message is the third in the three-way handshake used by PPTP for
1748 establishing incoming calls. It provides a mechanism for providing
1749 the PNS with additional information about the call that cannot, in
1750 general, be obtained at the time the Incoming-Call-Request is issued
1751 by the PAC.
1753 0 1 2 3
1754 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
1755 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1756 | Length | PPTP Message Type |
1757 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1758 | Magic Cookie |
1759 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1760 | Control Message Type | Reserved0 |
1761 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1762 | Peer's Call ID | Reserved1 |
1763 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1764 | Connect Speed |
1765 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1766 | Packet Recv. Window Size | Packet Transmit Delay |
1767 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1768 | Framing Type |
1769 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1772 Length Total length in octets of this PPTP
1773 message, including the entire PPTP
1774 header.
1776 PPTP Message Type 1 for Control Message.
1778 Magic Cookie 0x1A2B3C4D.
1780 Control Message Type 11 for Incoming-Call-Connected.
1782 Reserved0 This field MUST be 0.
1784 Peer's Call ID This field is set to the value received
1785 in the Call ID field of the corresponding
1786 Incoming-Call-Reply message. It is used
1790 Hamzeh, et al [Page 32]
1792 Internet Draft PPTP July 1997
1795 by the PNS to match the Incoming-Call-
1796 Connected with the Incoming-Call-Reply it
1797 issued.
1799 Connect Speed The actual connection speed used, in
1800 bits/second.
1802 Packet Recv. Window Size The number of received data packets the
1803 PAC will buffer for this session.
1805 Packet Transmit Delay A measure of the packet processing delay
1806 that might be imposed on data sent to the
1807 PAC from the PNS. This value is
1808 specified in units of 1/10 seconds. See
1809 Appendix A for a description of how this
1810 value is determined and used.
1812 Framing Type A value indicating the type of PPP
1813 framing being used by this incoming call.
1815 1 - Call uses asynchronous framing
1817 2 - Call uses synchronous framing
1846 Hamzeh, et al [Page 33]
1848 Internet Draft PPTP July 1997
1851 2.12 Call-Clear-Request
1853 The Call-Clear-Request is a PPTP control message sent by the PNS to
1854 the PAC indicating that a particular call is to be disconnected. The
1855 call being cleared can be either an incoming or outgoing call, in any
1856 state. The PAC responds to this message with a Call-Disconnect-
1857 Notify message.
1859 0 1 2 3
1860 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
1861 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1862 | Length | PPTP Message Type |
1863 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1864 | Magic Cookie |
1865 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1866 | Control Message Type | Reserved0 |
1867 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1868 | Call ID | Reserved1 |
1869 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1872 Length Total length in octets of this PPTP
1873 message, including the entire PPTP
1874 header.
1876 PPTP Message Type 1 for Control Message.
1878 Magic Cookie 0x1A2B3C4D.
1880 Control Message Type 12 for Call-Clear-Request.
1882 Reserved0 This field MUST be 0.
1884 Call ID The Call ID assigned by the PNS to this
1885 call. This value is used instead of the
1886 Peer's Call ID because the latter may not
1887 be known to the PNS if the call must be
1888 aborted during call establishment.
1890 Reserved1 This field MUST be 0.
1902 Hamzeh, et al [Page 34]
1904 Internet Draft PPTP July 1997
1907 2.13 Call-Disconnect-Notify
1909 The Call-Disconnect-Notify message is a PPTP control message sent by
1910 the PAC to the PNS. It is issued whenever a call is disconnected,
1911 due to the receipt by the PAC of a Call-Clear-Request or for any
1912 other reason. Its purpose is to inform the PNS of both the
1913 disconnection and the reason for it.
1915 0 1 2 3
1916 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
1917 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1918 | Length | PPTP Message Type |
1919 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1920 | Magic Cookie |
1921 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1922 | Control Message Type | Reserved0 |
1923 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1924 | Call ID | Result Code | Error Code |
1925 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1926 | Cause Code | Reserved1 |
1927 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1928 | |
1929 + Call Statistics (128 octets) +
1930 | |
1931 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1934 Length Total length in octets of this PPTP
1935 message, including the entire PPTP
1936 header.
1938 PPTP Message Type 1 for Control Message.
1940 Magic Cookie 0x1A2B3C4D.
1942 Control Message Type 13 for Call-Disconnect-Notify.
1944 Reserved0 This field MUST be 0.
1946 Call ID The value of the Call ID assigned by the
1947 PAC to this call. This value is used
1948 instead of the Peer's Call ID because the
1949 latter may not be known to the PNS if the
1950 call must be aborted during call
1951 establishment.
1953 Result Code This value indicates the reason for the
1954 disconnect. Current valid Result Code
1958 Hamzeh, et al [Page 35]
1960 Internet Draft PPTP July 1997
1963 values are:
1965 1 (Lost Carrier) - Call disconnected
1966 due to loss of carrier
1968 2 (General Error) - Call disconnected
1969 for the reason indicated in Error
1970 Code
1972 3 (Admin Shutdown) - Call disconnected
1973 for administrative reasons
1975 4 (Request) - Call disconnected due to
1976 received Call-Clear-Request
1978 Error Code This field is set to 0 unless a "General
1979 Error" condition exists, in which case
1980 the Result Code is set to 2 and this
1981 field is set to the value corresponding
1982 to the general error condition as
1983 specified in Section 2.16.
1985 Cause Code This field gives additional disconnect
1986 information. Its value varies depending
1987 on the type of call being disconnected.
1988 For ISDN calls it is the Q.931 cause
1989 code.
1991 Call Statistics This field is an ASCII string containing
1992 vendor-specific call statistics that can
1993 be logged for diagnostic purposes. If
1994 the length of the string is less than
1995 128, the remainder of the field is filled
1996 with octets of value 0.
2014 Hamzeh, et al [Page 36]
2016 Internet Draft PPTP July 1997
2019 2.14 WAN-Error-Notify
2021 The WAN-Error-Notify message is a PPTP control message sent by the
2022 PAC to the PNS to indicate WAN error conditions (conditions that
2023 occur on the interface supporting PPP). The counters in this message
2024 are cumulative. This message should only be sent when an error
2025 occurs, and not more than once every 60 seconds. The counters are
2026 reset when a new call is established.
2028 0 1 2 3
2029 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
2030 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2031 | Length | PPTP Message Type |
2032 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2033 | Magic Cookie |
2034 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2035 | Control Message type | Reserved0 |
2036 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2037 | Peer's Call ID | Reserved1 |
2038 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2039 | CRC Errors |
2040 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2041 | Framing Errors |
2042 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2043 | Hardware Overruns |
2044 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2045 | Buffer Overruns |
2046 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2047 | Time-out Errors |
2048 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2049 | Alignment Errors |
2050 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2053 Length Total length in octets of this PPTP
2054 message, including the entire PPTP
2055 header.
2057 PPTP Message Type 1 for Control Message.
2059 Magic Cookie 0x1A2B3C4D.
2061 Control Message Type 14 for WAN-Error-Notify.
2063 Reserved0 This field MUST be 0.
2065 Peer's Call ID Th Call ID assigned by the PNS to this
2066 call.
2070 Hamzeh, et al [Page 37]
2072 Internet Draft PPTP July 1997
2075 CRC Errors Number of PPP frames received with CRC
2076 errors since session was established.
2078 Framing Errors Number of improperly framed PPP packets
2079 received.
2081 Hardware Overruns Number of receive buffer over-runs since
2082 session was established.
2084 Buffer Overruns Number of buffer over-runs detected since
2085 session was established.
2087 Time-out Errors Number of time-outs since call was
2088 established.
2090 Alignment Errors Number of alignment errors since call was
2091 established.
2126 Hamzeh, et al [Page 38]
2128 Internet Draft PPTP July 1997
2131 2.15 Set-Link-Info
2133 The Set-Link-Info message is a PPTP control message sent by the PNS
2134 to the PAC to set PPP-negotiated options. Because these options can
2135 change at any time during the life of the call, the PAC must be able
2136 to update its internal call information dynamically and perform PPP
2137 negotiation on an active PPP session.
2139 0 1 2 3
2140 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
2141 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2142 | Length | PPTP Message Type |
2143 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2144 | Magic Cookie |
2145 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2146 | Control Message type | Reserved0 |
2147 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2148 | Peer's Call ID | Reserved1 |
2149 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2150 | Send ACCM |
2151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2152 | Receive ACCM |
2153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2156 Length Total length in octets of this PPTP
2157 message, including the entire PPTP
2158 header.
2160 PPTP Message Type 1 for Control Message.
2162 Magic Cookie 0x1A2B3C4D.
2164 Control Message Type 15 for Set-Link-Info.
2166 Reserved0 This field MUST be 0.
2168 Peer's Call ID The value of the Call ID assigned by the
2169 PAC to this call.
2171 Reserved1 This field MUST be 0.
2173 Send ACCM The send ACCM value the client should use
2174 to process outgoing PPP packets. The
2175 default value used by the client until
2176 this message is received is 0XFFFFFFFF.
2177 See [7].
2182 Hamzeh, et al [Page 39]
2184 Internet Draft PPTP July 1997
2187 Receive ACCM The receive ACCM value the client should
2188 use to process incoming PPP packets. The
2189 default value used by the client until
2190 this message is received is 0XFFFFFFFF.
2191 See [7].
2238 Hamzeh, et al [Page 40]
2240 Internet Draft PPTP July 1997
2243 2.16 General Error Codes
2245 General error codes pertain to types of errors which are not specific
2246 to any particular PPTP request, but rather to protocol or message
2247 format errors. If a PPTP reply indicates in its Result Code that a
2248 general error occurred, the General Error value should be examined to
2249 determined what the error was. The currently defined General Error
2250 codes and their meanings are:
2252 0 (None) - No general error
2254 1 (Not-Connected) - No control connection exists yet for this
2255 PAC-PNS pair
2257 2 (Bad-Format) - Length is wrong or Magic Cookie value is
2258 incorrect
2260 3 (Bad-Value) - One of the field values was out of range or
2261 reserved field was non-zero
2263 4 (No-Resource) - Insufficient resources to handle this command
2264 now
2266 5 (Bad-Call ID) - The Call ID is invalid in this context
2268 6 (PAC-Error) - A generic vendor-specific error occurred in
2269 the PAC
2294 Hamzeh, et al [Page 41]
2296 Internet Draft PPTP July 1997
2299 3.0 Control Connection Protocol Operation
2301 This section describes the operation of various PPTP control
2302 connection functions and the Control Connection messages which are
2303 used to support them. The protocol operation of the control
2304 connection is simplified because TCP is used to provide a reliable
2305 transport mechanism.
2306 Ordering and retransmission of messages is not a concern at this
2307 level. The TCP connection itself, however, can close at any time and
2308 an appropriate error recovery mechanism must be provided to handle
2309 this case.
2311 Some error recovery procedures are common to all states of the
2312 control connection. If an expected reply does not arrive within 60
2313 seconds, the control connection is closed, unless otherwise
2314 specified. Appropriate logging should be implemented for easy
2315 determination of the problems and the reasons for closing the control
2316 connection.
2318 Receipt of an invalid or malformed Control Connection message should
2319 be logged appropriately, and the control connection should be closed
2320 and restarted to ensure recovery into a known state.
2323 3.1 Control Connection States
2325 The control connection relies on a standard TCP connection for its
2326 service. The PPTP control connection protocol is not distinguishable
2327 between the PNS and PAC, but is distinguishable between the
2328 originator and receiver. The originating peer is the one which first
2329 attempts the TCP open. Since either PAC or PNS may originate a
2330 connection, it is possible for a TCP collision to occur. See Section
2331 3.1.3 for a description of this situation.
2350 Hamzeh, et al [Page 42]
2352 Internet Draft PPTP July 1997
2355 3.1.1 Control Connection Originator (may be PAC or PNS)
2357 TCP Open Indication
2358 /Send Start Control
2359 Connection Request +-----------------+
2360 +------------------------------------>| wait_ctl_reply |
2361 | +-----------------+
2362 | Collision/See (3.1.3) Close TCP V V V Receive Start Ctl
2363 | +-------------------------------+ | | Connection Reply
2364 | | | | Version OK
2365 ^ V | V
2366 +-----------------+ Receive Start Ctl | +-----------------+
2367 | idle | Connection Reply | | established |
2368 +-----------------+ Version Not OK | +-----------------+
2369 ^ | V Local Terminate
2370 | Receive Stop Control | | /Send Stop
2371 | Connection Request | | Control Request
2372 | /Send Stop Control Reply V V
2373 | Close TCP +-----------------+
2374 +-------------------------------------| wait_stop_reply |
2375 +-----------------+
2379 idle
2381 The control connection originator attempts to open a TCP connection
2382 to the peer during idle state. When the TCP connection is open, the
2383 originator transmits a send Start-Control-Connection-Request and then
2384 enters the wait_ctl_reply state.
2386 wait_ctl_reply
2388 The originator checks to see if another TCP connection has been
2389 requested from the same peer, and if so, handles the collision
2390 situation described in Section 3.1.3.
2392 When a Start-Control-Connection-Reply is received, it is examined for
2393 a compatible version. If the version of the reply is lower than the
2394 version sent in the request, the older (lower) version should be used
2395 provided it is supported. If the version in the reply is earlier and
2396 supported, the originator moves to the established state. If the
2397 version is earlier and not supported, a Stop-Control-Connection-
2398 Request SHOULD be sent to the peer and the originator moves into the
2399 wait_stop_reply state.
2406 Hamzeh, et al [Page 43]
2408 Internet Draft PPTP July 1997
2411 established
2413 An established connection may be terminated by either a local
2414 condition or the receipt of a Stop-Control-Connection-Request. In the
2415 event of a local termination, the originator MUST send a Stop-
2416 Control-Connection-Request and enter the wait_stop_reply state.
2418 If the originator receives a Stop-Control-Connection-Request it
2419 SHOULD send a Stop-Control-Connection-Reply and close the TCP
2420 connection making sure that the final TCP information has been
2421 "pushed" properly.
2423 wait_stop_reply
2425 If a Stop-Control-Connection-Reply is received, the TCP connection
2426 SHOULD be closed and the control connection becomes idle.
2428 3.1.2 Control connection Receiver (may be PAC or PNS)
2431 Receive Start Control Connection Request
2432 Version Not OK/Send Start Control Connection
2433 Reply with Error
2434 +--------+
2435 | | Receive Control Connection Request Version OK
2436 | | /Send Start Control Connection Reply
2437 | | +----------------------------------------+
2438 ^ V ^ V
2439 +-----------------+ Receive Start Ctl +-----------------+
2440 | Idle | Connection Request | Established |
2441 +-----------------+ /Send Stop Reply +-----------------+
2442 ^ ^ Close TCP V V Local Terminate
2443 | +-------------------------------------+ | /Send Stop
2444 | | Control Conn.
2445 | V Request
2446 | +-----------------+
2447 +-------------------------------------| Wait-Stop-Reply |
2448 Receive Stop Control +-----------------+
2449 Connection Reply
2450 /Close TCP
2452 idle
2454 The control connection receiver waits for a TCP open attempt on port
2455 1723. When notified of an open TCP connection, it should prepare to
2456 receive PPTP messages. When a Start-Control-Connection-Request is
2457 received its version field should be examined. If the version is
2458 earlier than the receiver's version and the earlier version can be
2462 Hamzeh, et al [Page 44]
2464 Internet Draft PPTP July 1997
2467 supported by the receiver, the receiver SHOULD send a Start-Control-
2468 Connection-Reply. If the version is earlier than the receiver's
2469 version and the version cannot be supported, the receiver SHOULD send
2470 a Start- Connection-Reply message, close the TCP connection and
2471 remain in the idle state. If the receiver's version is the same as
2472 earlier than the peer's, the receiver SHOULD send a Start-Control-
2473 Connection-Reply with the receiver's version and enter the
2474 established state.
2476 established
2478 An established connection may be terminated by either a local
2479 condition or the reception of a Stop-Control-Connection-Request. In
2480 the event of a local termination, the originator MUST send a Stop-
2481 Control-Connection-Request and enter the wait_stop_reply state.
2483 If the originator receives a Stop-Control-Connection-Request it
2484 SHOULD send a Stop-Control-Connection-Reply and close the TCP
2485 connection, making sure that the final TCP information has been
2486 "pushed" properly.
2488 wait_stop_reply
2490 If a Stop-Control-Connection-Reply is received, the TCP connection
2491 SHOULD be closed and the control connection becomes idle.
2493 3.1.3 Start Control Connection Initiation Request Collision
2495 A PAC and PNS must have only one control connection between them. It
2496 is possible, however, for a PNS and a PAC to simultaneously attempt
2497 to establish a control connection to each other. When a Start-
2498 Control-Connection-Request is received on one TCP connection and
2499 another Start-Control-Connection-Request has already been sent on
2500 another TCP connection to the same peer, a collision has occurred.
2502 The "winner" of the initiation race is the peer with the higher IP
2503 address (compared as 32 bit unsigned values, network number more
2504 significant). For example, if the peers 192.33.45.17 and 192.33.45.89
2505 collide, the latter will be declared the winner.
2507 The loser will immediately close the TCP connection it initiated,
2508 without sending any further PPTP control messages on it and will
2509 respond to the winner's request with a Start-Control-Connection-Reply
2510 message. The winner will wait for the Start-Control-Connection-Reply
2511 on the connection it initiated and also wait for a TCP termination
2512 indication on the connection the loser opened. The winner MUST NOT
2513 send any messages on the connection the loser initiated.
2518 Hamzeh, et al [Page 45]
2520 Internet Draft PPTP July 1997
2523 3.1.3 Keep Alives and Timers
2525 A control connection SHOULD be closed by closing the underlying TCP
2526 connection under the following circumstances:
2528 1. If a control connection is not in the established state (i.e.,
2529 Start-Control-Connection-Request and Start-Control-Connection-
2530 Reply have not been exchanged), a control connection SHOULD be
2531 closed after 60 seconds by a peer waiting for a Start-Control-
2532 Connection-Request or Start-Control-Connection-Reply message.
2534 2. If a peer's control connection is in the established state and has
2535 not received a control message for 60 seconds, it SHOULD send a
2536 Echo-Request message. If an Echo-Reply is not received 60 seconds
2537 after the Echo-Request message transmission, the control
2538 connection SHOULD be closed.
2540 3.2 Call States
2542 3.2.1 Timing considerations
2544 Because of the real-time nature of telephone signaling, both the PNS
2545 and PAC should be implemented with multi-threaded architectures such
2546 that messages related to multiple calls are not serialized and
2547 blocked. The transit delay between the PAC and PNS should not exceed
2548 one second. The call and connection state figures do not specify
2549 exceptions caused by timers. The implicit assumption is that since
2550 the TCP-based control connection is being verified with keep-alives,
2551 there is less need to maintain strict timers for call control
2552 messages.
2554 Establishing outbound international calls, including the modem
2555 training and negotiation sequences, may take in excess of 1 minute so
2556 the use of short timers is discouraged.
2558 If a state transition does not occur within 1 minute (except for
2559 connections in the idle or established states), the integrity of the
2560 protocol processing between the peers is suspect and the ENTIRE
2561 CONTROL CONNECTION should be closed and restarted. All Call IDs are
2562 logically released whenever a control connection is started. This
2563 presumably also helps in preventing toll calls from being "lost" and
2564 never cleared.
2566 3.2.2 Call ID values
2568 Each peer assigns a Call ID value to each user session it requests or
2569 accepts. This Call ID value MUST be unique for the tunnel between the
2570 PNS and PAC to which it belongs. Tunnels to other peers can use the
2574 Hamzeh, et al [Page 46]
2576 Internet Draft PPTP July 1997
2579 same Call ID number so the receiver of a packet on a tunnel needs to
2580 associate a user session with a particular tunnel and Call ID. It is
2581 suggested that the number of potential Call ID values for each tunnel
2582 be at least twice as large as the maximum number of calls expected on
2583 a given tunnel.
2585 A session is defined by the triple (PAC, PNS, Call ID).
2587 3.2.3 Incoming calls
2589 An Incoming-Call-Request message is generated by the PAC when an
2590 associated telephone line rings. The PAC selects a Call ID and serial
2591 number and indicates the call bearer type. Modems should always
2592 indicate analog call type. ISDN calls should indicate digital when
2593 unrestricted digital service or rate adaption is used and analog if
2594 digital modems are involved. Dialing number, dialed number, and
2595 subaddress may be included in the message if they are available from
2596 the telephone network.
2598 Once the PAC sends the Incoming-Call-Request, it waits for a response
2599 from the PNS but does not answer the call from the telephone network.
2600 The PNS may choose not to accept the call if:
2602 - No resources are available to handle more sessions
2604 - The dialed, dialing, or subaddress fields are not indicative of
2605 an authorized user
2607 - The bearer service is not authorized or supported
2609 If the PNS chooses to accept the call, it responds with an Outgoing-
2610 Call-Reply which also indicates window sizes (see Appendix B). When
2611 the PAC receives the Outgoing-Call-Reply, it attempts to connect the
2612 call, assuming the calling party has not hung up. A final call
2613 connected message from the PAC to the PNS indicates that the call
2614 states for both the PAC and the PNS should enter the established
2615 state.
2617 When the dialed-in client hangs up, the call is cleared normally and
2618 the PAC sends a Call-Disconnect-Notify message. If the PNS wishes to
2619 clear a call, it sends a Call-Clear-Request message and then waits
2620 for a Call-Disconnect-Notify.
2630 Hamzeh, et al [Page 47]
2632 Internet Draft PPTP July 1997
2635 3.2.3.1 PAC Incoming Call States
2638 Ring/Send Incoming Call Request +-----------------+
2639 +----------------------------------------->| wait_reply |
2640 | +-----------------+
2641 | Receive Incoming Call Reply V V V
2642 | Not Accepting | | | Receive Incoming
2643 | +--------------------------------+ | | Call Reply Accepting
2644 | | +------------------------------+ | /Answer call; Send
2645 | | | Abort/Send Call | Call Connected
2646 ^ V V Disconnect Notify V
2647 +-----------------+ +-----------------+
2648 | idle |<-----------------------------| established |
2649 +-----------------+ Receive Clear Call Request +-----------------+
2650 or telco call dropped
2651 or local disconnect
2652 /Send Call Disconnect Notify
2656 The states associated with the PAC for incoming calls are:
2658 idle
2660 The PAC detects an incoming call on one of its telco interfaces.
2661 Typically this means an analog line is ringing or an ISDN TE has
2662 detected an incoming Q.931 SETUP message. The PAC sends an Incoming-
2663 Call-Request message and moves to the wait_reply state.
2665 wait_reply
2667 The PAC receives an Incoming-Call-Reply message indicating non-
2668 willingness to accept the call (general error or don't accept) and
2669 moves back into the idle state. If the reply message indicates that
2670 the call is accepted, the PAC sends an Incoming-Call-Connected
2671 message and enters the established state.
2673 established
2675 Data is exchanged over the tunnel. The call may be cleared following:
2677 An event on the telco connection. The PAC sends a Call-
2678 Disconnect-Notify message
2680 Receipt of a Call-Clear-Request. The PAC sends a Call-Disconnect-
2681 Notify message
2686 Hamzeh, et al [Page 48]
2688 Internet Draft PPTP July 1997
2691 A local reason. The PAC sends a Call-Disconnect-Notify message.
2693 3.2.3.2 PNS Incoming Call States
2697 Receive Incoming Call Request
2698 /Send Incoming Call Reply +-----------------+
2699 Not Accepting if Error | Wait-Connect |
2700 +-----+ +-----------------+
2701 | | Receive Incoming Call Req. ^ V V
2702 | | /Send Incoming Call Reply OK | | | Receive Incoming
2703 | | +--------------------------------+ | | Call Connect
2704 ^ V ^ V------------------------------+ V
2705 +-----------------+ Receive Call Disconnect +-----------------+
2706 | Idle | Notify +- | Established |
2707 +-----------------+ | +-----------------+
2708 ^ ^ | V Local Terminate
2709 | +----------------------------+ | /Send Call Clear
2710 | Receive Call Disconnect | Request
2711 | Notify V
2712 | +-----------------+
2713 +--------------------------------------| Wait-Disconnect |
2714 Receive Call Disconnect +-----------------+
2715 Notify
2719 The states associated with the PNS for incoming calls are:
2721 idle
2723 An Incoming-Call-Request message is received. If the request is not
2724 acceptable, an Incoming-Call-Reply is sent back to the PAC and the
2725 PNS remains in the idle state. If the Incoming-Call-Request message
2726 is acceptable, an Incoming-Call-Reply is sent indicating accept in
2727 the result code. The session moves to the wait_connect state.
2729 wait_connect
2731 If the session is connected on the PAC, the PAC sends an incoming
2732 call connect message to the PNS which then moves into established
2733 state. The PAC may send a Call-Disconnect-Notify to indicate that the
2734 incoming caller could not be connected. This could happen, for
2735 example, if a telephone user accidently places a standard voice call
2736 to a PAC resulting in a handshake failure on the called modem.
2742 Hamzeh, et al [Page 49]
2744 Internet Draft PPTP July 1997
2747 established
2749 The session is terminated either by receipt of a Call-Disconnect-
2750 Notify message from the PAC or by sending a Call-Clear-Request. Once
2751 a Call-Clear-Request has been sent, the session enters the
2752 wait_disconnect state.
2754 wait_disconnect
2756 Once a Call-Disconnect-Notify is received the session moves back to
2757 the idle state.
2759 3.2.4 Outgoing calls
2761 Outgoing messages are initiated by a PNS and instruct a PAC to place
2762 a call on a telco interface. There are only two messages for outgoing
2763 calls: Outgoing-Call-Request and Outgoing-Call-Reply. The PNS sends
2764 an Outgoing-Call-Request specifying the dialed party phone number and
2765 subaddress as well as speed and window parameters. The PAC MUST
2766 respond to the Outgoing-Call-Request message with an Outgoing-Call-
2767 Reply message once the PAC determines that:
2769 The call has been successfully connected
2771 A call failure has occurred for reasons such as: no interfaces are
2772 available for dial-out, the called party is busy or does not
2773 answer, or no dial tone is detected on the interface chosen for
2774 dialing
2798 Hamzeh, et al [Page 50]
2800 Internet Draft PPTP July 1997
2803 3.2.4.1 PAC Outgoing Call States
2807 Receive Outgoing Call Request in Error
2808 /Send Outgoing Call Reply with Error
2809 |--------+
2810 | | Receive Outgoing Call Request No Error
2811 | | /Off Hook; Dial
2812 | | +-----------------------------------------
2813 ^ V ^ V
2814 +-----------------+ Incomplete Call +-----------------+
2815 | idle | /Send Outgoing Call | wait_cs_ans |
2816 +-----------------+ Reply with Error +-----------------+
2817 ^ ^ or Recv. Call Clear Req. V V Telco Answer
2818 | | /Send Disconnect Notify| | /Send Outgoing
2819 | +-------------------------------------+ | Call Reply.
2820 | V
2821 | +-----------------+
2822 +-------------------------------------| established |
2823 Receive Call Clear Request +-----------------+
2824 or local terminate
2825 or telco disconnect
2826 /Hangup call and send
2827 Call Disconnect Notify
2831 The states associated with the PAC for outgoing calls are:
2833 idle
2835 Received Outgoing-Call-Request. If this is received in error, respond
2836 with an Outgoing-Call-Reply with error condition set. Otherwise,
2837 allocate physical channel to dial on. Place the outbound call, wait
2838 for a connection, and move to the wait_cs_ans state.
2840 wait_cs_ans
2842 If the call is incomplete, send an Outgoing-Call-Reply with a non-
2843 zero Error Code. If a timer expires on an outbound call, send back an
2844 Outgoing-Call-Reply with a non-zero Error Code. If a circuit switched
2845 connection is established, send an Outgoing-Call-Reply indicating
2846 success.
2848 established
2850 If a Call-Clear-Request is received, the telco call SHOULD be
2854 Hamzeh, et al [Page 51]
2856 Internet Draft PPTP July 1997
2859 released via appropriate mechanisms and a Call-Disconnect-Notify
2860 message SHOULD BE sent to the PNS. If the call is disconnected by the
2861 client or by the telco interface, a Call-Disconnect-Notify message
2862 SHOULD be sent to the PNS.
2864 3.2.4.2 PNS Outgoing Call States
2867 Open Indication Abort/Send
2868 /Send Outgoing Call Call Clear
2869 Request +-----------------+ Request
2870 +-------------------------------->| Wait-Reply |------------+
2871 | +-----------------+ |
2872 | Receive Outgoing Call Reply V V Receive Outgoing |
2873 | with Error | | Call Reply |
2874 | +-------------------------------+ | No Error |
2875 ^ V V |
2876 +-----------------+ +-----------------+ |
2877 | Idle |<-----------------------------| Established | |
2878 +-----------------+ Receive Call Disconnect +-----------------+ |
2879 ^ Notify V Local Terminate |
2880 | | /Send Call Clear |
2881 | | Request |
2882 | Receive Call Disconnect V |
2883 | Notify +-----------------+ |
2884 +---------------------------------| Wait-Disconnect |<-----------+
2885 +-----------------+
2888 The states associated with the PNS for outgoing calls are:
2890 idle
2892 An Outgoing-Call-Request message is sent to the PAC and the session
2893 moves into the wait_reply state.
2895 wait_reply
2897 An Outgoing-Call-Reply is received which indicates an error. The
2898 session returns to idle state. No telco call is active. If the
2899 Outgoing-Call-Reply does not indicate an error, the telco call is
2900 connected and the session moves to the established state.
2902 established
2904 If a Call-Disconnect-Notify is received, the telco call has been
2905 terminated for the reason indicated in the Result and Cause Codes.
2906 The session moves back to the idle state. If the PNS chooses to
2910 Hamzeh, et al [Page 52]
2912 Internet Draft PPTP July 1997
2915 terminate the session, it sends a Call-Clear-Request to the PAC and
2916 then enters the wait_disconnect state.
2918 wait_disconnect
2920 A session disconnection is waiting to be confirmed by the PAC. Once
2921 the PNS receives the Call-Disconnect-Notify message, the session
2922 enters idle state.
2924 4.0 Tunnel Protocol Operation
2926 The user data carried by the PPTP protocol are PPP data packets. PPP
2927 packets are carried between the PAC and PNS, encapsulated in GRE
2928 packets which in turn are carried over IP. The encapsulated PPP
2929 packets are essentially PPP data packets less any media specific
2930 framing elements. No HDLC flags, bit insertion, control characters,
2931 or control character escapes are included. No CRCs are sent through
2932 the tunnel. The IP packets transmitted over the tunnels between a PAC
2933 and PNS has the following general structure:
2935 +--------------------------------+
2936 | Media Header |
2937 +--------------------------------+
2938 | IP Header |
2939 +--------------------------------+
2940 | GRE Header |
2941 +--------------------------------+
2942 | PPP Packet |
2943 +--------------------------------+
2946 4.1 Enhanced GRE header
2948 The GRE header used in PPTP is enhanced slightly from that specified
2949 in the current GRE protocol specification [1,2]. The main difference
2950 involves the definition of a new Acknowledgment Number field, used to
2951 determine if a particular GRE packet or set of packets has arrived at
2952 the remote end of the tunnel. This Acknowledgment capability is not
2953 used in conjunction with any retransmission of user data packets. It
2954 is used instead to determine the rate at which user data packets are
2955 to be transmitted over the tunnel for a given user session.
2957 The format of the enhanced GRE header is as follows:
2966 Hamzeh, et al [Page 53]
2968 Internet Draft PPTP July 1997
2972 0 1 2 3
2973 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
2974 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2975 |C|R|K|S|s|Recur|A| Flags | Ver | Protocol Type |
2976 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2977 | Key (HW) Payload Length | Key (LW) Call ID |
2978 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2979 | Sequence Number (Optional) |
2980 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2981 | Acknowledgment Number (Optional) |
2982 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2985 C (Bit 0) Checksum Present. Set to zero
2986 (0).
2988 R (Bit 1) Routing Present. Set to zero
2989 (0).
2991 K (Bit 2) Key Present. Set to one (1).
2993 S (Bit 3) Sequence Number Present. Set to
2994 one (1) if a payload (data) packet is
2995 present. Set to zero (0) if payload is
2996 not present (GRE packet is an
2997 Acknowledgment only).
2999 s (Bit 4) Strict source route present. Set
3000 to zero (0).
3002 Recur (Bits 5-7) Recursion control. Set to
3003 zero (0).
3005 A (Bit 8) Acknowledgment sequence number
3006 present. Set to one (1) if packet
3007 contains Acknowledgment Number to be used
3008 for acknowledging previously transmitted
3009 data.
3011 Flags (Bits 9-12) Must be set to zero (0).
3013 Ver (Bits 13-15) Must contain 1 (enhanced
3014 GRE).
3016 Protocol Type Set to hex 880B [8].
3018 Key Use of the Key field is up to the
3022 Hamzeh, et al [Page 54]
3024 Internet Draft PPTP July 1997
3027 implementation.
3028 PPTP uses it as follows:
3030 Payload Length
3031 (High 2 octets of Key) Size of the
3032 payload, not including the GRE header
3034 Call ID
3035 (Low 2 octets) Contains the Peer's
3036 Call ID for the session to which this
3037 packet belongs.
3039 Sequence Number Contains the sequence number of the
3040 payload. Present if S bit (Bit 3) is one
3041 (1).
3043 Acknowledgment Number Contains the sequence number of the
3044 highest numbered GRE packet received by
3045 the sending peer for this user session.
3046 Present if A bit (Bit 8) is one (1).
3048 The payload section contains a PPP data packet without any media
3049 specific framing elements.
3051 The sequence numbers involved are per packet sequence numbers. The
3052 sequence number for each user session is set to zero at session
3053 startup. Each packet sent for a given user session which contains a
3054 payload (and has the S bit (Bit 3) set to one) is assigned the next
3055 consecutive sequence number for that session.
3057 This protocol allows acknowledgments to be carried with the data and
3058 makes the overall protocol more efficient, which in turn requires
3059 less buffering of packets.
3062 4.2 Sliding Window Protocol
3064 The sliding window protocol used on the PPTP data path is used for
3065 flow control by each side of the data exchange. The enhanced GRE
3066 protocol allows packet acknowledgments to be piggybacked on data
3067 packets. Acknowledgments can also be sent separately from data
3068 packets. Again, the main purpose of the sliding window protocol is
3069 for flow control--retransmissions are not performed by the tunnel
3070 peers.
3078 Hamzeh, et al [Page 55]
3080 Internet Draft PPTP July 1997
3083 4.3 Multi Packet Acknowledgment
3085 One feature of the PPTP sliding window protocol is that it allows the
3086 acknowledgment of multiple packets with a single acknowledgment. All
3087 outstanding packets with a sequence number lower or equal to the
3088 acknowledgment number are considered acknowledged. Time-out
3089 calculations are performed using the time the packet corresponding to
3090 the highest sequence number being acknowledged was transmitted.
3093 Adaptive time-out calculations are only performed when an
3094 Acknowledgment is received. When multi-packet acknowledgments are
3095 used, the overhead of the adaptive time-out algorithm is reduced. The
3096 PAC is not required to transmit multi-packet acknowledgments; it can
3097 instead acknowledge each packet individually as it is delivered to
3098 the PPP client.
3100 4.4 Out-of-Sequence Packets
3102 Occasionally packets lose their sequencing across a complicated
3103 internetwork. Say, for example that a PNS sends packets 0 to 5 to a
3104 PAC. Because of rerouting in the internetwork, packet 4 arrives at
3105 the PAC before packet 3. The PAC acknowledges packet 4, and may
3106 assume packet 3 is lost. This acknowledgment grants window credit
3107 beyond packet 4.
3109 When the PAC does receive packet 3, it MUST not attempt to transmit
3110 it to the corresponding PPP client. To do so could cause problems,
3111 as proper PPP protocol operation is premised upon receiving packets
3112 in sequence. PPP does properly deal with the loss of packets, but
3113 not with reordering so out of sequence packets between the PNS and
3114 PAC MUST be silently discarded, or they may be reordered by the
3115 receiver. When packet 5 comes in, it is acknowledged by the PAC
3116 since it has a higher sequence number than 4, which was the last
3117 highest packet acknowledged by the PAC. Packets with duplicate
3118 sequence numbers should never occur since the PAC and PNS never
3119 retransmit GRE packets. A robust implementation will silently
3120 discard duplicate GRE packets, should it receive any.
3122 5.0 Security Considerations
3124 Security issues are not addressed in this document. End to end
3125 security is addressed by PPP. Further security considerations will be
3126 addressed by the next version of PPTP.
3134 Hamzeh, et al [Page 56]
3136 Internet Draft PPTP July 1997
3139 6.0 Authors' Addresses
3142 Kory Hamzeh
3143 Ascend Communications
3144 1275 Harbor Bay Parkway
3145 Alameda, CA 94502
3146 Email: kory@ascend.com
3148 Gurdeep Singh Pall
3149 Microsoft Corporation
3150 Redmond, WA
3151 Email: gurdeep@microsoft.com
3153 William Verthein
3154 U.S. Robotics/3Com
3156 Jeff Taarud
3157 Copper Mountain Networks
3159 W. Andrew Little
3160 ECI Telematics
3162 7.0 References
3164 [1] Hanks, S. Li, T., Farinacci, D. Traina, P., "Generic Routing
3165 Encapsulation (GRE)", RFC 1701, October 1994.
3167 [2] Hanks, S. Li, T., Farinacci, D. Traina, P., "Generic Routing
3168 Encapsulation (GRE) over IPv4 Networks", RFC 1702, October 1994.
3170 [3] Lloyd, B. Simpson, W., "PPP Authentication Protocols", RFC 1334,
3171 October 1992.
3173 [4] Postel, J. B., "Transmission Control Protocol", RFC 791,
3174 September 1981
3176 [5] Postel, J. B., "User Data Protocol", RFC 768, August 1980.
3178 [6] Reynolds, J., Postel, J., "Assigned Numbers", RFC 1700, October,
3179 1994.
3181 [7] Simpson, W., editor, "The Point-to-Point Protocol (PPP)", RFC
3182 1661, July 1994.
3184 [8] Ethertype for PPP, Reserved with Xerox Corporation.
3190 Hamzeh, et al [Page 57]
3192 Internet Draft PPTP July 1997
3195 Appendix A. Acknowledgment Time-Outs
3198 PPTP uses sliding windows and time-outs to provide both user session
3199 flow-control across the internetwork and to perform efficient data
3200 buffering to keep the PAC-PNS data channels full without causing
3201 receive buffer overflow. PPTP requires that a time-out be used to
3202 recover from dropped data or acknowledgment packets. The exact
3203 implementation of the time-out is vendor-specific. It is suggested
3204 that an adaptive time-out be implemented with backoff for congestion
3205 control. The time-out mechanism proposed here has the following
3206 properties:
3208 Independent time-outs for each session. A device (PAC or PNS) will
3209 have to maintain and calculate time-outs for every active session.
3211 An administrator-adjustable maximum time-out, MaxTimeOut, unique
3212 to each device.
3214 An adaptive time-out mechanism that compensates for changing
3215 throughput. To reduce packet processing overhead, vendors may
3216 choose not to recompute the adaptive time-out for every received
3217 acknowledgment. The result of this overhead reduction is that the
3218 time-out will not respond as quickly to rapid network changes.
3220 Timer backoff on time-out to reduce congestion. The backed-off
3221 timer value is limited by the configurable maximum time-out value.
3222 Timer backoff is done every time an acknowledgment time-out
3223 occurs.
3225 In general, this mechanism has the desirable behavior of quickly
3226 backing off upon a time-out and of slowly decreasing the time-out
3227 value as packets are delivered without time-outs.
3229 Some definitions:
3231 Packet Processing Delay (PPD) is the amount of time required for
3232 each side to process the maximum amount of data buffered in their
3233 receive packet sliding window. The PPD is the value exchanged
3234 between the PAC and PNS when a call is established. For the PNS,
3235 this number should be small. For a PAC making modem connections,
3236 this number could be significant.
3238 Sample is the actual amount of time incurred receiving an
3239 acknowledgment for a packet. The Sample is measured, not
3240 calculated.
3242 Round-Trip Time (RTT) is the estimated round-trip time for an
3246 Hamzeh, et al [Page 58]
3248 Internet Draft PPTP July 1997
3251 Acknowledgment to be received for a given transmitted packet. When
3252 the network link is a local network, this delay will be minimal
3253 (if not zero). When the network link is the Internet, this delay
3254 could be substantial and vary widely. RTT is adaptive: it will
3255 adjust to include the PPD and whatever shifting network delays
3256 contribute to the time between a packet being transmitted and
3257 receiving its acknowledgment.
3259 Adaptive Time-Out (ATO) is the time that must elapse before an
3260 acknowledgment is considered lost. After a time-out, the sliding
3261 window is partially closed and the ATO is backed off.
3264 Packet Processing Delay (PPD)
3266 The PPD parameter is a 16-bit word exchanged during the Call Control
3267 phase that represents tenths of a second (64 means 6.4 seconds). The
3268 protocol only specifies that the parameter is exchanged, it does not
3269 specify how it is calculated. The way values for PPD are calculated
3270 is implementation-dependent and need not be variable (static time-
3271 outs are allowed). The PPD must be exchanged in the call connect
3272 sequences, even if it remains constant in an implementation. One
3273 possible way to calculate the PPD is:
3275 PPD' = ((PPP_MAX_DATA_MTU - Header) * WindowSize * 8) / ConnectRate
3276 PPD = PPD' + PACFudge
3278 Header is the total size of the IP and GRE headers, which is 36. The
3279 MTU is the overall MTU for the internetwork link between the PAC and
3280 PNS. WindowSize represents the number of packets in the sliding
3281 window, and is implementation-dependent. The latency of the
3282 internetwork could be used to pick a window size sufficient to keep
3283 the current session's pipe full. The constant 8 converts octets to
3284 bits (assuming ConnectRate is in bits per second). If ConnectRate is
3285 in bytes per second, omit the 8. PACFudge is not required but can be
3286 used to take overall processing overhead of the PAC into account.
3288 The value of PPD is used to seed the adaptive algorithm with the
3289 initial RTT[n-1] value.
3291 Sample
3293 Sample is the actual measured time for a returned acknowledgment.
3295 Round-Trip Time (RTT)
3297 The RTT value represents an estimate of the average time it takes for
3298 an acknowledgment to be received after a packet is sent to the remote
3302 Hamzeh, et al [Page 59]
3304 Internet Draft PPTP July 1997
3307 end of the tunnel.
3310 A.1 Calculating Adaptive Acknowledgment Time-Out
3312 We still must decide how much time to allow for acknowledgments to
3313 return. If the time-out is set too high, we may wait an unnecessarily
3314 long time for dropped packets. If the time-out is too short, we may
3315 time out just before the acknowledgment arrives. The acknowledgment
3316 time-out should also be reasonable and responsive to changing network
3317 conditions.
3319 The suggested adaptive algorithm detailed below is based on the TCP
3320 1989 implementation and is explained in Richard Steven's book TCP/IP
3321 Illustrated, Volume 1 (page 300). 'n' means this iteration of the
3322 calculation, and 'n-1' refers to values from the last calculation.
3324 DIFF[n] = SAMPLE[n] - RTT[n-1]
3325 DEV[n] = DEV[n-1] + (beta * (|DIFF[n]| - DEV[n-1]))
3326 RTT[n] = RTT[n-1] + (alpha * DIFF[n])
3327 ATO[n] = MIN (RTT[n] + (chi * DEV[n]), MaxTimeOut)
3329 DIFF represents the error between the last estimated round-trip
3330 time and the measured time. DIFF is calculated on each iteration.
3332 DEV is the estimated mean deviation. This approximates the
3333 standard deviation. DEV is calculated on each iteration and
3334 stored for use in the next iteration. Initially, it is set to 0.
3336 RTT is the estimated round-trip time of an average packet. RTT is
3337 calculated on each iteration and stored for use in the next
3338 iteration. Initially, it is set to PPD.
3340 ATO is the adaptive time-out for the next transmitted packet. ATO
3341 is calculated on each iteration. Its value is limited, by the MIN
3342 function, to be a maximum of the configured MaxTimeOut value.
3344 Alpha is the gain for the average and is typically 1/8 (0.125).
3346 Beta is the gain for the deviation and is typically 1/4 (0.250).
3348 Chi is the gain for the time-out and is typically set to 4.
3350 To eliminate division operations for fractional gain elements, the
3351 entire set of equations can be scaled. With the suggested gain
3352 constants, they should be scaled by 8 to eliminate all division. To
3353 simplify calculations, all gain values are kept to powers of two so
3354 that shift operations can be used in place of multiplication or
3358 Hamzeh, et al [Page 60]
3360 Internet Draft PPTP July 1997
3363 division.
3366 A.2 Congestion Control: Adjusting for Time-Out
3368 This section describes how the calculation of ATO is modified in the
3369 case where a time-out does occur. When a time-out occurs, the time-
3370 out value should be adjusted rapidly upward. Although the GRE
3371 packets are not retransmitted when a time-out occurs, the time-out
3372 should be adjusted up toward a maximum limit. To compensate for
3373 shifting internetwork time delays, a strategy must be employed to
3374 increase the time-out when it expires. A simple formula called
3375 Karn's Algorithm is used in TCP implementations and may be used in
3376 implementing the backoff timers for the PNS or the PAC. Notice that
3377 in addition to increasing the time-out, we are also shrinking the
3378 size of the window as described in the next section.
3380 Karn's timer backoff algorithm, as used in TCP, is:
3383 NewTIMEOUT = delta * TIMEOUT
3385 Adapted to our time-out calculations, for an interval in which a
3386 time-out occurs, the new ATO is calculated as:
3388 RTT[n] = delta * RTT[n-1]
3389 DEV[n] = DEV[n-1]
3390 ATO[n] = MIN (RTT[n] + (chi * DEV[n]), MaxTimeOut)
3392 In this modified calculation of ATO, only the two values that
3393 contribute to ATO and that are stored for the next iteration are
3394 calculated. RTT is scaled by chi, and DEV is unmodified. DIFF is not
3395 carried forward and is not used in this scenario. A value of 2 for
3396 Delta, the time-out gain factor for RTT, is suggested.
3398 Appendix B. Acknowledgment Time-Out and Window Adjustment
3400 B.1 Initial Window Size
3402 Although each side has indicated the maximum size of its receive
3403 window, it is recommended that a slow start method be used to begin
3404 transmitting data. The initial window size on the transmitter is set
3405 to half the maximum size the receiver requested, with a minimum size
3406 of one packet. The transmitter stops sending packets when the number
3407 of packets awaiting acknowledgment is equal to the current window
3408 size. As the receiver successfully digests each window, the window
3409 size on the transmitter is bumped up by one packet until the maximum
3410 is reached. This method prevents a system from flooding an already
3414 Hamzeh, et al [Page 61]
3416 Internet Draft PPTP July 1997
3419 congested network because no history has been established.
3421 B.2 Closing the Window
3423 When a time-out does occur on a packet, the sender adjusts the size
3424 of the transmit window down to one half its value when it failed.
3425 Fractions are rounded up, and the minimum window size is one.
3427 B.3 Opening the Window
3429 With every successful transmission of a window's worth of packets
3430 without a time-out, the transmit window size is increased by one
3431 packet until it reaches the maximum window size that was sent by the
3432 other side when the call was connected. As stated earlier, no
3433 retransmission is done on a time-out. After a time-out, the
3434 transmission resumes with the window starting at one half the size of
3435 the transmit window when the time-out occurred and adjusting upward
3436 by one each time the transmit window is filled with packets that are
3437 all acknowledged without time-outs.
3439 B.4 Window Overflow
3441 When a receiver's window overflows with too many incoming packets,
3442 excess packets are thrown away. This situation should not arise if
3443 the sliding window procedures are being properly followed by the
3444 transmitter and receiver. It is assumed that, on the transmit side,
3445 packets are buffered for transmission and are no longer accepted from
3446 the packet source when the transmit buffer fills.
3470 Hamzeh, et al [Page 62]