idnits 2.17.1 draft-ietf-pppext-pptp-10.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == It seems as if not all pages are separated by form feeds - found 0 form feeds but 57 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 42 instances of too long lines in the document, the longest one being 6 characters in excess of 72. ** The abstract seems to contain references ([12]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 236 has weird spacing: '...ltilink hunt-...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: When the PAC does receive packet 3, it MUST not attempt to transmit it to the corresponding PPP client. To do so could cause problems, as proper PPP protocol operation is premised upon receiving packets in sequence. PPP does properly deal with the loss of packets, but not with reordering so out of sequence packets between the PNS and PAC MUST be silently discarded, or they may be reordered by the receiver. When packet 5 comes in, it is acknowledged by the PAC since it has a higher sequence number than 4, which was the last highest packet acknowledged by the PAC. Packets with duplicate sequence numbers should never occur since the PAC and PNS never retransmit GRE packets. A robust implementation will silently discard duplicate GRE packets, should it receive any. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 1999) is 9140 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: '5' is defined on line 2534, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1334 (ref. '3') (Obsoleted by RFC 1994) ** Obsolete normative reference: RFC 793 (ref. '4') (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 1700 (ref. '6') (Obsoleted by RFC 3232) ** Obsolete normative reference: RFC 2284 (ref. '10') (Obsoleted by RFC 3748) Summary: 13 errors (**), 0 flaws (~~), 6 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group K. Hamzeh 2 Internet-Draft Ascend Communications 3 Category: Informational G. S. Pall 4 Microsoft Corporation 5 W. Verthein 6 3Com 7 J. Taarud 8 Copper Mountain Networks 9 W. A. Little 10 ECI Telematics 11 G. Zorn 12 Microsoft Corporation 13 April 1999 15 Point-to-Point Tunneling Protocol (PPTP) 17 Status of this Memo 19 This document is an Internet-Draft and is in full conformance with 20 all provisions of Section 10 of RFC2026. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six 28 months and may be updated, replaced, or obsoleted by other 29 documents at any time. It is inappropriate to use Internet- Drafts 30 as reference material or to cite them other than as "work in 31 progress." 33 To view the list Internet-Draft Shadow Directories, see 34 http://www.ietf.org/shadow.html. 36 This memo provides information for the Internet community. This 37 memo does not specify an Internet standard of any kind. The 38 distribution of this memo is unlimited. It is filed as and expires October 30, 1999. Please send 40 comments to the PPP Extensions Working Group mailing list (ietf- 41 ppp@merit.edu). 43 Abstract 45 This document specifies a protocol which allows the Point to Point 46 Protocol (PPP) to be tunneled through an IP network. PPTP does not 47 specify any changes to the PPP protocol but rather describes a new 48 vehicle for carrying PPP. A client-server architecture is defined 49 in order to decouple functions which exist in current Network 50 Access Servers (NAS) and support Virtual Private Networks (VPNs). 51 The PPTP Network Server (PNS) is envisioned to run on a general 52 purpose operating system while the client, referred to as a PPTP 53 Access Concentrator (PAC) operates on a dial access platform. PPTP 54 specifies a call-control and management protocol which allows the 55 server to control access for dial-in circuit switched calls 56 originating from a PSTN or ISDN or to initiate outbound circuit- 57 switched connections. PPTP uses an enhanced GRE (Generic Routing 58 Encapsulation) mechanism to provide a flow- and congestion- 59 controlled encapsulated datagram service for carrying PPP packets. 61 Specification of Requirements 63 In this document, the key words "MAY", "MUST, "MUST NOT", 64 "optional", "recommended", "SHOULD", and "SHOULD NOT" are to be 65 interpreted as described in [12]. 67 The words "silently discard", when used in reference to the 68 behavior of an implementation upon receipt of an incoming packet, 69 are to be interpreted as follows: the implementation discards the 70 datagram without further processing, and without indicating an 71 error to the sender. The implementation SHOULD provide the 72 capability of logging the error, including the contents of the 73 discarded datagram, and SHOULD record the event in a statistics 74 counter. 76 Table of Contents 78 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 6 80 1.1. Protocol Goals and Assumptions . . . . . . . . . . . . . . . . 7 82 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7 84 1.3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 9 86 1.3.1. Control Connection Overview . . . . . . . . . . . . . . . . 9 88 1.3.2. Tunnel Protocol Overview . . . . . . . . . . . . . . . . . . 10 90 1.4. Message Format and Protocol Extensibility . . . . . . . . . . 10 92 2. Control Connection Protocol Specification . . . . . . . . . . . 12 94 2.1. Start-Control-Connection-Request . . . . . . . . . . . . . . . 12 96 2.2. Start-Control-Connection-Reply . . . . . . . . . . . . . . . . 14 98 2.3. Stop-Control-Connection-Request . . . . . . . . . . . . . . . 17 100 2.4. Stop-Control-Connection-Reply . . . . . . . . . . . . . . . . 18 102 2.5. Echo-Request . . . . . . . . . . . . . . . . . . . . . . . . . 19 104 2.6. Echo-Reply . . . . . . . . . . . . . . . . . . . . . . . . . . 20 106 2.7. Outgoing-Call-Request . . . . . . . . . . . . . . . . . . . . 21 108 2.8. Outgoing-Call-Reply . . . . . . . . . . . . . . . . . . . . . 23 110 2.9. Incoming-Call-Request . . . . . . . . . . . . . . . . . . . . 26 112 2.10. Incoming-Call-Reply . . . . . . . . . . . . . . . . . . . . . 28 114 2.11. Incoming-Call-Connected . . . . . . . . . . . . . . . . . . . 30 116 2.12. Call-Clear-Request . . . . . . . . . . . . . . . . . . . . . 32 118 2.13. Call-Disconnect-Notify . . . . . . . . . . . . . . . . . . . 32 120 2.14. WAN-Error-Notify . . . . . . . . . . . . . . . . . . . . . . 34 121 2.15. Set-Link-Info . . . . . . . . . . . . . . . . . . . . . . . . 36 123 2.16. General Error Codes . . . . . . . . . . . . . . . . . . . . . 37 125 3. Control Connection Protocol Operation . . . . . . . . . . . . . 37 127 3.1. Control Connection States . . . . . . . . . . . . . . . . . . 38 129 3.1.1. Control Connection Originator (may be PAC or PNS) . . . . . 38 131 3.1.2. Control connection Receiver (may be PAC or PNS) . . . . . . 39 133 3.1.3. Start Control Connection Initiation Request Collision . . . 40 135 3.1.4. Keep Alives and Timers . . . . . . . . . . . . . . . . . . . 41 137 3.2. Call States . . . . . . . . . . . . . . . . . . . . . . . . . 41 139 3.2.1. Timing considerations . . . . . . . . . . . . . . . . . . . 41 141 3.2.2. Call ID Values . . . . . . . . . . . . . . . . . . . . . . . 42 143 3.2.3. Incoming Calls . . . . . . . . . . . . . . . . . . . . . . . 42 145 3.2.3.1. PAC Incoming Call States . . . . . . . . . . . . . . . . . 43 147 3.2.3.2. PNS Incoming Call States . . . . . . . . . . . . . . . . . 44 149 3.2.4. Outgoing Calls . . . . . . . . . . . . . . . . . . . . . . . 45 151 3.2.4.1. PAC Outgoing Call States . . . . . . . . . . . . . . . . . 45 153 3.2.4.2. PNS Outgoing Call States . . . . . . . . . . . . . . . . . 46 155 4. Tunnel Protocol Operation . . . . . . . . . . . . . . . . . . . 47 157 4.1. Enhanced GRE header . . . . . . . . . . . . . . . . . . . . . 48 159 4.2. Sliding Window Protocol . . . . . . . . . . . . . . . . . . . 50 161 4.2.1. Initial Window Size . . . . . . . . . . . . . . . . . . . . 50 163 4.2.2. Closing the Window . . . . . . . . . . . . . . . . . . . . . 50 165 4.2.3. Opening the Window . . . . . . . . . . . . . . . . . . . . . 50 167 4.2.4. Window Overflow . . . . . . . . . . . . . . . . . . . . . . 51 168 4.2.5. Multi-packet Acknowledgment . . . . . . . . . . . . . . . . 51 170 4.3. Out-of-sequence Packets . . . . . . . . . . . . . . . . . . . 51 172 4.4. Acknowledgment Time-Outs . . . . . . . . . . . . . . . . . . . 52 174 4.4.1. Calculating Adaptive Acknowledgment Time-Out . . . . . . . . 53 176 4.4.2. Congestion Control: Adjusting for Time-Out . . . . . . . . . 54 178 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 55 180 6. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 55 182 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 184 8. Expiration Date . . . . . . . . . . . . . . . . . . . . . . . . 57 185 1. Introduction 187 PPTP allows existing Network Access Server (NAS) functions to be 188 separated using a client-server architecture. Traditionally, the 189 following functions are implemented by a NAS: 191 1) Physical native interfacing to PSTN or ISDN and control of 192 external modems or terminal adapters. 194 A NAS may interface directly to a telco analog or digital circuit 195 or attach via an external modem or terminal adapter. Control of a 196 circuit-switched connection is accomplished with either modem 197 control or DSS1 ISDN call control protocols. 199 The NAS, in conjunction with the modem or terminal adapters, may 200 perform rate adaption, analog to digital conversion, sync to async 201 conversion or a number of other alterations of data streams. 203 2) Logical termination of a Point-to-Point-Protocol (PPP) Link 204 Control Protocol (LCP) session. 206 3) Participation in PPP authentication protocols [3,9,10]. 208 4) Channel aggregation and bundle management for PPP Multilink 209 Protocol. 211 5) Logical termination of various PPP network control protocols 212 (NCP). 214 6) Multiprotocol routing and bridging between NAS interfaces. 216 PPTP divides these functions between the PAC and PNS. The PAC is 217 responsible for functions 1, 2, and possibly 3. The PNS may be 218 responsible for function 3 and is responsible for functions 4, 5, and 6. 219 The protocol used to carry PPP protocol data units (PDUs) between the 220 PAC and PNS, as well as call control and management is addressed by 221 PPTP. 223 The decoupling of NAS functions offers these benefits: 225 Flexible IP address management. Dial-in users may maintain a single 226 IP address as they dial into different PACs as long as they are 227 served from a common PNS. If an enterprise network uses unregistered 228 addresses, a PNS associated with the enterprise assigns addresses 229 meaningful to the private network. 231 Support of non-IP protocols for dial networks behind IP networks. 232 This allows Appletalk and IPX, for example to be tunneled through an 233 IP-only provider. The PAC need not be capable of processing these 234 protocols. 236 A solution to the "multilink hunt-group splitting" problem. 237 Multilink PPP, typically used to aggregate ISDN B channels, requires 238 that all of the channels composing a multilink bundle be grouped at a 239 single NAS. Since a multilink PPP bundle can be handled by a single 240 PNS, the channels comprising the bundle may be spread across multiple 241 PACs. 243 1.1. Protocol Goals and Assumptions 245 The PPTP protocol is implemented only by the PAC and PNS. No other 246 systems need to be aware of PPTP. Dial networks may be connected to a 247 PAC without being aware of PPTP. Standard PPP client software should 248 continue to operate on tunneled PPP links. 250 PPTP can also be used to tunnel a PPP session over an IP network. In 251 this configuration the PPTP tunnel and the PPP session runs between the 252 same two machines with the caller acting as a PNS. 254 It is envisioned that there will be a many-to-many relationship between 255 PACs and PNSs. A PAC may provide service to many PNSs. For example, an 256 Internet service provider may choose to support PPTP for a number of 257 private network clients and create VPNs for them. Each private network 258 may operate one or more PNSs. A single PNS may associate with many PACs 259 to concentrate traffic from a large number of geographically diverse 260 sites. 262 PPTP uses an extended version of GRE to carry user PPP packets. These 263 enhancements allow for low-level congestion and flow control to be 264 provided on the tunnels used to carry user data between PAC and PNS. 265 This mechanism allows for efficient use of the bandwidth available for 266 the tunnels and avoids unnecessary retransmisions and buffer overruns. 267 PPTP does not dictate the particular algorithms to be used for this low 268 level control but it does define the parameters that must be 269 communicated in order to allow such algorithms to work. Suggested 270 algorithms are included in section 4. 272 1.2. Terminology 274 Analog Channel 276 A circuit-switched communication path which is intended to carry 277 3.1 Khz audio in each direction. 279 Digital Channel 281 A circuit-switched communication path which is intended to carry 282 digital information in each direction. 284 Call 286 A connection or attempted connection between two terminal 287 endpoints on a PSTN or ISDN -- for example, a telephone call 288 between two modems. 290 Control Connection 292 A control connection is created for each PAC, PNS pair and 293 operates over TCP [4]. The control connection governs aspects of 294 the tunnel and of sessions assigned to the tunnel. 296 Dial User 298 An end-system or router attached to an on-demand PSTN or ISDN 299 which is either the initiator or recipient of a call. 301 Network Access Server (NAS) 303 A device providing temporary, on-demand network access to users. 304 This access is point-to-point using PSTN or ISDN lines. 306 PPTP Access Concentrator (PAC) 308 A device attached to one or more PSTN or ISDN lines capable of PPP 309 operation and of handling the PPTP protocol. The PAC need only 310 implement TCP/IP to pass traffic to one or more PNSs. It may also 311 tunnel non-IP protocols. 313 PPTP Network Server (PNS) 315 A PNS is envisioned to operate on general-purpose computing/server 316 platforms. The PNS handles the server side of the PPTP protocol. 317 Since PPTP relies completely on TCP/IP and is independent of the 318 interface hardware, the PNS may use any combination of IP 319 interface hardware including LAN and WAN devices. 321 Session 323 PPTP is connection-oriented. The PNS and PAC maintain state for 324 each user that is attached to a PAC. A session is created when 325 end-to-end PPP connection is attempted between a dial user and the 326 PNS. The datagrams related to a session are sent over the tunnel 327 between the PAC and PNS. 329 Tunnel 331 A tunnel is defined by a PNS-PAC pair. The tunnel protocol is 332 defined by a modified version of GRE [1,2]. The tunnel carries 333 PPP datagrams between the PAC and the PNS. Many sessions are 334 multiplexed on a single tunnel. A control connection operating 335 over TCP controls the establishment, release, and maintenance of 336 sessions and of the tunnel itself. 338 1.3. Protocol Overview 340 There are two parallel components of PPTP: 1) a Control Connection 341 between each PAC-PNS pair operating over TCP and 2) an IP tunnel 342 operating between the same PAC-PNS pair which is used to transport GRE 343 encapsulated PPP packets for user sessions between the pair. 345 1.3.1. Control Connection Overview 347 Before PPP tunneling can occur between a PAC and PNS, a control 348 connection must be established between them. The control connection is a 349 standard TCP session over which PPTP call control and management 350 information is passed. The control session is logically associated with, 351 but separate from, the sessions being tunneled through a PPTP tunnel. 352 For each PAC-PNS pair both a tunnel and a control connection exist. The 353 control connection is responsible for establishment, management, and 354 release of sessions carried through the tunnel. It is the means by which 355 a PNS is notified of an incoming call at an associated PAC, as well as 356 the means by which a PAC is instructed to place an outgoing dial call. 358 A control connection can be established by either the PNS or the PAC. 359 Following the establishment of the required TCP connection, the PNS and 360 PAC establish the control connection using the Start-Control- 361 Connection-Request and -Reply messages. These messages are also used to 362 exchange information about basic operating capabilities of the PAC and 363 PNS. Once the control connection is established, the PAC or PNS may 364 initiate sessions by requesting outbound calls or responding to inbound 365 requests. The control connection may communicate changes in operating 366 characteristics of an individual user session with a Set- Link-Info 367 message. Individual sessions may be released by either the PAC or PNS, 368 also through Control Connection messages. 370 The control connection itself is maintained by keep-alive echo messages. 371 This ensures that a connectivity failure between the PNS and the PAC can 372 be detected in a timely manner. Other failures can be reported via the 373 Wan-Error-Notify message, also on the control connection. 375 It is intended that the control connection will also carry management 376 related messages in the future, such as a message allowing the PNS to 377 request the status of a given PAC; these message types have not yet been 378 defined. 380 1.3.2. Tunnel Protocol Overview 382 PPTP requires the establishment of a tunnel for each communicating PNS- 383 PAC pair. This tunnel is used to carry all user session PPP packets for 384 sessions involving a given PNS-PAC pair. A key which is present in the 385 GRE header indicates which session a particular PPP packet belongs to. 386 In this manner, PPP packets are multiplexed and demultiplexed over a 387 single tunnel between a given PNS-PAC pair. The value to use in the key 388 field is established by the call establishment procedure which takes 389 place on the control connection. 391 The GRE header also contains acknowledgment and sequencing information 392 that is used to perform some level of congestion-control and error 393 detection over the tunnel. Again the control connection is used to 394 determine rate and buffering parameters that are used to regulate the 395 flow of PPP packets for a particular session over the tunnel. PPTP does 396 not specify the particular algorithms to use for congestion-control and 397 flow-control. Suggested algorithms for the determination of adaptive 398 time-outs to recover from dropped data or acknowledgments on the tunnel 399 are included in section 4.4 of this document. 401 1.4. Message Format and Protocol Extensibility 403 PPTP defines a set of messages sent as TCP data on the control 404 connection between a PNS and a given PAC. The TCP session for the 405 control connection is established by initiating a TCP connection to port 406 1723 [6]. The source port is assigned to any unused port number. 408 Each PPTP Control Connection message begins with an 8 octet fixed header 409 portion. This fixed header contains the following: the total length of 410 the message, the PPTP Message Type indicator, and a "Magic Cookie". 412 Two Control Connection message types are indicated by the PPTP Message 413 Type field: 415 1 - Control Message 416 2 - Management Message 418 Management messages are currently not defined. 420 The Magic Cookie is always sent as the constant 0x1A2B3C4D. Its basic 421 purpose is to allow the receiver to ensure that it is properly 422 synchronized with the TCP data stream. It should not be used as a means 423 for resynchronizing the TCP data stream in the event that a transmitter 424 issues an improperly formatted message. Loss of synchronization must 425 result in immediate closing of the control connection's TCP session. 427 For clarity, all Control Connection message templates in the next 428 section include the entire PPTP Control Connection message header. 429 Numbers preceded by 0x are hexadecimal values. 431 The currently defined Control Messages, grouped by function, are: 433 Control Message Message Code 435 (Control Connection Management) 437 Start-Control-Connection-Request 1 438 Start-Control-Connection-Reply 2 439 Stop-Control-Connection-Request 3 440 Stop-Control-Connection-Reply 4 441 Echo-Request 5 442 Echo-Reply 6 444 (Call Management) 446 Outgoing-Call-Request 7 447 Outgoing-Call-Reply 8 448 Incoming-Call-Request 9 449 Incoming-Call-Reply 10 450 Incoming-Call-Connected 11 451 Call-Clear-Request 12 452 Call-Disconnect-Notify 13 454 (Error Reporting) 456 WAN-Error-Notify 14 458 (PPP Session Control) 460 Set-Link-Info 15 462 The Start-Control-Connection-Request and -Reply messages determine which 463 version of the Control Connection protocol will be used. The version 464 number field carried in these messages consists of a version number in 465 the high octet and a revision number in the low octet. Version handling 466 is described in section 2. The current value of the version number field 467 is 0x0100 for version 1, revision 0. 469 The use of the GRE-like header for the encapsulation of PPP user packets 470 is specified in section 4.1. 472 The MTU for the user data packets encapsulated in GRE is 1532 octets, 473 not including the IP and GRE headers. 475 2. Control Connection Protocol Specification 477 Control Connection messages are used to establish and clear user 478 sessions. The first set of Control Connection messages are used to 479 maintain the control connection itself. The control connection is 480 initiated by either the PNS or PAC after they establish the underlying 481 TCP connection. The procedure and configuration information required to 482 determine which TCP connections are established is not covered by this 483 protocol. 485 The following Control Connection messages are all sent as user data on 486 the established TCP connection between a given PNS-PAC pair. Note that 487 care has been taken to ensure that all word (2 octet) and longword (4 488 octet) values begin on appropriate boundaries. All data is sent in 489 network order (high order octets first). Any "reserved" fields MUST be 490 sent as 0 values to allow for protocol extensibility. 492 2.1. Start-Control-Connection-Request 494 The Start-Control-Connection-Request is a PPTP control message used to 495 establish the control connection between a PNS and a PAC. Each PNS-PAC 496 pair requires a dedicated control connection to be established. A 497 control connection must be established before any other PPTP messages 498 can be issued. The establishment of the control connection can be 499 initiated by either the PNS or PAC. A procedure which handles the 500 occurrence of a collision between PNS and PAC Start-Control-Connection- 501 Requests is described in section 3.1.3. 503 0 1 2 3 504 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 505 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 506 | Length | PPTP Message Type | 507 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 508 | Magic Cookie | 509 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 510 | Control Message Type | Reserved0 | 511 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 512 | Protocol Version | Reserved1 | 513 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 514 | Framing Capabilities | 515 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 516 | Bearer Capabilities | 517 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 518 | Maximum Channels | Firmware Revision | 519 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 520 | | 521 + Host Name (64 octets) + 522 | | 523 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 524 | | 525 + Vendor String (64 octets) + 526 | | 527 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 529 Length Total length in octets of this PPTP 530 message, including the entire PPTP 531 header. 533 PPTP Message Type 1 for Control Message. 535 Magic Cookie 0x1A2B3C4D. This constant value is used 536 as a sanity check on received messages 537 (see section 1.4). 539 Control Message Type 1 for Start-Control-Connection-Request. 541 Reserved0 This field MUST be 0. 543 Protocol Version The version of the PPTP protocol that the 544 sender wishes to use. 546 Reserved1 This field MUST be 0. 548 Framing Capabilities A set of bits indicating the type of 549 framing that the sender of this message 550 can provide. The currently defined bit 551 settings are: 553 1 - Asynchronous Framing supported 555 2 - Synchronous Framing supported 557 Bearer Capabilities A set of bits indicating the bearer 558 capabilities that the sender of this 559 message can provide. The currently 560 defined bit settings are: 562 1 - Analog access supported 564 2 - Digital access supported 566 Maximum Channels The total number of individual PPP 567 sessions this PAC can support. In 568 Start-Control-Connection-Requests issued 569 by the PNS, this value SHOULD be set to 570 0. It MUST be ignored by the PAC. 572 Firmware Revision This field contains the firmware revision 573 number of the issuing PAC, when issued by 574 the PAC, or the version of the PNS PPTP 575 driver if issued by the PNS. 577 Host Name A 64 octet field containing the DNS name 578 of the issuing PAC or PNS. If less than 579 64 octets in length, the remainder of 580 this field SHOULD be filled with octets 581 of value 0. 583 Vendor Name A 64 octet field containing a vendor 584 specific string describing the type of 585 PAC being used, or the type of PNS 586 software being used if this request is 587 issued by the PNS. If less than 64 588 octets in length, the remainder of this 589 field SHOULD be filled with octets of 590 value 0. 592 2.2. Start-Control-Connection-Reply 594 The Start-Control-Connection-Reply is a PPTP control message sent in 595 reply to a received Start-Control-Connection-Request message. This 596 message contains a result code indicating the result of the control 597 connection establishment attempt. 599 0 1 2 3 600 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 601 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 602 | Length | PPTP Message Type | 603 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 604 | Magic Cookie | 605 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 606 | Control Message Type | Reserved0 | 607 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 608 | Protocol Version | Result Code | Error Code | 609 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 610 | Framing Capability | 611 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 612 | Bearer Capability | 613 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 614 | Maximum Channels | Firmware Revision | 615 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 616 | | 617 + Host Name (64 octets) + 618 | | 619 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 620 | | 621 + Vendor String (64 octets) + 622 | | 623 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 625 Length Total length in octets of this PPTP 626 message, including the entire PPTP 627 header. 629 PPTP Message Type 1 for Control Message. 631 Magic Cookie 0x1A2B3C4D. 633 Control Message Type 2 for Start-Control-Connection-Reply. 635 Reserved0 This field MUST be 0. 637 Protocol Version The version of the PPTP protocol that the 638 sender wishes to use. 640 Result Code Indicates the result of the command 641 channel establishment attempt. Current 642 valid Result Code values are: 644 1 - Successful channel establishment 646 2 - General error -- Error Code 647 indicates the problem 649 3 - Command channel already exists; 651 4 - Requester is not authorized to 652 establish a command channel 654 5 - The protocol version of the 655 requester is not supported 657 Error Code This field is set to 0 unless a "General 658 Error" exists, in which case Result Code 659 is set to 2 and this field is set to the 660 value corresponding to the general error 661 condition as specified in section 2.2. 663 Framing Capabilities A set of bits indicating the type of 664 framing that the sender of this message 665 can provide. The currently defined bit 666 settings are: 668 1 - Asynchronous Framing supported 670 2 - Synchronous Framing supported. 672 Bearer Capabilities A set of bits indicating the bearer 673 capabilities that the sender of this 674 message can provide. The currently 675 defined bit settings are: 677 1 - Analog access supported 679 2 - Digital access supported 681 Maximum Channels The total number of individual PPP 682 sessions this PAC can support. In a 683 Start-Control-Connection-Reply issued by 684 the PNS, this value SHOULD be set to 0 685 and it must be ignored by the PAC. The 686 PNS MUST NOT use this value to try to 687 track the remaining number of PPP 688 sessions that the PAC will allow. 690 Firmware Revision This field contains the firmware revision 691 number of the issuing PAC, or the version 692 of the PNS PPTP driver if issued by the 693 PNS. 695 Host Name A 64 octet field containing the DNS name 696 of the issuing PAC or PNS. If less than 697 64 octets in length, the remainder of 698 this field SHOULD be filled with octets 699 of value 0. 701 Vendor Name A 64 octet field containing a vendor 702 specific string describing the type of 703 PAC being used, or the type of PNS 704 software being used if this request is 705 issued by the PNS. If less than 64 706 octets in length, the remainder of this 707 field SHOULD be filled with octets of 708 value 0. 710 2.3. Stop-Control-Connection-Request 712 The Stop-Control-Connection-Request is a PPTP control message sent by 713 one peer of a PAC-PNS control connection to inform the other peer that 714 the control connection should be closed. In addition to closing the 715 control connection, all active user calls are implicitly cleared. The 716 reason for issuing this request is indicated in the Reason field. 718 0 1 2 3 719 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 720 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 721 | Length | PPTP Message Type | 722 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 723 | Magic Cookie | 724 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 725 | Control Message Type | Reserved0 | 726 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 727 | Reason | Reserved1 | Reserved2 | 728 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 730 Length Total length in octets of this PPTP 731 message, including the entire PPTP 732 header. 734 PPTP Message Type 1 for Control Message. 736 Magic Cookie 0x1A2B3C4D. 738 Control Message Type 3 for Stop-Control-Connection-Request. 740 Reserved0 This field MUST be 0. 742 Reason Indicates the reason for the control 743 connection being closed. Current valid 744 Reason values are: 746 1 (None) - General request to clear 747 control connection 749 2 (Stop-Protocol) - Can't support 750 peer's version of the protocol 752 3 (Stop-Local-Shutdown) - Requester is 753 being shut down 755 Reserved1, Reserved2 These fields MUST be 0. 757 2.4. Stop-Control-Connection-Reply 759 The Stop-Control-Connection-Reply is a PPTP control message sent by one 760 peer of a PAC-PNS control connection upon receipt of a Stop- Control- 761 Connection-Request from the other peer. 763 0 1 2 3 764 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 765 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 766 | Length | PPTP Message Type | 767 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 768 | Magic Cookie | 769 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 770 | Control Message Type | Reserved0 | 771 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 772 | Result Code | Error Code | Reserved1 | 773 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 775 Length Total length in octets of this PPTP 776 message, including the entire PPTP 777 header. 779 PPTP Message Type 1 for Control Message. 781 Magic Cookie 0x1A2B3C4D. 783 Control Message Type 4 for Stop-Control-Connection-Reply. 785 Reserved0 This field MUST be 0. 787 Result Code Indicates the result of the attempt to 788 close the control connection. Current 789 valid Result Code values are: 791 1 (OK) - Control connection closed 793 2 (General Error) - Control connection 794 not closed for reason indicated in 795 Error Code 797 Error Code This field is set to 0 unless a "General 798 Error" exists, in which case Result Code 799 is set to 2 and this field is set to the 800 value corresponding to the general error 801 condition as specified in section 2.2. 803 Reserved1 This field MUST be 0. 805 2.5. Echo-Request 807 The Echo-Request is a PPTP control message sent by either peer of a PAC- 808 PNS control connection. This control message is used as a "keep-alive" 809 for the control connection. The receiving peer issues an Echo-Reply to 810 each Echo-Request received. As specified in section 3.1.4, if the sender 811 does not receive an Echo-Reply in response to an Echo-Request, it will 812 eventually clear the control connection. 814 0 1 2 3 815 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 816 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 817 | Length | PPTP Message Type | 818 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 819 | Magic Cookie | 820 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 821 | Control Message Type | Reserved0 | 822 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 823 | Identifier | 824 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 826 Length Total length in octets of this PPTP 827 message, including the entire PPTP 828 header. 830 PPTP Message Type 1 for Control Message. 832 Magic Cookie 0x1A2B3C4D. 834 Control Message Type 5 for Echo-Request. 836 Reserved0 This field MUST be 0. 838 Identifier A value set by the sender of the Echo- 839 Request that is used to match the reply 840 with the corresponding request. 842 2.6. Echo-Reply 844 The Echo-Reply is a PPTP control message sent by either peer of a PAC- 845 PNS control connection in response to the receipt of an Echo- Request. 847 0 1 2 3 848 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 849 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 850 | Length | PPTP Message Type | 851 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 852 | Magic Cookie | 853 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 854 | Control Message Type | Reserved0 | 855 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 856 | Identifier | 857 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 858 | Result Code | Error Code | Reserved1 | 859 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 861 Length Total length in octets of this PPTP 862 message, including the entire PPTP 863 header. 865 PPTP Message Type 1 for Control Message. 867 Magic Cookie 0x1A2B3C4D. 869 Control Message Type 6 for Echo-Reply. 871 Reserved0 This field MUST be 0. 873 Identifier The contents of the identify field from 874 the received Echo-Request is copied to 875 this field. 877 Result Code Indicates the result of the receipt of 878 the Echo-Request. Current valid Result 879 Code values are: 881 1 (OK) - The Echo-Reply is valid 883 2 (General Error) - Echo-Request not 884 accepted for the reason indicated in 885 Error Code 887 Error Code This field is set to 0 unless a "General 888 Error" condition exists, in which case 889 Result Code is set to 2 and this field is 890 set to the value corresponding to the 891 general error condition as specified in 892 section 2.2. 894 Reserved1 This field MUST be 0. 896 2.7. Outgoing-Call-Request 898 The Outgoing-Call-Request is a PPTP control message sent by the PNS to 899 the PAC to indicate that an outbound call from the PAC is to be 900 established. This request provides the PAC with information required to 901 make the call. It also provides information to the PAC that is used to 902 regulate the transmission of data to the PNS for this session once it is 903 established. 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 | Call ID | Call Serial Number | 915 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 916 | Minimum BPS | 917 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 918 | Maximum BPS | 919 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 920 | Bearer Type | 921 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 922 | Framing Type | 923 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 924 | Packet Recv. Window Size | Packet Processing Delay | 925 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 926 | Phone Number Length | Reserved1 | 927 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 928 | | 929 + Phone Number (64 octets) + 930 | | 931 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 932 | | 933 + Subaddress (64 octets) + 934 | | 935 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 936 Length Total length in octets of this PPTP 937 message, including the entire PPTP 938 header. 940 PPTP Message Type 1 for Control Message. 942 Magic Cookie 0x1A2B3C4D. 944 Control Message Type 7 for Outgoing-Call-Request. 946 Reserved0 This field MUST be 0. 948 Call ID A unique identifier, unique to a 949 particular PAC-PNS pair assigned by the 950 PNS to this session. It is used to 951 multiplex and demultiplex data sent over 952 the tunnel between the PNS and PAC 953 involved in this session. 955 Call Serial Number An identifier assigned by the PNS to this 956 session for the purpose of identifying 957 this particular session in logged session 958 information. Unlike the Call ID, both 959 the PNS and PAC associate the same Call 960 Serial Number with a given session. The 961 combination of IP address and call serial 962 number SHOULD be unique. 964 Minimum BPS The lowest acceptable line speed (in 965 bits/second) for this session. 967 Maximum BPS The highest acceptable line speed (in 968 bits/second) for this session. 970 Bearer Type A value indicating the bearer capability 971 required for this outgoing call. The 972 currently defined values are: 974 1 - Call to be placed on an analog 975 channel 977 2 - Call to be placed on a digital 978 channel 980 3 - Call can be placed on any type of 981 channel 983 Framing Type A value indicating the type of PPP 984 framing to be used for this outgoing 985 call. 987 1 - Call to use Asynchronous framing 989 2 - Call to use Synchronous framing 991 3 - Call can use either type of 992 framing 994 Packet Recv. Window Size The number of received data packets the 995 PNS will buffer for this session. 997 Packet Processing Delay A measure of the packet processing delay 998 that might be imposed on data sent to the 999 PNS from the PAC. This value is 1000 specified in units of 1/10 seconds. For 1001 the PNS this number should be very small. 1002 See section 4.4 for a description of how 1003 this value is determined and used. 1005 Phone Number Length The actual number of valid digits in the 1006 Phone Number field. 1008 Reserved1 This field MUST be 0. 1010 Phone Number The number to be dialed to establish the 1011 outgoing session. For ISDN and analog 1012 calls this field is an ASCII string. If 1013 the Phone Number is less than 64 octets 1014 in length, the remainder of this field is 1015 filled with octets of value 0. 1017 Subaddress A 64 octet field used to specify 1018 additional dialing information. If the 1019 subaddress is less than 64 octets long, 1020 the remainder of this field is filled 1021 with octets of value 0. 1023 2.8. Outgoing-Call-Reply 1025 The Outgoing-Call-Reply is a PPTP control message sent by the PAC to the 1026 PNS in response to a received Outgoing-Call-Request message. The reply 1027 indicates the result of the outgoing call attempt. It also provides 1028 information to the PNS about particular parameters used for the call. 1029 It provides information to allow the PNS to regulate the transmission of 1030 data to the PAC for this session. 1032 0 1 2 3 1033 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 1034 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1035 | Length | PPTP Message Type | 1036 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1037 | Magic Cookie | 1038 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1039 | Control Message Type | Reserved0 | 1040 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1041 | Call ID | Peer's Call ID | 1042 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1043 | Result Code | Error Code | Cause Code | 1044 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1045 | Connect Speed | 1046 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1047 | Packet Recv. Window Size | Packet Processing Delay | 1048 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1049 | Physical Channel ID | 1050 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1052 Length Total length in octets of this PPTP 1053 message, including the entire PPTP 1054 header. 1056 PPTP Message Type 1 for Control Message. 1058 Magic Cookie 0x1A2B3C4D. 1060 Control Message Type 8 for Outgoing-Call-Reply. 1062 Reserved0 This field MUST be 0. 1064 Call ID A unique identifier for the tunnel, 1065 assigned by the PAC to this session. It 1066 is used to multiplex and demultiplex data 1067 sent over the tunnel between the PNS and 1068 PAC involved in this session. 1070 Peer's Call ID This field is set to the value received 1071 in the Call ID field of the corresponding 1072 Outgoing-Call-Request message. It is 1073 used by the PNS to match the Outgoing- 1074 Call-Reply with the Outgoing-Call-Request 1075 it issued. It also is used as the value 1076 sent in the GRE header for mux/demuxing. 1078 Result Code This value indicates the result of the 1079 Outgoing-Call-Request attempt. Currently 1080 valid values are: 1082 1 (Connected) - Call established with 1083 no errors 1085 2 (General Error) - Outgoing Call not 1086 established for the reason indicated 1087 in Error Code 1089 3 (No Carrier) - Outgoing Call failed 1090 due to no carrier detected 1092 4 (Busy) - Outgoing Call failed due to 1093 detection of a busy signal 1095 5 (No Dial Tone) - Outgoing Call 1096 failed due to lack of a dial tone 1098 6 (Time-out) - Outgoing Call was not 1099 established within time allotted by 1100 PAC 1102 7 (Do Not Accept) - Outgoing Call 1103 administratively prohibited 1105 Error Code This field is set to 0 unless a "General 1106 Error" condition exists, in which case 1107 Result Code is set to 2 and this field is 1108 set to the value corresponding to the 1109 general error condition as specified in 1110 section 2.2. 1112 Cause Code This field gives additional failure 1113 information. Its value can vary 1114 depending upon the type of call 1115 attempted. For ISDN call attempts it is 1116 the Q.931 cause code. 1118 Connect Speed The actual connection speed used, in 1119 bits/second. 1121 Packet Recv. Window Size The number of received data packets the 1122 PAC will buffer for this session. 1124 Packet Processing Delay A measure of the packet processing delay 1125 that might be imposed on data sent to the 1126 PAC from the PNS. This value is 1127 specified in units of 1/10 seconds. For 1128 the PAC, this number is related to the 1129 size of the buffer used to hold packets 1130 to be sent to the client and to the speed 1131 of the link to the client. This value 1132 should be set to the maximum delay that 1133 can normally occur between the time a 1134 packet arrives at the PAC and is 1135 delivered to the client. See section 4.4 1136 for an example of how this value is 1137 determined and used. 1139 Physical Channel ID This field is set by the PAC in a 1140 vendor-specific manner to the physical 1141 channel number used to place this call. 1142 It is used for logging purposes only. 1144 2.9. Incoming-Call-Request 1146 The Incoming-Call-Request is a PPTP control message sent by the PAC to 1147 the PNS to indicate that an inbound call is to be established from the 1148 PAC. This request provides the PNS with parameter information for the 1149 incoming call. 1151 This message is the first in the "three-way handshake" used by PPTP for 1152 establishing incoming calls. The PAC may defer answering the call until 1153 it has received an Incoming-Call-Reply from the PNS indicating that the 1154 call should be established. This mechanism allows the PNS to obtain 1155 sufficient information about the call before it is answered to determine 1156 whether the call should be answered or not. 1158 0 1 2 3 1159 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 1160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1161 | Length | PPTP Message Type | 1162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1163 | Magic Cookie | 1164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1165 | Control Message Type | Reserved0 | 1166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1167 | Call ID | Call Serial Number | 1168 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1169 | Call Bearer Type | 1170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1171 | Physical Channel ID | 1172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1173 | Dialed Number Length | Dialing Number Length | 1174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1175 | | 1176 + Dialed Number (64 octets) + 1177 | | 1178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1179 | | 1180 + Dialing Number (64 octets) + 1181 | 1182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1183 | | 1184 + Subaddress (64 octets) + 1185 | | 1186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1188 Length Total length in octets of this PPTP 1189 message, including the entire PPTP 1190 header. 1192 PPTP Message Type 1 for Control Message. 1194 Magic Cookie 0x1A2B3C4D. 1196 Control Message Type 9 for Incoming-Call-Request. 1198 Reserved0 This field MUST be 0. 1200 Call ID A unique identifier for this tunnel, 1201 assigned by the PAC to this session. It 1202 is used to multiplex and demultiplex data 1203 sent over the tunnel between the PNS and 1204 PAC involved in this session. 1206 Call Serial Number An identifier assigned by the PAC to this 1207 session for the purpose of identifying 1208 this particular session in logged session 1209 information. Unlike the Call ID, both 1210 the PNS and PAC associate the same Call 1211 Serial Number to a given session. The 1212 combination of IP address and call serial 1213 number should be unique. 1215 Bearer Type A value indicating the bearer capability 1216 used for this incoming call. Currently 1217 defined values are: 1219 1 - Call is on an analog channel 1220 2 - Call is on a digital channel 1222 Physical Channel ID This field is set by the PAC in a 1223 vendor-specific manner to the number of 1224 the physical channel this call arrived 1225 on. 1227 Dialed Number Length The actual number of valid digits in the 1228 Dialed Number field. 1230 Dialing Number Length The actual number of valid digits in the 1231 Dialing Number field. 1233 Dialed Number The number that was dialed by the caller. 1234 For ISDN and analog calls this field is 1235 an ASCII string. If the Dialed Number is 1236 less than 64 octets in length, the 1237 remainder of this field is filled with 1238 octets of value 0. 1240 Dialing Number The number from which the call was 1241 placed. For ISDN and analog calls this 1242 field is an ASCII string. If the Dialing 1243 Number is less than 64 octets in length, 1244 the remainder of this field is filled 1245 with octets of value 0. 1247 Subaddress A 64 octet field used to specify 1248 additional dialing information. If the 1249 subaddress is less than 64 octets long, 1250 the remainder of this field is filled 1251 with octets of value 0. 1253 2.10. Incoming-Call-Reply 1255 The Incoming-Call-Reply is a PPTP control message sent by the PNS to the 1256 PAC in response to a received Incoming-Call-Request message. The reply 1257 indicates the result of the incoming call attempt. It also provides 1258 information to allow the PAC to regulate the transmission of data to the 1259 PNS for this session. 1261 This message is the second in the three-way handshake used by PPTP for 1262 establishing incoming calls. It indicates to the PAC whether the call 1263 should be answered or not. 1265 0 1 2 3 1266 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 1268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1269 | Length | PPTP Message Type | 1270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1271 | Magic Cookie | 1272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1273 | Control Message Type | Reserved0 | 1274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1275 | Call ID | Peer's Call ID | 1276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1277 | Result Code | Error Code | Packet Recv. Window Size | 1278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1279 | Packet Transmit Delay | Reserved1 | 1280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1282 Length Total length in octets of this PPTP 1283 message, including the entire PPTP 1284 header. 1286 PPTP Message Type 1 for Control Message. 1288 Magic Cookie 0x1A2B3C4D. 1290 Control Message Type 10 for Incoming-Call-Reply. 1292 Reserved0 This field MUST be 0. 1294 Call ID A unique identifier for this tunnel 1295 assigned by the PNS to this session. It 1296 is used to multiplex and demultiplex data 1297 sent over the tunnel between the PNS and 1298 PAC involved in this session. 1300 Peer's Call ID This field is set to the value received 1301 in the Call ID field of the corresponding 1302 Incoming-Call-Request message. It is used 1303 by the PAC to match the Incoming-Call- 1304 Reply with the Incoming-Call-Request it 1305 issued. This value is included in the GRE 1306 header of transmitted data packets for 1307 this session. 1309 Result Code This value indicates the result of the 1310 Incoming-Call-Request attempt. Current 1311 valid Result Code values are: 1313 1 (Connect) - The PAC should answer 1314 the incoming call 1316 2 (General Error) - The Incoming Call 1317 should not be established due to the 1318 reason indicated in Error Code 1320 3 (Do Not Accept) - The PAC should not 1321 accept the incoming call. It should 1322 hang up or issue a busy indication 1324 Error Code This field is set to 0 unless a "General 1325 Error" condition exists, in which case 1326 Result Code is set to 2 and this field is 1327 set to the value corresponding to the 1328 general error condition as specified in 1329 section 2.2. 1331 Packet Recv. Window Size The number of received data packets the 1332 PAC will buffer for this session. 1334 Packet Transmit Delay A measure of the packet processing delay 1335 that might be imposed on data sent to the 1336 PAC from the PNS. This value is 1337 specified in units of 1/10 seconds. 1339 Reserved1 This field MUST be 0. 1341 2.11. Incoming-Call-Connected 1343 The Incoming-Call-Connected message is a PPTP control message sent by 1344 the PAC to the PNS in response to a received Incoming-Call-Reply. It 1345 provides information to the PNS about particular parameters used for the 1346 call. It also provides information to allow the PNS to regulate the 1347 transmission of data to the PAC for this session. 1349 This message is the third in the three-way handshake used by PPTP for 1350 establishing incoming calls. It provides a mechanism for providing the 1351 PNS with additional information about the call that cannot, in general, 1352 be obtained at the time the Incoming-Call-Request is issued by the PAC. 1354 0 1 2 3 1355 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 1356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1357 | Length | PPTP Message Type | 1358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1359 | Magic Cookie | 1360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1361 | Control Message Type | Reserved0 | 1362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1363 | Peer's Call ID | Reserved1 | 1364 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1365 | Connect Speed | 1366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1367 | Packet Recv. Window Size | Packet Transmit Delay | 1368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1369 | Framing Type | 1370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1372 Length Total length in octets of this PPTP 1373 message, including the entire PPTP 1374 header. 1376 PPTP Message Type 1 for Control Message. 1378 Magic Cookie 0x1A2B3C4D. 1380 Control Message Type 11 for Incoming-Call-Connected. 1382 Reserved0 This field MUST be 0. 1384 Peer's Call ID This field is set to the value received 1385 in the Call ID field of the corresponding 1386 Incoming-Call-Reply message. It is used 1387 by the PNS to match the Incoming-Call- 1388 Connected with the Incoming-Call-Reply it 1389 issued. 1391 Connect Speed The actual connection speed used, in 1392 bits/second. 1394 Packet Recv. Window Size The number of received data packets the 1395 PAC will buffer for this session. 1397 Packet Transmit Delay A measure of the packet processing delay 1398 that might be imposed on data sent to the 1399 PAC from the PNS. This value is 1400 specified in units of 1/10 seconds. 1402 Framing Type A value indicating the type of PPP 1403 framing being used by this incoming call. 1405 1 - Call uses asynchronous framing 1407 2 - Call uses synchronous framing 1409 2.12. Call-Clear-Request 1411 The Call-Clear-Request is a PPTP control message sent by the PNS to the 1412 PAC indicating that a particular call is to be disconnected. The call 1413 being cleared can be either an incoming or outgoing call, in any state. 1414 The PAC responds to this message with a Call-Disconnect- Notify message. 1416 0 1 2 3 1417 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 1418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1419 | Length | PPTP Message Type | 1420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1421 | Magic Cookie | 1422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1423 | Control Message Type | Reserved0 | 1424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1425 | Call ID | Reserved1 | 1426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1428 Length Total length in octets of this PPTP 1429 message, including the entire PPTP 1430 header. 1432 PPTP Message Type 1 for Control Message. 1434 Magic Cookie 0x1A2B3C4D. 1436 Control Message Type 12 for Call-Clear-Request. 1438 Reserved0 This field MUST be 0. 1440 Call ID The Call ID assigned by the PNS to this 1441 call. This value is used instead of the 1442 Peer's Call ID because the latter may not 1443 be known to the PNS if the call must be 1444 aborted during call establishment. 1446 Reserved1 This field MUST be 0. 1448 2.13. Call-Disconnect-Notify 1450 The Call-Disconnect-Notify message is a PPTP control message sent by the 1451 PAC to the PNS. It is issued whenever a call is disconnected, due to 1452 the receipt by the PAC of a Call-Clear-Request or for any other reason. 1453 Its purpose is to inform the PNS of both the disconnection and the 1454 reason for it. 1456 0 1 2 3 1457 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 1458 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1459 | Length | PPTP Message Type | 1460 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1461 | Magic Cookie | 1462 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1463 | Control Message Type | Reserved0 | 1464 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1465 | Call ID | Result Code | Error Code | 1466 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1467 | Cause Code | Reserved1 | 1468 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1469 | | 1470 + Call Statistics (128 octets) + 1471 | | 1472 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1474 Length Total length in octets of this PPTP 1475 message, including the entire PPTP 1476 header. 1478 PPTP Message Type 1 for Control Message. 1480 Magic Cookie 0x1A2B3C4D. 1482 Control Message Type 13 for Call-Disconnect-Notify. 1484 Reserved0 This field MUST be 0. 1486 Call ID The value of the Call ID assigned by the 1487 PAC to this call. This value is used 1488 instead of the Peer's Call ID because the 1489 latter may not be known to the PNS if the 1490 call must be aborted during call 1491 establishment. 1493 Result Code This value indicates the reason for the 1494 disconnect. Current valid Result Code 1495 values are: 1497 1 (Lost Carrier) - Call disconnected 1498 due to loss of carrier 1500 2 (General Error) - Call disconnected 1501 for the reason indicated in Error 1502 Code 1504 3 (Admin Shutdown) - Call disconnected 1505 for administrative reasons 1507 4 (Request) - Call disconnected due to 1508 received Call-Clear-Request 1510 Error Code This field is set to 0 unless a "General 1511 Error" condition exists, in which case 1512 the Result Code is set to 2 and this 1513 field is set to the value corresponding 1514 to the general error condition as 1515 specified in section 2.2. 1517 Cause Code This field gives additional disconnect 1518 information. Its value varies depending 1519 on the type of call being disconnected. 1520 For ISDN calls it is the Q.931 cause 1521 code. 1523 Call Statistics This field is an ASCII string containing 1524 vendor-specific call statistics that can 1525 be logged for diagnostic purposes. If 1526 the length of the string is less than 1527 128, the remainder of the field is filled 1528 with octets of value 0. 1530 2.14. WAN-Error-Notify 1532 The WAN-Error-Notify message is a PPTP control message sent by the PAC 1533 to the PNS to indicate WAN error conditions (conditions that occur on 1534 the interface supporting PPP). The counters in this message are 1535 cumulative. This message should only be sent when an error occurs, and 1536 not more than once every 60 seconds. The counters are reset when a new 1537 call is established. 1539 0 1 2 3 1540 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 1541 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1542 | Length | PPTP Message Type | 1543 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1544 | Magic Cookie | 1545 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1546 | Control Message type | Reserved0 | 1547 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1548 | Peer's Call ID | Reserved1 | 1549 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1550 | CRC Errors | 1551 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1552 | Framing Errors | 1553 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1554 | Hardware Overruns | 1555 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1556 | Buffer Overruns | 1557 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1558 | Time-out Errors | 1559 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1560 | Alignment Errors | 1561 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1563 Length Total length in octets of this PPTP 1564 message, including the entire PPTP 1565 header. 1567 PPTP Message Type 1 for Control Message. 1569 Magic Cookie 0x1A2B3C4D. 1571 Control Message Type 14 for WAN-Error-Notify. 1573 Reserved0 This field MUST be 0. 1575 Peer's Call ID Th Call ID assigned by the PNS to this 1576 call. 1578 CRC Errors Number of PPP frames received with CRC 1579 errors since session was established. 1581 Framing Errors Number of improperly framed PPP packets 1582 received. 1584 Hardware Overruns Number of receive buffer over-runs since 1585 session was established. 1587 Buffer Overruns Number of buffer over-runs detected since 1588 session was established. 1590 Time-out Errors Number of time-outs since call was 1591 established. 1593 Alignment Errors Number of alignment errors since call was 1594 established. 1596 2.15. Set-Link-Info 1598 The Set-Link-Info message is a PPTP control message sent by the PNS to 1599 the PAC to set PPP-negotiated options. Because these options can change 1600 at any time during the life of the call, the PAC must be able to update 1601 its internal call information dynamically and perform PPP negotiation on 1602 an active PPP session. 1604 0 1 2 3 1605 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 1606 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1607 | Length | PPTP Message Type | 1608 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1609 | Magic Cookie | 1610 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1611 | Control Message type | Reserved0 | 1612 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1613 | Peer's Call ID | Reserved1 | 1614 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1615 | Send ACCM | 1616 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1617 | Receive ACCM | 1618 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1620 Length Total length in octets of this PPTP 1621 message, including the entire PPTP 1622 header. 1624 PPTP Message Type 1 for Control Message. 1626 Magic Cookie 0x1A2B3C4D. 1628 Control Message Type 15 for Set-Link-Info. 1630 Reserved0 This field MUST be 0. 1632 Peer's Call ID The value of the Call ID assigned by the 1633 PAC to this call. 1635 Reserved1 This field MUST be 0. 1637 Send ACCM The send ACCM value the client should use 1638 to process outgoing PPP packets. The 1639 default value used by the client until 1640 this message is received is 0XFFFFFFFF. 1641 See [7]. 1643 Receive ACCM The receive ACCM value the client should 1644 use to process incoming PPP packets. The 1645 default value used by the client until 1646 this message is received is 0XFFFFFFFF. 1647 See [7]. 1649 2.16. General Error Codes 1651 General error codes pertain to types of errors which are not specific to 1652 any particular PPTP request, but rather to protocol or message format 1653 errors. If a PPTP reply indicates in its Result Code that a general 1654 error occurred, the General Error value should be examined to determined 1655 what the error was. The currently defined General Error codes and their 1656 meanings are: 1658 0 (None) - No general error 1660 1 (Not-Connected) - No control connection exists yet for this 1661 PAC-PNS pair 1663 2 (Bad-Format) - Length is wrong or Magic Cookie value is 1664 incorrect 1666 3 (Bad-Value) - One of the field values was out of range or 1667 reserved field was non-zero 1669 4 (No-Resource) - Insufficient resources to handle this command 1670 now 1672 5 (Bad-Call ID) - The Call ID is invalid in this context 1674 6 (PAC-Error) - A generic vendor-specific error occurred in 1675 the PAC 1677 3. Control Connection Protocol Operation 1679 This section describes the operation of various PPTP control connection 1680 functions and the Control Connection messages which are used to support 1681 them. The protocol operation of the control connection is simplified 1682 because TCP is used to provide a reliable transport mechanism. Ordering 1683 and retransmission of messages is not a concern at this level. The TCP 1684 connection itself, however, can close at any time and an appropriate 1685 error recovery mechanism must be provided to handle this case. 1687 Some error recovery procedures are common to all states of the control 1688 connection. If an expected reply does not arrive within 60 seconds, the 1689 control connection is closed, unless otherwise specified. Appropriate 1690 logging should be implemented for easy determination of the problems and 1691 the reasons for closing the control connection. 1693 Receipt of an invalid or malformed Control Connection message should be 1694 logged appropriately, and the control connection should be closed and 1695 restarted to ensure recovery into a known state. 1697 3.1. Control Connection States 1699 The control connection relies on a standard TCP connection for its 1700 service. The PPTP control connection protocol is not distinguishable 1701 between the PNS and PAC, but is distinguishable between the originator 1702 and receiver. The originating peer is the one which first attempts the 1703 TCP open. Since either PAC or PNS may originate a connection, it is 1704 possible for a TCP collision to occur. See section 3.1.3 for a 1705 description of this situation. 1707 3.1.1. Control Connection Originator (may be PAC or PNS) 1709 TCP Open Indication 1710 /Send Start Control 1711 Connection Request +-----------------+ 1712 +------------------------------------>| wait_ctl_reply | 1713 | +-----------------+ 1714 | Collision/See (4.1.3) Close TCP V V V Receive Start Ctl 1715 | +-------------------------------+ | | Connection Reply 1716 | | | | Version OK 1717 ^ V | V 1718 +-----------------+ Receive Start Ctl | +-----------------+ 1719 | idle | Connection Reply | | established | 1720 +-----------------+ Version Not OK | +-----------------+ 1721 ^ | V Local Terminate 1722 | Receive Stop Control | | /Send Stop 1723 | Connection Request | | Control Request 1724 | /Send Stop Control Reply V V 1725 | Close TCP +-----------------+ 1726 +-------------------------------------| wait_stop_reply | 1727 +-----------------+ 1729 idle 1730 The control connection originator attempts to open a TCP 1731 connection to the peer during idle state. When the TCP connection 1732 is open, the originator transmits a send Start-Control-Connection- 1733 Request and then enters the wait_ctl_reply state. 1735 wait_ctl_reply 1736 The originator checks to see if another TCP connection has been 1737 requested from the same peer, and if so, handles the collision 1738 situation described in section 3.1.3. 1740 When a Start-Control-Connection-Reply is received, it is examined 1741 for a compatible version. If the version of the reply is lower 1742 than the version sent in the request, the older (lower) version 1743 should be used provided it is supported. If the version in the 1744 reply is earlier and supported, the originator moves to the 1745 established state. If the version is earlier and not supported, a 1746 Stop-Control-Connection- Request SHOULD be sent to the peer and 1747 the originator moves into the wait_stop_reply state. 1749 established 1750 An established connection may be terminated by either a local 1751 condition or the receipt of a Stop-Control-Connection-Request. In 1752 the event of a local termination, the originator MUST send a Stop- 1753 Control-Connection-Request and enter the wait_stop_reply state. 1755 If the originator receives a Stop-Control-Connection-Request it 1756 SHOULD send a Stop-Control-Connection-Reply and close the TCP 1757 connection making sure that the final TCP information has been 1758 "pushed" properly. 1760 wait_stop_reply 1761 If a Stop-Control-Connection-Reply is received, the TCP connection 1762 SHOULD be closed and the control connection becomes idle. 1764 3.1.2. Control connection Receiver (may be PAC or PNS) 1766 Receive Start Control Connection Request 1767 Version Not OK/Send Start Control Connection 1768 Reply with Error 1769 +--------+ 1770 | | Receive Control Connection Request Version OK 1771 | | /Send Start Control Connection Reply 1772 | | +----------------------------------------+ 1773 ^ V ^ V 1774 +-----------------+ Receive Start Ctl +-----------------+ 1775 | Idle | Connection Request | Established | 1776 +-----------------+ /Send Stop Reply +-----------------+ 1777 ^ ^ Close TCP V V Local Terminate 1778 | +-------------------------------------+ | /Send Stop 1779 | | Control Conn. 1780 | V Request 1781 | +-----------------+ 1782 +-------------------------------------| Wait-Stop-Reply | 1783 Receive Stop Control +-----------------+ 1784 Connection Reply 1785 /Close TCP 1787 idle 1788 The control connection receiver waits for a TCP open attempt on port 1789 1723. When notified of an open TCP connection, it should prepare to 1790 receive PPTP messages. When a Start-Control-Connection-Request is 1791 received its version field should be examined. If the version is 1792 earlier than the receiver's version and the earlier version can be 1793 supported by the receiver, the receiver SHOULD send a Start-Control- 1794 Connection-Reply. If the version is earlier than the receiver's 1795 version and the version cannot be supported, the receiver SHOULD send 1796 a Start- Connection-Reply message, close the TCP connection and 1797 remain in the idle state. If the receiver's version is the same as 1798 earlier than the peer's, the receiver SHOULD send a Start-Control- 1799 Connection-Reply with the receiver's version and enter the 1800 established state. 1802 established 1803 An established connection may be terminated by either a local 1804 condition or the reception of a Stop-Control-Connection-Request. In 1805 the event of a local termination, the originator MUST send a Stop- 1806 Control-Connection-Request and enter the wait_stop_reply state. 1808 If the originator receives a Stop-Control-Connection-Request it 1809 SHOULD send a Stop-Control-Connection-Reply and close the TCP 1810 connection, making sure that the final TCP information has been 1811 "pushed" properly. 1813 wait_stop_reply 1814 If a Stop-Control-Connection-Reply is received, the TCP connection 1815 SHOULD be closed and the control connection becomes idle. 1817 3.1.3. Start Control Connection Initiation Request Collision 1819 A PAC and PNS must have only one control connection between them. It is 1820 possible, however, for a PNS and a PAC to simultaneously attempt to 1821 establish a control connection to each other. When a Start- Control- 1822 Connection-Request is received on one TCP connection and another Start- 1823 Control-Connection-Request has already been sent on another TCP 1824 connection to the same peer, a collision has occurred. 1826 The "winner" of the initiation race is the peer with the higher IP 1827 address (compared as 32 bit unsigned values, network number more 1828 significant). For example, if the peers 192.33.45.17 and 192.33.45.89 1829 collide, the latter will be declared the winner. The loser will 1830 immediately close the TCP connection it initiated, without sending any 1831 further PPTP control messages on it and will respond to the winner's 1832 request with a Start-Control-Connection-Reply message. The winner will 1833 wait for the Start-Control-Connection-Reply on the connection it 1834 initiated and also wait for a TCP termination indication on the 1835 connection the loser opened. The winner MUST NOT send any messages on 1836 the connection the loser initiated. 1838 3.1.4. Keep Alives and Timers 1840 A control connection SHOULD be closed by closing the underlying TCP 1841 connection under the following circumstances: 1843 1. If a control connection is not in the established state (i.e., 1844 Start-Control-Connection-Request and Start-Control-Connection- 1845 Reply have not been exchanged), a control connection SHOULD be 1846 closed after 60 seconds by a peer waiting for a Start-Control- 1847 Connection-Request or Start-Control-Connection-Reply message. 1849 2. If a peer's control connection is in the established state and has 1850 not received a control message for 60 seconds, it SHOULD send a 1851 Echo-Request message. If an Echo-Reply is not received 60 seconds 1852 after the Echo-Request message transmission, the control 1853 connection SHOULD be closed. 1855 3.2. Call States 1857 3.2.1. Timing considerations 1859 Because of the real-time nature of telephone signaling, both the PNS and 1860 PAC should be implemented with multi-threaded architectures such that 1861 messages related to multiple calls are not serialized and blocked. The 1862 transit delay between the PAC and PNS should not exceed one second. The 1863 call and connection state figures do not specify exceptions caused by 1864 timers. The implicit assumption is that since the TCP-based control 1865 connection is being verified with keep-alives, there is less need to 1866 maintain strict timers for call control messages. 1868 Establishing outbound international calls, including the modem training 1869 and negotiation sequences, may take in excess of 1 minute so the use of 1870 short timers is discouraged. 1872 If a state transition does not occur within 1 minute (except for 1873 connections in the idle or established states), the integrity of the 1874 protocol processing between the peers is suspect and the ENTIRE CONTROL 1875 CONNECTION should be closed and restarted. All Call IDs are logically 1876 released whenever a control connection is started. This presumably also 1877 helps in preventing toll calls from being "lost" and never cleared. 1879 3.2.2. Call ID Values 1881 Each peer assigns a Call ID value to each user session it requests or 1882 accepts. This Call ID value MUST be unique for the tunnel between the 1883 PNS and PAC to which it belongs. Tunnels to other peers can use the same 1884 Call ID number so the receiver of a packet on a tunnel needs to 1885 associate a user session with a particular tunnel and Call ID. It is 1886 suggested that the number of potential Call ID values for each tunnel be 1887 at least twice as large as the maximum number of calls expected on a 1888 given tunnel. 1890 A session is defined by the triple (PAC, PNS, Call ID). 1892 3.2.3. Incoming Calls 1894 An Incoming-Call-Request message is generated by the PAC when an 1895 associated telephone line rings. The PAC selects a Call ID and serial 1896 number and indicates the call bearer type. Modems should always 1897 indicate analog call type. ISDN calls should indicate digital when 1898 unrestricted digital service or rate adaption is used and analog if 1899 digital modems are involved. Dialing number, dialed number, and 1900 subaddress may be included in the message if they are available from the 1901 telephone network. 1903 Once the PAC sends the Incoming-Call-Request, it waits for a response 1904 from the PNS but does not answer the call from the telephone network. 1905 The PNS may choose not to accept the call if: 1907 - No resources are available to handle more sessions 1909 - The dialed, dialing, or subaddress fields are not indicative of 1910 an authorized user 1912 - The bearer service is not authorized or supported 1914 If the PNS chooses to accept the call, it responds with an Incoming- 1915 Call-Reply which also indicates window sizes (see section 4.2). When the 1916 PAC receives the Outgoing-Call-Reply, it attempts to connect the call, 1917 assuming the calling party has not hung up. A final call connected 1918 message from the PAC to the PNS indicates that the call states for both 1919 the PAC and the PNS should enter the established state. 1921 When the dialed-in client hangs up, the call is cleared normally and the 1922 PAC sends a Call-Disconnect-Notify message. If the PNS wishes to clear a 1923 call, it sends a Call-Clear-Request message and then waits for a Call- 1924 Disconnect-Notify. 1926 3.2.3.1. PAC Incoming Call States 1928 Ring/Send Incoming Call Request +-----------------+ 1929 +----------------------------------------->| wait_reply | 1930 | +-----------------+ 1931 | Receive Incoming Call Reply V V V 1932 | Not Accepting | | | Receive Incoming 1933 | +--------------------------------+ | | Call Reply Accepting 1934 | | +------------------------------+ | /Answer call; Send 1935 | | | Abort/Send Call | Call Connected 1936 ^ V V Disconnect Notify V 1937 +-----------------+ +-----------------+ 1938 | idle |<-----------------------------| established | 1939 +-----------------+ Receive Clear Call Request +-----------------+ 1940 or telco call dropped 1941 or local disconnect 1942 /Send Call Disconnect Notify 1944 The states associated with the PAC for incoming calls are: 1946 idle 1947 The PAC detects an incoming call on one of its telco interfaces. 1948 Typically this means an analog line is ringing or an ISDN TE has 1949 detected an incoming Q.931 SETUP message. The PAC sends an Incoming- 1950 Call-Request message and moves to the wait_reply state. 1952 wait_reply 1953 The PAC receives an Incoming-Call-Reply message indicating non- 1954 willingness to accept the call (general error or don't accept) and 1955 moves back into the idle state. If the reply message indicates that 1956 the call is accepted, the PAC sends an Incoming-Call-Connected 1957 message and enters the established state. 1959 established 1960 Data is exchanged over the tunnel. The call may be cleared 1961 following: 1962 An event on the telco connection. The PAC sends a Call-Disconnect- 1963 Notify message 1965 Receipt of a Call-Clear-Request. The PAC sends a Call-Disconnect- 1966 Notify message 1968 A local reason. The PAC sends a Call-Disconnect-Notify message. 1970 3.2.3.2. PNS Incoming Call States 1972 Receive Incoming Call Request 1973 /Send Incoming Call Reply +-----------------+ 1974 Not Accepting if Error | Wait-Connect | 1975 +-----+ +-----------------+ 1976 | | Receive Incoming Call Req. ^ V V 1977 | | /Send Incoming Call Reply OK | | | Receive Incoming 1978 | | +--------------------------------+ | | Call Connect 1979 ^ V ^ V------------------------------+ V 1980 +-----------------+ Receive Call Disconnect +-----------------+ 1981 | Idle | Notify +- | Established | 1982 +-----------------+ | +-----------------+ 1983 ^ ^ | V Local Terminate 1984 | +----------------------------+ | /Send Call Clear 1985 | Receive Call Disconnect | Request 1986 | Notify V 1987 | +-----------------+ 1988 +--------------------------------------| Wait-Disconnect | 1989 Receive Call Disconnect +-----------------+ 1990 Notify 1992 The states associated with the PNS for incoming calls are: 1994 idle 1995 An Incoming-Call-Request message is received. If the request is 1996 not acceptable, an Incoming-Call-Reply is sent back to the PAC and 1997 the PNS remains in the idle state. If the Incoming-Call-Request 1998 message is acceptable, an Incoming-Call-Reply is sent indicating 1999 accept in the result code. The session moves to the wait_connect 2000 state. 2002 wait_connect 2003 If the session is connected on the PAC, the PAC sends an incoming 2004 call connect message to the PNS which then moves into established 2005 state. The PAC may send a Call-Disconnect-Notify to indicate that 2006 the incoming caller could not be connected. This could happen, 2007 for example, if a telephone user accidently places a standard 2008 voice call to a PAC resulting in a handshake failure on the called 2009 modem. 2011 established 2012 The session is terminated either by receipt of a Call-Disconnect- 2013 Notify message from the PAC or by sending a Call-Clear-Request. 2014 Once a Call-Clear-Request has been sent, the session enters the 2015 wait_disconnect state. 2017 wait_disconnect 2018 Once a Call-Disconnect-Notify is received the session moves 2019 back to the idle state. 2021 3.2.4. Outgoing Calls 2023 Outgoing messages are initiated by a PNS and instruct a PAC to place a 2024 call on a telco interface. There are only two messages for outgoing 2025 calls: Outgoing-Call-Request and Outgoing-Call-Reply. The PNS sends an 2026 Outgoing-Call-Request specifying the dialed party phone number and 2027 subaddress as well as speed and window parameters. The PAC MUST respond 2028 to the Outgoing-Call-Request message with an Outgoing-Call- Reply 2029 message once the PAC determines that: 2031 The call has been successfully connected 2033 A call failure has occurred for reasons such as: no interfaces are 2034 available for dial-out, the called party is busy or does not answer, 2035 or no dial tone is detected on the interface chosen for dialing 2037 3.2.4.1. PAC Outgoing Call States 2039 Receive Outgoing Call Request in Error 2040 /Send Outgoing Call Reply with Error 2041 |--------+ 2042 | | Receive Outgoing Call Request No Error 2043 | | /Off Hook; Dial 2044 | | +----------------------------------------- 2045 ^ V ^ V 2046 +-----------------+ Incomplete Call +-----------------+ 2047 | idle | /Send Outgoing Call | wait_cs_ans | 2048 +-----------------+ Reply with Error +-----------------+ 2049 ^ ^ or Recv. Call Clear Req. V V Telco Answer 2050 | | /Send Disconnect Notify| | /Send Outgoing 2051 | +-------------------------------------+ | Call Reply. 2052 | V 2053 | +-----------------+ 2054 +-------------------------------------| established | 2055 Receive Call Clear Request +-----------------+ 2056 or local terminate 2057 or telco disconnect 2058 /Hangup call and send 2059 Call Disconnect Notify 2061 The states associated with the PAC for outgoing calls are: 2063 idle 2064 Received Outgoing-Call-Request. If this is received in error, 2065 respond with an Outgoing-Call-Reply with error condition set. 2066 Otherwise, allocate physical channel to dial on. Place the 2067 outbound call, wait for a connection, and move to the wait_cs_ans 2068 state. 2070 wait_cs_ans 2071 If the call is incomplete, send an Outgoing-Call-Reply with a non- 2072 zero Error Code. If a timer expires on an outbound call, send back 2073 an Outgoing-Call-Reply with a non-zero Error Code. If a circuit 2074 switched connection is established, send an Outgoing-Call-Reply 2075 indicating success. 2077 established 2078 If a Call-Clear-Request is received, the telco call SHOULD be 2079 released via appropriate mechanisms and a Call-Disconnect-Notify 2080 message SHOULD BE sent to the PNS. If the call is disconnected by 2081 the client or by the telco interface, a Call-Disconnect-Notify 2082 message SHOULD be sent to the PNS. 2084 3.2.4.2. PNS Outgoing Call States 2086 Open Indication Abort/Send 2087 /Send Outgoing Call Call Clear 2088 Request +-----------------+ Request 2089 +-------------------------------->| Wait-Reply |------------+ 2090 | +-----------------+ | 2091 | Receive Outgoing Call Reply V V Receive Outgoing | 2092 | with Error | | Call Reply | 2093 | +-------------------------------+ | No Error | 2094 ^ V V | 2095 +-----------------+ +-----------------+ | 2096 | Idle |<-----------------------------| Established | | 2097 +-----------------+ Receive Call Disconnect +-----------------+ | 2098 ^ Notify V Local Terminate | 2099 | | /Send Call Clear | 2100 | | Request | 2101 | Receive Call Disconnect V | 2102 | Notify +-----------------+ | 2103 +---------------------------------| Wait-Disconnect |<-----------+ 2104 +-----------------+ 2106 The states associated with the PNS for outgoing calls are: 2108 idle 2109 An Outgoing-Call-Request message is sent to the PAC and the 2110 session moves into the wait_reply state. 2112 wait_reply 2113 An Outgoing-Call-Reply is received which indicates an error. The 2114 session returns to idle state. No telco call is active. If the 2115 Outgoing-Call-Reply does not indicate an error, the telco call is 2116 connected and the session moves to the established state. 2118 established 2119 If a Call-Disconnect-Notify is received, the telco call has been 2120 terminated for the reason indicated in the Result and Cause Codes. 2121 The session moves back to the idle state. If the PNS chooses to 2122 terminate the session, it sends a Call-Clear-Request to the PAC 2123 and then enters the wait_disconnect state. 2125 wait_disconnect 2126 A session disconnection is waiting to be confirmed by the PAC. 2127 Once the PNS receives the Call-Disconnect-Notify message, the 2128 session enters idle state. 2130 4. Tunnel Protocol Operation 2132 The user data carried by the PPTP protocol are PPP data packets. PPP 2133 packets are carried between the PAC and PNS, encapsulated in GRE packets 2134 which in turn are carried over IP. The encapsulated PPP packets are 2135 essentially PPP data packets less any media specific framing elements. 2136 No HDLC flags, bit insertion, control characters, or control character 2137 escapes are included. No CRCs are sent through the tunnel. The IP 2138 packets transmitted over the tunnels between a PAC and PNS has the 2139 following general structure: 2140 +--------------------------------+ 2141 | Media Header | 2142 +--------------------------------+ 2143 | IP Header | 2144 +--------------------------------+ 2145 | GRE Header | 2146 +--------------------------------+ 2147 | PPP Packet | 2148 +--------------------------------+ 2150 4.1. Enhanced GRE header 2152 The GRE header used in PPTP is enhanced slightly from that specified in 2153 the current GRE protocol specification [1,2]. The main difference 2154 involves the definition of a new Acknowledgment Number field, used to 2155 determine if a particular GRE packet or set of packets has arrived at 2156 the remote end of the tunnel. This Acknowledgment capability is not 2157 used in conjunction with any retransmission of user data packets. It is 2158 used instead to determine the rate at which user data packets are to be 2159 transmitted over the tunnel for a given user session. The format of the 2160 enhanced GRE header is as follows: 2162 0 1 2 3 2163 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 2164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2165 |C|R|K|S|s|Recur|A| Flags | Ver | Protocol Type | 2166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2167 | Key (HW) Payload Length | Key (LW) Call ID | 2168 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2169 | Sequence Number (Optional) | 2170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2171 | Acknowledgment Number (Optional) | 2172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2174 C 2175 (Bit 0) Checksum Present. Set to zero (0). 2177 R 2178 (Bit 1) Routing Present. Set to zero (0). 2180 K 2181 (Bit 2) Key Present. Set to one (1). 2183 S 2184 (Bit 3) Sequence Number Present. Set to one (1) if a payload 2185 (data) packet is present. Set to zero (0) if payload is not 2186 present (GRE packet is an Acknowledgment only). 2188 s 2189 (Bit 4) Strict source route present. Set to zero (0). 2191 Recur 2192 (Bits 5-7) Recursion control. Set to zero (0). 2194 A 2195 (Bit 8) Acknowledgment sequence number present. Set to one (1) if 2196 packet contains Acknowledgment Number to be used for acknowledging 2197 previously transmitted data. 2199 Flags 2200 (Bits 9-12) Must be set to zero (0). 2202 Ver 2203 (Bits 13-15) Must contain 1 (enhanced GRE). 2205 Protocol Type 2206 Set to hex 880B [8]. 2208 Key 2209 Use of the Key field is up to the implementation. PPTP uses it as 2210 follows: 2211 Payload Length 2212 (High 2 octets of Key) Size of the payload, not including 2213 the GRE header 2215 Call ID 2216 (Low 2 octets) Contains the Peer's Call ID for the session 2217 to which this packet belongs. 2219 Sequence Number 2220 Contains the sequence number of the payload. Present if S 2221 bit (Bit 3) is one (1). 2223 Acknowledgment Number 2224 Contains the sequence number of the highest numbered GRE 2225 packet received by the sending peer for this user session. 2226 Present if A bit (Bit 8) is one (1). 2228 The payload section contains a PPP data packet without any media 2229 specific framing elements. 2231 The sequence numbers involved are per packet sequence numbers. 2232 The sequence number for each user session is set to zero at 2233 session startup. Each packet sent for a given user session which 2234 contains a payload (and has the S bit (Bit 3) set to one) is 2235 assigned the next consecutive sequence number for that session. 2237 This protocol allows acknowledgments to be carried with the data 2238 and makes the overall protocol more efficient, which in turn 2239 requires less buffering of packets. 2241 4.2. Sliding Window Protocol 2243 The sliding window protocol used on the PPTP data path is used for flow 2244 control by each side of the data exchange. The enhanced GRE protocol 2245 allows packet acknowledgments to be piggybacked on data packets. 2246 Acknowledgments can also be sent separately from data packets. Again, 2247 the main purpose of the sliding window protocol is for flow 2248 control--retransmissions are not performed by the tunnel peers. 2250 4.2.1. Initial Window Size 2252 Although each side has indicated the maximum size of its receive window, 2253 it is recommended that a conservative approach be taken when beginning 2254 to transmit data. The initial window size on the transmitter is set to 2255 half the maximum size the receiver requested, with a minimum size of one 2256 packet. The transmitter stops sending packets when the number of 2257 packets awaiting acknowledgment is equal to the current window size. As 2258 the receiver successfully digests each window, the window size on the 2259 transmitter is bumped up by one packet until the maximum is reached. 2260 This method prevents a system from flooding an already congested network 2261 because no history has been established. 2263 4.2.2. Closing the Window 2265 When a time-out does occur on a packet, the sender adjusts the size of 2266 the transmit window down to one half its value when it failed. 2267 Fractions are rounded up, and the minimum window size is one. 2269 4.2.3. Opening the Window 2271 With every successful transmission of a window's worth of packets 2272 without a time-out, the transmit window size is increased by one packet 2273 until it reaches the maximum window size that was sent by the other side 2274 when the call was connected. As stated earlier, no retransmission is 2275 done on a time-out. After a time-out, the transmission resumes with the 2276 window starting at one half the size of the transmit window when the 2277 time-out occurred and adjusting upward by one each time the transmit 2278 window is filled with packets that are all acknowledged without time- 2279 outs. 2281 4.2.4. Window Overflow 2283 When a receiver's window overflows with too many incoming packets, 2284 excess packets are thrown away. This situation should not arise if the 2285 sliding window procedures are being properly followed by the transmitter 2286 and receiver. It is assumed that, on the transmit side, packets are 2287 buffered for transmission and are no longer accepted from the packet 2288 source when the transmit buffer fills. 2290 4.2.5. Multi-packet Acknowledgment 2292 One feature of the PPTP sliding window protocol is that it allows the 2293 acknowledgment of multiple packets with a single acknowledgment. All 2294 outstanding packets with a sequence number lower or equal to the 2295 acknowledgment number are considered acknowledged. Time-out calculations 2296 are performed using the time the packet corresponding to the highest 2297 sequence number being acknowledged was transmitted. 2299 Adaptive time-out calculations are only performed when an Acknowledgment 2300 is received. When multi-packet acknowledgments are used, the overhead 2301 of the adaptive time-out algorithm is reduced. The PAC is not required 2302 to transmit multi-packet acknowledgments; it can instead acknowledge 2303 each packet individually as it is delivered to the PPP client. 2305 4.3. Out-of-sequence Packets 2307 Occasionally packets lose their sequencing across a complicated 2308 internetwork. Say, for example that a PNS sends packets 0 to 5 to a 2309 PAC. Because of rerouting in the internetwork, packet 4 arrives at the 2310 PAC before packet 3. The PAC acknowledges packet 4, and may assume 2311 packet 3 is lost. This acknowledgment grants window credit beyond packet 2312 4. 2314 When the PAC does receive packet 3, it MUST not attempt to transmit it 2315 to the corresponding PPP client. To do so could cause problems, as 2316 proper PPP protocol operation is premised upon receiving packets in 2317 sequence. PPP does properly deal with the loss of packets, but not with 2318 reordering so out of sequence packets between the PNS and PAC MUST be 2319 silently discarded, or they may be reordered by the receiver. When 2320 packet 5 comes in, it is acknowledged by the PAC since it has a higher 2321 sequence number than 4, which was the last highest packet acknowledged 2322 by the PAC. Packets with duplicate sequence numbers should never occur 2323 since the PAC and PNS never retransmit GRE packets. A robust 2324 implementation will silently discard duplicate GRE packets, should it 2325 receive any. 2327 4.4. Acknowledgment Time-Outs 2329 PPTP uses sliding windows and time-outs to provide both user session 2330 flow-control across the internetwork and to perform efficient data 2331 buffering to keep the PAC-PNS data channels full without causing receive 2332 buffer overflow. PPTP requires that a time-out be used to recover from 2333 dropped data or acknowledgment packets. The exact implementation of the 2334 time-out is vendor-specific. It is suggested that an adaptive time-out 2335 be implemented with backoff for congestion control. The time-out 2336 mechanism proposed here has the following properties: 2338 Independent time-outs for each session. A device (PAC or PNS) will 2339 have to maintain and calculate time-outs for every active session. 2341 An administrator-adjustable maximum time-out, MaxTimeOut, unique to 2342 each device. 2344 An adaptive time-out mechanism that compensates for changing 2345 throughput. To reduce packet processing overhead, vendors may choose 2346 not to recompute the adaptive time-out for every received 2347 acknowledgment. The result of this overhead reduction is that the 2348 time-out will not respond as quickly to rapid network changes. 2350 Timer backoff on time-out to reduce congestion. The backed-off timer 2351 value is limited by the configurable maximum time-out value. Timer 2352 backoff is done every time an acknowledgment time-out occurs. 2354 In general, this mechanism has the desirable behavior of quickly backing 2355 off upon a time-out and of slowly decreasing the time-out value as 2356 packets are delivered without time-outs. 2358 Some definitions: 2360 Packet Processing Delay (PPD) is the amount of time required for each 2361 side to process the maximum amount of data buffered in their receive 2362 packet sliding window. The PPD is the value exchanged between the PAC 2363 and PNS when a call is established. For the PNS, this number should 2364 be small. For a PAC making modem connections, this number could be 2365 significant. 2367 Sample is the actual amount of time incurred receiving an 2368 acknowledgment for a packet. The Sample is measured, not calculated. 2370 Round-Trip Time (RTT) is the estimated round-trip time for an 2371 Acknowledgment to be received for a given transmitted packet. When 2372 the network link is a local network, this delay will be minimal (if 2373 not zero). When the network link is the Internet, this delay could be 2374 substantial and vary widely. RTT is adaptive: it will adjust to 2375 include the PPD and whatever shifting network delays contribute to 2376 the time between a packet being transmitted and receiving its 2377 acknowledgment. 2379 Adaptive Time-Out (ATO) is the time that must elapse before an 2380 acknowledgment is considered lost. After a time-out, the sliding 2381 window is partially closed and the ATO is backed off. 2383 The Packet Processing Delay (PPD) parameter is a 16-bit word exchanged 2384 during the Call Control phase that represents tenths of a second (64 2385 means 6.4 seconds). The protocol only specifies that the parameter is 2386 exchanged, it does not specify how it is calculated. The way values for 2387 PPD are calculated is implementation-dependent and need not be variable 2388 (static time- outs are allowed). The PPD must be exchanged in the call 2389 connect sequences, even if it remains constant in an implementation. One 2390 possible way to calculate the PPD is: 2392 PPD' = ((PPP_MAX_DATA_MTU - Header) * WindowSize * 8) / ConnectRate 2393 PPD = PPD' + PACFudge 2395 Header is the total size of the IP and GRE headers, which is 36. The MTU 2396 is the overall MTU for the internetwork link between the PAC and PNS. 2397 WindowSize represents the number of packets in the sliding window, and 2398 is implementation-dependent. The latency of the internetwork could be 2399 used to pick a window size sufficient to keep the current session's pipe 2400 full. The constant 8 converts octets to bits (assuming ConnectRate is in 2401 bits per second). If ConnectRate is in bytes per second, omit the 8. 2402 PACFudge is not required but can be used to take overall processing 2403 overhead of the PAC into account. 2405 The value of PPD is used to seed the adaptive algorithm with the initial 2406 RTT[n-1] value. 2408 4.4.1. Calculating Adaptive Acknowledgment Time-Out 2410 We still must decide how much time to allow for acknowledgments to 2411 return. If the time-out is set too high, we may wait an unnecessarily 2412 long time for dropped packets. If the time-out is too short, we may time 2413 out just before the acknowledgment arrives. The acknowledgment time-out 2414 should also be reasonable and responsive to changing network conditions. 2416 The suggested adaptive algorithm detailed below is based on the TCP 1989 2417 implementation and is explained in [11]. 'n' means this iteration of 2418 the calculation, and 'n-1' refers to values from the last calculation. 2420 DIFF[n] = SAMPLE[n] - RTT[n-1] 2421 DEV[n] = DEV[n-1] + (beta * (|DIFF[n]| - DEV[n-1])) 2422 RTT[n] = RTT[n-1] + (alpha * DIFF[n]) 2423 ATO[n] = MAX (MinTimeOut, MIN (RTT[n] + (chi * DEV[n]), MaxTimeOut)) 2425 DIFF represents the error between the last estimated round-trip time 2426 and the measured time. DIFF is calculated on each iteration. 2428 DEV is the estimated mean deviation. This approximates the standard 2429 deviation. DEV is calculated on each iteration and stored for use in 2430 the next iteration. Initially, it is set to 0. 2432 RTT is the estimated round-trip time of an average packet. RTT is 2433 calculated on each iteration and stored for use in the next 2434 iteration. Initially, it is set to PPD. 2436 ATO is the adaptive time-out for the next transmitted packet. ATO is 2437 calculated on each iteration. Its value is limited, by the MIN 2438 function, to be a maximum of the configured MaxTimeOut value. 2440 Alpha is the gain for the average and is typically 1/8 (0.125). 2442 Beta is the gain for the deviation and is typically 1/4 (0.250). 2444 Chi is the gain for the time-out and is typically set to 4. 2446 To eliminate division operations for fractional gain elements, the 2447 entire set of equations can be scaled. With the suggested gain 2448 constants, they should be scaled by 8 to eliminate all division. To 2449 simplify calculations, all gain values are kept to powers of two so that 2450 shift operations can be used in place of multiplication or division. 2452 4.4.2. Congestion Control: Adjusting for Time-Out 2454 This section describes how the calculation of ATO is modified in the 2455 case where a time-out does occur. When a time-out occurs, the time-out 2456 value should be adjusted rapidly upward. Although the GRE packets are 2457 not retransmitted when a time-out occurs, the time-out should be 2458 adjusted up toward a maximum limit. To compensate for shifting 2459 internetwork time delays, a strategy must be employed to increase the 2460 time-out when it expires (notice that in addition to increasing the 2461 time-out, we are also shrinking the size of the window as described in 2462 the next section). For an interval in which a time-out occurs, the new 2463 ATO is calculated as: 2465 RTT[n] = delta * RTT[n-1] 2466 DEV[n] = DEV[n-1] 2467 ATO[n] = MAX (MinTimeOut, MIN (RTT[n] + (chi * DEV[n]), MaxTimeOut)) 2469 In this calculation of ATO, only the two values that both contribute to 2470 ATO and are stored for the next iteration are calculated. RTT is scaled 2471 by delta, and DEV is unmodified. DIFF is not carried forward and is not 2472 used in this scenario. A value of 2 for Delta, the time-out gain factor 2473 for RTT, is suggested. 2475 5. Security Considerations 2477 The security of user data passed over the tunneled PPP connection is 2478 addressed by PPP, as is authentication of the PPP peers. 2480 Because the PPTP control channel messages are neither authenticated nor 2481 integrity protected, it might be possible for an attacker to hijack the 2482 underlying TCP connection. It is also possible to manufacture false 2483 control channel messages and alter genuine messages in transit without 2484 detection. 2486 The GRE packets forming the tunnel itself are not cryptographically 2487 protected. Because the PPP negotiations are carried out over the 2488 tunnel, it may be possible for an attacker to eavesdrop on and modify 2489 those negotiations. 2491 Unless the PPP payload data is cryptographically protected, it can be 2492 captured and read or modified. 2494 6. Authors' Addresses 2496 Kory Hamzeh 2497 Ascend Communications 2498 1275 Harbor Bay Parkway 2499 Alameda, CA 94502 2500 Email: kory@ascend.com 2502 Gurdeep Singh Pall 2503 Microsoft Corporation 2504 Redmond, WA 2505 Email: gurdeep@microsoft.com 2506 William Verthein 2507 U.S. Robotics/3Com 2509 Jeff Taarud 2510 Copper Mountain Networks 2512 W. Andrew Little 2513 ECI Telematics 2515 Glen Zorn 2516 Microsoft Corporation 2517 Redmond, WA 2518 Email: glennz@microsoft.com 2520 7. References 2522 [1] Hanks, S., Li, T., Farinacci, D., Traina, P., "Generic Routing 2523 Encapsulation (GRE)", RFC 1701, October 1994 2525 [2] Hanks, S., Li, T., Farinacci, D., Traina, P., "Generic Routing 2526 Encapsulation (GRE) over IPv4 Networks", RFC 1702, October 1994 2528 [3] Lloyd, B., Simpson, W., "PPP Authentication Protocols", RFC 1334, 2529 October 1992 2531 [4] Postel, J. B., "Transmission Control Protocol", STD 7, RFC 793, 2532 September 1981 2534 [5] Postel, J. B., "User Data Protocol", STD 6, RFC 768, August 1980 2536 [6] Reynolds, J., Postel, J., "Assigned Numbers", STD 2, RFC 1700, 2537 October, 1994 2539 [7] Simpson, W., editor, "The Point-to-Point Protocol (PPP)", STD 51, 2540 RFC 1661, July 1994 2542 [8] Ethertype for PPP, Reserved with Xerox Corporation. 2544 [9] Simpson, W., "PPP Challenge Handshake Authentication Protocol 2545 (CHAP)", RFC 1994, August 1996 2547 [10] Blunk, L., Vollbrecht, J., "PPP Extensible Authentication Protocol 2548 (EAP)", RFC 2284, March 1998 2550 [11] Stevens, R., "TCP/IP Illustrated, Volume 1", p. 300, Addison- 2551 Wesley, 1994 2553 [12] Bradner, S., "Key words for use in RFCs to Indicate Requirement 2554 Levels", BCP 14, RFC 2119, March 1997 2556 8. Expiration Date 2558 This memo is filed as and expires 2559 October 30, 1999. 2561 ------- End of Forwarded Message