idnits 2.17.1 draft-ietf-pppext-pptp-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-25) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. 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 Internet-Drafts being working documents. ** 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. ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard 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 44 instances of too long lines in the document, the longest one being 6 characters in excess of 72. == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 279: '... MUST This word, o...' RFC 2119 keyword, line 283: '... MUST NOT This phrase ...' RFC 2119 keyword, line 286: '... SHOULD This word, o...' RFC 2119 keyword, line 294: '... MAY This word, o...' RFC 2119 keyword, line 297: '...nclude this option MUST be prepared to...' (57 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 107 has weird spacing: '...ltilink hunt-...' == 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 (June 1996) is 10176 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '5' is defined on line 2278, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 1701 (ref. '1') ** Downref: Normative reference to an Informational RFC: RFC 1702 (ref. '2') ** Obsolete normative reference: RFC 1334 (ref. '3') (Obsoleted by RFC 1994) ** Obsolete normative reference: RFC 1700 (ref. '6') (Obsoleted by RFC 3232) Summary: 14 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft Kory Hamzeh 2 Ascend Communications 3 Gurdeep Singh Pall 4 Microsoft Corporation 5 William Verthein 6 U.S. Robotics 7 Jeff Taarud 8 3COM Corporation 9 W. Andrew Little 10 ECI Telematics 11 June 1996 12 Expire in six months 14 Point-to-Point Tunneling Protocol--PPTP 15 draft-ietf-pppext-pptp-00.txt 17 Status of this Memo 19 This document is an Internet-Draft. Internet-Drafts are working 20 documents of the Internet Engineering Task Force (IETF), its areas, 21 and its working groups. Note that other groups may also distribute 22 working documents as Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 To learn the current status of any Internet-Draft, please check the 30 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 31 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 32 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 33 ftp.isi.edu (US West Coast). 35 Abstract 37 This document specifies a protocol which allows the Point 38 to Point Protocol (PPP) to be tunneled through an IP 39 network. PPTP does not specify any changes to the PPP 40 protocol but rather describes a new vehicle for carrying 41 PPP. A client-server architecture is defined in order to 42 decouple functions which exist in current Network Access 43 Servers (NAS) and support Virtual Private Networks (VPNs). 44 The PPTP Network Server (PNS) is envisioned to run on a 45 general purpose operating system while the client, referred 46 to as a PPTP Access Concentrator (PAC) operates on a dial 47 access platform. PPTP specifies a call-control and 48 management protocol which allows the server to control 49 access for dial-in circuit switched calls originating from 50 a PSTN or ISDN or to initiate outbound circuit-switched 51 connections. PPTP uses a GRE-like (Generic Routing 52 Encapsulation) mechanism to provide a flow- and 53 congestion-controlled encapsulated datagram service for 54 carrying PPP packets. 56 1. Introduction 58 PPTP allows existing Network Access Server (NAS) functions to be 59 separated using a client-server architecture. Traditionally, the 60 following functions are implemented by a NAS: 62 1) Physical native interfacing to PSTN or ISDN and control of 63 external modems or terminal adapters. 65 A NAS may interface directly to a telco analog or digital circuit 66 or attach via an external modem or terminal adapter. Control of a 67 circuit-switched connection is accomplished with either modem 68 control or DSS1 ISDN call control protocols. 70 The NAS, in conjunction with the modem or terminal adapters, may 71 perform rate adaption, analog to digital conversion, sync to async 72 conversion or a number of other alterations of data streams. 74 2) Logical termination of a Point-to-Point-Protocol (PPP) Link 75 Control Protocol (LCP) session. 77 3) Participation in PPP authentication protocols [3]. 79 4) Channel aggregation and bundle management for PPP Multilink 80 Protocol. 82 5) Logical termination of various PPP network control protocols 83 (NCP). 85 6) Multiprotocol routing and bridging between NAS interfaces. 87 PPTP divides these functions between the PAC and PNS. The PAC is 88 responsible for functions 1, 2, and possibly 3. The PNS may be 89 responsible for function 3 and is responsible for functions 4, 5, and 90 6. The protocol used to carry PPP protocol data units (PDUs) between 91 the PAC and PNS, as well as call control and management is addressed 92 by PPTP. 94 The decoupling of NAS functions offers these benefits: 96 Flexible IP address management. Dial-in users may maintain a 97 single IP address as they dial into different PACs as long as they 98 are served from a common PNS. If an enterprise network uses 99 unregistered addresses, a PNS associated with the enterprise 100 assigns addresses meaningful to the private network. 102 Support of non-IP protocols for dial networks behind IP networks. 103 This allows Appletalk and IPX, for example to be tunneled through 104 an IP-only provider. The PAC need not be capable of processing 105 these protocols. 107 A solution to the "multilink hunt-group splitting" problem. 108 Multilink PPP, typically used to aggregate ISDN B channels, 109 requires that all of the channels composing a multilink bundle be 110 grouped at a single NAS. Since a multilink PPP bundle can be 111 handled by a single PNS, the channels comprising the bundle may be 112 spread across multiple PACs. 114 1.1 Protocol Goals and Assumptions 116 The PPTP protocol is implemented only by the PAC and PNS. No other 117 systems need to be aware of PPTP. Dial networks may be connected to a 118 PAC without being aware of PPTP. Standard PPP client software should 119 continue to operate on tunneled PPP links. 121 It is envisioned that there will be a many-to-many relationship 122 between PACs and PNSs. A PAC may provide service to many PNSs. For 123 example, an Internet service provider may choose to support PPTP for 124 a number of private network clients and create VPNs for them. Each 125 private network may operate one or more PNSs. A single PNS may 126 associate with many PACs to concentrate traffic from a large number 127 of geographically diverse sites. 129 While PPTP is not envisioned to be implemented on dial user software, 130 this implementation is not precluded by the protocol. 132 PPTP uses a GRE-like discipline to carry user PPP packets. These 133 enhancements allow for low-level congestion and flow control to be 134 provided on the tunnels used to carry user data between PAC and PNS. 135 This mechanism allows for efficient use of the bandwidth available 136 for the tunnels and avoids unnecessary retransmisions and buffer 137 overruns. PPTP does not dictate the particular algorithms to be used 138 for this low level control but it does define the parameters that 139 must be communicated in order to allow such algorithms to work. 140 Suggested algorithms are included in Appendix A. 142 1.2 Terminology 143 Analog Channel 145 A circuit-switched communication path which is intended to 146 carry 3.1 Khz audio in each direction. 148 Digital Channel 150 A circuit-switched communication path which is intended to 151 carry digital information in each direction. 153 Call 155 A connection or attempted connection between two terminal 156 endpoints on a PSTN or ISDN--for example, a telephone call 157 between two modems. 159 Control Connection 161 A control connection is created for each PAC, PNS pair and 162 operates over TCP [4]. The control connection governs aspects 163 of the tunnel and of sessions assigned to the tunnel. 165 Dial User 167 An end-system or router attached to an on-demand PSTN or ISDN 168 which is either the initiator or recipient of a call. 170 Network Access Server (NAS) 172 A device providing temporary, on-demand network access to 173 users. This access is point-to-point using PSTN or ISDN lines. 175 PPTP Access Concentrator (PAC) 177 A device attached to one or more PSTN or ISDN lines capable of 178 PPP operation and of handling the PPTP protocol. The PAC need 179 only implement TCP/IP to pass traffic to one or more PNSs. It 180 may also tunnel non-IP protocols. 182 PPTP Network Server (PNS) 184 A PNS is envisioned to operate on general-purpose 185 computing/server platforms. The PNS handles the server side of 186 the PPTP protocol. Since PPTP relies completely on TCP/IP and 187 is independent of the interface hardware, the PNS may use any 188 combination of IP interface hardware including LAN and WAN 189 devices. 191 Session 193 PPTP is connection-oriented. The PNS and PAC maintain state for 194 each user that is attached to a PAC. A session is created when 195 end-to-end PPP connection is attempted between a dial user and 196 the PNS. The datagrams related to a session are sent over the 197 tunnel between the PAC and PNS. 199 Tunnel 201 A tunnel is defined by a PNS-PAC pair. The tunnel protocol is 202 defined by a modified version of GRE [1,2]. The tunnel carries 203 PPP datagrams between the PAC and the PNS. Many sessions are 204 multiplexed on a single tunnel. A control connection operating 205 over TCP controls the establishment, release, and maintenance 206 of sessions and of the tunnel itself. 208 1.3 Protocol Overview 210 There are two parallel components of PPTP: 1) a Control Connection 211 between each PAC-PNS pair operating over TCP and 2) an IP tunnel 212 operating between the same PAC-PNS pair which is used to transport 213 GRE encapsulated PPP packets for user sessions between the pair. 215 1.3.1 Control Connection Overview 217 Before PPP tunneling can occur between a PAC and PNS, a control 218 connection must be established between them. The control connection 219 is a standard TCP session over which PPTP call control and management 220 information is passed. The control session is logically associated 221 with, but separate from, the sessions being tunneled through a PPTP 222 tunnel. For each PAC-PNS pair both a tunnel and a control connection 223 exist. The control connection is responsible for establishment, 224 management, and release of sessions carried through the tunnel. It is 225 the means by which a PNS is notified of an incoming call at an 226 associated PAC, as well as the means by which a PAC is instructed to 227 place an outgoing dial call. 229 A control connection can be established by either the PNS or the PAC. 230 Following the establishment of the required TCP connection, the PNS 231 and PAC establish the control connection using the Start-Control- 232 Connection-Request and -Reply messages. These messages are also used 233 to exchange information about basic operating capabilities of the PAC 234 and PNS. Once the control connection is established, the PAC or PNS 235 may initiate sessions by requesting outbound calls or responding to 236 inbound requests. The control connection may communicate changes in 237 operating characteristics of an individual user session with a Set- 238 Link-Info message. Individual sessions may be released by either the 239 PAC or PNS, also through Control Connection messages. 241 The control connection itself is maintained by keep-alive echo 242 messages. This ensures that a connectivity failure between the PNS 243 and the PAC can be detected in a timely manner. Other failures can be 244 reported via the Wan-Error-Notify message, also on the control 245 connection. 247 It is intended that the control connection will also carry management 248 related messages in the future, such as a message allowing the PNS to 249 request the status of a given PAC; these message types have not yet 250 been defined. 252 1.3.2 Tunnel Protocol Overview 254 PPTP requires the establishment of a tunnel for each communicating 255 PNS-PAC pair. This tunnel is used to carry all user session PPP 256 packets for sessions involving a given PNS-PAC pair. A key which is 257 present in the GRE header indicates which session a particular PPP 258 packet belongs to. In this manner, PPP packets are multiplexed and 259 demultiplexed over a single tunnel between a given PNS-PAC pair. The 260 value to use in the key field is established by the call 261 establishment procedure which takes place on the control connection. 263 The GRE header also contains acknowledgment and sequencing 264 information that is used to perform some level of congestion-control 265 and error detection over the tunnel. Again the control connection is 266 used to determine rate and buffering parameters that are used to 267 regulate the flow of PPP packets for a particular session over the 268 tunnel. PPTP does not specify the particular algorithms to use for 269 congestion-control and flow-control. Suggested algorithms for the 270 determination of adaptive time-outs to recover from dropped data or 271 acknowledgments on the tunnel are included in Appendix A of this 272 document. 274 1.4 Specification Language 276 In this document, several words are used to signify the requirements 277 of the specification. These words are often capitalized. 279 MUST This word, or the adjective "required", means 280 that the definition is an absolute requirement 281 of the specification. 283 MUST NOT This phrase means that the definition is an 284 absolute prohibition of the specification. 286 SHOULD This word, or the adjective "recommended", 287 means that, in some circumstances, valid 288 reasons may exist to ignore this item, but the 289 full implications must be understood and 290 carefully weighed before choosing a different 291 course. Unexpected results may result 292 otherwise. 294 MAY This word, or the adjective "optional", means 295 that this item is one of an allowed set of 296 alternatives. An implementation which does 297 not include this option MUST be prepared to 298 interoperate with another implementation which 299 does include the option. 301 silently discard The implementation discards the datagram 302 without further processing, and without 303 indicating an error to the sender. The 304 implementation SHOULD provide the capability 305 of logging the error, including the contents 306 of the discarded datagram, and SHOULD record 307 the event in a statistics counter. 309 1.5 Message Format and Protocol Extensibility 311 PPTP defines a set of messages sent as TCP data on the control 312 connection between a PNS and a given PAC. The TCP session for the 313 control connection is established by initiating a TCP connection to 314 port 5678. The source port is assigned to any unused port number. 316 Each PPTP Control Connection message begins with an 8 octet fixed 317 header portion. This fixed header contains the following: the total 318 length of the message, the PPTP Message Type indicator, and a "Magic 319 Cookie". 321 Two Control Connection message types are indicated by the PPTP 322 Message Type field: 324 1 - Control Message 325 2 - Management Message 327 Management messages are currently not defined. 329 The Magic Cookie is always sent as the constant 0x1A2B3C4D. Its 330 basic purpose is to allow the receiver to ensure that it is properly 331 synchronized with the TCP data stream. It should not be used as a 332 means for resynchronizing the TCP data stream in the event that a 333 transmitter issues an improperly formatted message. Loss of 334 synchronization must result in immediate closing of the control 335 connection's TCP session. 337 For clarity, all Control Connection message templates in the next 338 section include the entire PPTP Control Connection message header. 339 Numbers preceded by 0x are hexadecimal values. 341 The currently defined Control Messages, grouped by function, are: 343 Control Message Message Code 345 (Control Connection Management) 347 Start-Control-Connection-Request 1 348 Start-Control-Connection-Reply 2 349 Stop-Control-Connection-Request 3 350 Stop-Control-Connection-Reply 4 351 Echo-Request 5 352 Echo-Reply 6 354 (Call Management) 356 Outgoing-Call-Request 7 357 Outgoing-Call-Reply 8 358 Incoming-Call-Request 9 359 Incoming-Call-Reply 10 360 Incoming-Call-Connected 11 361 Call-Clear-Request 12 362 Call-Disconnect-Notify 13 364 (Error Reporting) 366 WAN-Error-Notify 14 368 (PPP Session Control) 370 Set-Link-Info 15 372 The Start-Control-Connection-Request and -Reply messages determine 373 which version of the Control Connection protocol will be used. The 374 version number field carried in these messages consists of a version 375 number in the high octet and a revision number in the low octet. 376 Version handling is described in Section 3. The current value of the 377 version number field is 0x0100 for version 1, revision 0. 379 The use of the GRE-like header for the encapsulation of PPP user 380 packets is specified in Section 4. 382 The MTU for the user data packets encapsulated in GRE is 1532 octets, 383 not including the IP and GRE headers. 385 2.0 Control Connection Protocol Specification 387 Control Connection messages are used to establish and clear user 388 sessions. The first set of Control Connection messages are used to 389 maintain the control connection itself. The control connection is 390 initiated by either the PNS or PAC after they establish the 391 underlying TCP connection. The procedure and configuration 392 information required to determine which TCP connections are 393 established is not covered by this protocol. 395 The following Control Connection messages are all sent as user data 396 on the established TCP connection between a given PNS-PAC pair. Note 397 that care has been taken to ensure that all word (2 octet) and 398 longword (4 octet) values begin on appropriate boundaries. All data 399 is sent in network order (high order octets first). Any "reserved" 400 fields MUST be sent as 0 values to allow for protocol extensibility. 402 The TCP header is followed by the PPTP fields shown in the following: 404 2.1 Start-Control-Connection-Request 406 The Start-Control-Connection-Request is a PPTP control message used 407 to establish the control connection between a PNS and a PAC. Each 408 PNS-PAC pair requires a dedicated control connection to be 409 established. A control connection must be established before any 410 other PPTP messages can be issued. The establishment of the control 411 connection can be initiated by either the PNS or PAC. A procedure 412 which handles the occurrence of a collision between PNS and PAC 413 Start-Control-Connection-Requests is described in Section 3. 415 0 1 2 3 416 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 417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 418 | Length | PTPP Message Type | 419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 420 | Magic Cookie | 421 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 422 | Control Message Type | Reserved0 | 423 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 424 | Protocol Version | Reserved1 | 425 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 426 | Framing Capabilities | 427 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 428 | Bearer Capabilities | 429 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 430 | Maximum Channels | Firmware Revision | 431 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 432 | | 433 + Host Name (64 octets) + 434 | | 435 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 436 | | 437 + Vendor String (64 octets) + 438 | | 439 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 441 Length Total length in octets of this PPTP 442 message, including the entire PPTP 443 header. 445 PTPP Message Type 1 for Control Message. 447 Magic Cookie 0x1A2B3C4D. This constant value is used 448 as a sanity check on received messages 449 (see Section 1.5). 451 Control Message Type 1 for Start-Control-Connection-Request. 453 Reserved0 This field MUST be 0. 455 Protocol Version The version of the PPTP protocol that the 456 sender wishes to use. 458 Reserved1 This field MUST be 0. 460 Framing Capabilities A set of bits indicating the type of 461 framing that the sender of this message 462 can provide. The currently defined bit 463 settings are: 465 1 - Asynchronous Framing supported 467 2 - Synchronous Framing supported 469 Bearer Capabilities A set of bits indicating the bearer 470 capabilities that the sender of this 471 message can provide. The currently 472 defined bit settings are: 474 1 - Analog access supported 476 2 - Digital access supported 478 Maximum Channels The total number of individual PPP 479 sessions this PAC can support. In 480 Start-Control-Connection-Requests issued 481 by the PNS, this value SHOULD be set to 482 0. It MUST be ignored by the PAC. 484 Firmware Revision This field contains the firmware revision 485 number of the issuing PAC, when issued by 486 the PAC, or the version of the PNS PPTP 487 driver if issued by the PNS. 489 Host Name A 64 octet field containing the DNS name 490 of the issuing PAC or PNS. If less than 491 64 octets in length, the remainder of 492 this field SHOULD be filled with octets 493 of value 0. 495 Vendor Name A 64 octet field containing a vendor 496 specific string describing the type of 497 PAC being used, or the type of PNS 498 software being used if this request is 499 issued by the PNS. If less than 64 500 octets in length, the remainder of this 501 field SHOULD be filled with octets of 502 value 0. 504 2.2 Start-Control-Connection-Reply 506 The Start-Control-Connection-Reply is a PPTP control message sent in 507 reply to a received Start-Control-Connection-Request message. This 508 message contains a result code indicating the result of the control 509 connection establishment attempt. 511 0 1 2 3 512 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 513 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 514 | Length | PTPP Message Type | 515 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 516 | Magic Cookie | 517 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 518 | Control Message Type | Reserved0 | 519 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 520 | Protocol Version | Result Code | Error Code | 521 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 522 | Framing Capability | 523 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 524 | Bearer Capability | 525 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 526 | Maximum Channels | Firmware Revision | 527 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 528 | | 529 + Host Name (64 octets) + 530 | | 531 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 532 | | 533 + Vendor String (64 octets) + 534 | | 535 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 537 Length Total length in octets of this PPTP 538 message, including the entire PPTP 539 header. 541 PTPP Message Type 1 for Control Message. 543 Magic Cookie 0x1A2B3C4D. 545 Control Message Type 2 for Start-Control-Connection-Reply. 547 Reserved0 This field MUST be 0. 549 Protocol Version The version of the PPTP protocol that the 550 sender wishes to use. 552 Result Code Indicates the result of the command 553 channel establishment attempt. Current 554 valid Result Code values are: 556 1 - Successful channel establishment 558 2 - General error -- Error Code 559 indicates the problem 561 3 - Command channel already exists; 563 4 - Requester is not authorized to 564 establish a command channel 566 5 - The protocol version of the 567 requester is not supported 569 Error Code This field is set to 0 unless a "General 570 Error" exists, in which case Result Code 571 is set to 2 and this field is set to the 572 value corresponding to the general error 573 condition as specified in Section 2.16. 575 Framing Capabilities A set of bits indicating the type of 576 framing that the sender of this message 577 can provide. The currently defined bit 578 settings are: 580 1 - Asynchronous Framing supported 582 2 - Synchronous Framing supported. 584 Bearer Capabilities A set of bits indicating the bearer 585 capabilities that the sender of this 586 message can provide. The currently 587 defined bit settings are: 589 1 - Analog access supported 591 2 - Digital access supported 593 Maximum Channels The total number of individual PPP 594 sessions this PAC can support. In a 595 Start-Control-Connection-Reply issued by 596 the PNS, this value SHOULD be set to 0 597 and it must be ignored by the PAC. The 598 PNS MUST NOT use this value to try to 599 track the remaining number of PPP 600 sessions that the PAC will allow. 602 Firmware Revision This field contains the firmware revision 603 number of the issuing PAC, or the version 604 of the PNS PPTP driver if issued by the 605 PNS. 607 Host Name A 64 octet field containing the DNS name 608 of the issuing PAC or PNS. If less than 609 64 octets in length, the remainder of 610 this field SHOULD be filled with octets 611 of value 0. 613 Vendor Name A 64 octet field containing a vendor 614 specific string describing the type of 615 PAC being used, or the type of PNS 616 software being used if this request is 617 issued by the PNS. If less than 64 618 octets in length, the remainder of this 619 field SHOULD be filled with octets of 620 value 0. 622 2.3 Stop-Control-Connection-Request 624 The Stop-Control-Connection-Request is a PPTP control message sent by 625 one peer of a PAC-PNS control connection to inform the other peer 626 that the control connection should be closed. In addition to closing 627 the control connection, all active user calls are implicitly cleared. 628 The reason for issuing this request is indicated in the Reason field. 630 0 1 2 3 631 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 632 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 633 | Length | PTPP Message Type | 634 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 635 | Magic Cookie | 636 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 637 | Control Message Type | Reserved0 | 638 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 639 | Reason | Reserved1 | Reserved2 | 640 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 642 Length Total length in octets of this PPTP 643 message, including the entire PPTP 644 header. 646 PTPP Message Type 1 for Control Message. 648 Magic Cookie 0x1A2B3C4D. 650 Control Message Type 3 for Stop-Control-Connection-Request. 652 Reserved0 This field MUST be 0. 654 Reason Indicates the reason for the control 655 connection being closed. Current valid 656 Reason values are: 658 1 (None) - General request to clear 659 control connection 661 2 (Stop-Protocol) - Can't support 662 peer's version of the protocol 664 3 (Stop-Local-Shutdown) - Requester is 665 being shut down 667 Reserved1, Reserved2 These fields MUST be 0. 669 2.4 Stop-Control-Connection-Reply 671 The Stop-Control-Connection-Reply is a PPTP control message sent by 672 one peer of a PAC-PNS control connection upon receipt of a Stop- 673 Control-Connection-Request from the other peer. 675 0 1 2 3 676 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 677 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 678 | Length | PPTP Message Type | 679 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 680 | Magic Cookie | 681 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 682 | Control Message Type | Reserved0 | 683 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 684 | Result Code | Error Code | Reserved1 | 685 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 687 Length Total length in octets of this PPTP 688 message, including the entire PPTP 689 header. 691 PTPP Message Type 1 for Control Message. 693 Magic Cookie 0x1A2B3C4D. 695 Control Message Type 4 for Stop-Control-Connection-Reply. 697 Reserved0 This field MUST be 0. 699 Result Code Indicates the result of the attempt to 700 close the control connection. Current 701 valid Result Code values are: 703 1 (OK) - Control connection closed 705 2 (General Error) - Control connection 706 not closed for reason indicated in 707 Error Code 709 Error Code This field is set to 0 unless a "General 710 Error" exists, in which case Result Code 711 is set to 2 and this field is set to the 712 value corresponding to the general error 713 condition as specified in Section 2.16. 715 Reserved1 This field MUST be 0. 717 2.5 Echo-Request 719 The Echo-Request is a PPTP control message sent by either peer of a 720 PAC-PNS control connection. This control message is used as a "keep- 721 Alive" for the control connection. The receiving peer issues an 722 Echo-Reply to each Echo-Request received. As specified in Section 3, 723 if the sender does not receive an Echo Reply in response to an Echo- 724 Request, it will eventually clear the control connection. 726 0 1 2 3 727 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 728 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 729 | Length | PPTP Message Type | 730 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 731 | Magic Cookie | 732 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 733 | Control Message Type | Reserved0 | 734 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 735 | Identifier | 736 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 738 Length Total length in octets of this PPTP 739 message, including the entire PPTP 740 header. 742 PTPP Message Type 1 for Control Message. 744 Magic Cookie 0x1A2B3C4D. 746 Control Message Type 5 for Echo-Request. 748 Reserved0 This field MUST be 0. 750 Identifier A value set by the sender of the Echo- 751 Request that is used to match the reply 752 with the corresponding request. 754 2.6 Echo-Reply 756 The Echo-Reply is a PPTP control message sent by either peer of a 757 PAC-PNS control connection in response to the receipt of an Echo- 758 Request. 760 0 1 2 3 761 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 762 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 763 | Length | PPTP Message Type | 764 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 765 | Magic Cookie | 766 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 767 | Control Message Type | Reserved0 | 768 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 769 | Identifier | 770 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 771 | Result Code | Error Code | Reserved1 | 772 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 774 Length Total length in octets of this PPTP 775 message, including the entire PPTP 776 header. 778 PTPP Message Type 1 for Control Message. 780 Magic Cookie 0x1A2B3C4D. 782 Control Message Type 6 for Echo-Reply. 784 Reserved0 This field MUST be 0. 786 Identifier The contents of the identify field from 787 the received Echo-Request is copied to 788 this field. 790 Result Code Indicates the result of the receipt of 791 the Echo-Request. Current valid Result 792 Code values are: 794 1 (OK) - The Echo-Reply is valid 796 2 (General Error) - Echo-Request not 797 accepted for the reason indicated in 798 Error Code 800 Error Code This field is set to 0 unless a "General 801 Error" condition exists, in which case 802 Result Code is set to 2 and this field is 803 set to the value corresponding to the 804 general error condition as specified in 805 Section 2.16. 807 Reserved1 This field MUST be 0. 809 2.7 Outgoing-Call-Request 811 The Outgoing-Call-Request is a PPTP control message sent by the PNS 812 to the PAC to indicate that an outbound call from the PAC is to be 813 established. This request provides the PAC with information required 814 to make the call. It also provides information to the PAC that is 815 used to regulate the transmission of data to the PNS for this session 816 once it is established. 818 0 1 2 3 819 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 820 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 821 | Length | PPTP Message Type | 822 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 823 | Magic Cookie | 824 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 825 | Control Message Type | Reserved0 | 826 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 827 | Call ID | Call Serial Number | 828 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 829 | Minimum BPS | 830 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 831 | Maximum BPS | 832 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 833 | Bearer Type | 834 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 835 | Framing Type | 836 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 837 | Packet Recv. Window Size | Packet Processing Delay | 838 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 839 | Phone Number Length | Reserved1 | 840 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 841 | | 842 + Phone Number (64 octets) + 843 | | 844 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 845 | | 846 + Subaddress (64 octets) + 847 | | 848 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 850 Length Total length in octets of this PPTP 851 message, including the entire PPTP 852 header. 854 PTPP Message Type 1 for Control Message. 856 Magic Cookie 0x1A2B3C4D. 858 Control Message Type 7 for Outgoing-Call-Request. 860 Reserved0 This field MUST be 0. 862 Call ID A unique identifier, unique to a 863 particular PAC-PNS pair assigned by the 864 PNS to this session. It is used to 865 multiplex and demultiplex data sent over 866 the tunnel between the PNS and PAC 867 involved in this session. 869 Call Serial Number An identifier assigned by the PNS to this 870 session for the purpose of identifying 871 this particular session in logged session 872 information. Unlike the Call ID, both 873 the PNS and PAC associate the same Call 874 Serial Number with a given session. The 875 combination of IP address and call serial 876 number SHOULD be unique. 878 Minimum BPS The lowest acceptable line speed (in 879 bits/second) for this session. 881 Maximum BPS The highest acceptable line speed (in 882 bits/second) for this session. 884 Bearer Type A value indicating the bearer capability 885 required for this outgoing call. The 886 currently defined values are: 888 1 - Call to be placed on an analog 889 channel 891 2 - Call to be placed on a digital 892 channel 894 3 - Call can be placed on any type of 895 channel 897 Framing Type A value indicating the type of PPP 898 framing to be used for this outgoing 899 call. 901 1 - Call to use Asynchronous framing 903 2 - Call to use Synchronous framing 904 3 - Call can use either type of 905 framing 907 Packet Recv. Window Size The number of received data packets the 908 PNS will buffer for this session. 910 Packet Processing Delay A measure of the packet processing delay 911 that might be imposed on data sent to the 912 PNS from the PAC. This value is 913 specified in units of 1/10 seconds. For 914 the PNS this number should be very small. 915 See appendix A for a description of how 916 this value is determined and used. 918 Phone Number Length The actual number of valid digits in the 919 Phone Number field. 921 Reserved1 This field MUST be 0. 923 Phone Number The number to be dialed to establish the 924 outgoing session. For ISDN and analog 925 calls this field is an ASCII string. If 926 the Phone Number is less than 64 octets 927 in length, the remainder of this field is 928 filled with octets of value 0. 930 Subaddress A 64 octet field used to specify 931 additional dialing information. If the 932 subaddress is less than 64 octets long, 933 the remainder of this field is filled 934 with octets of value 0. 936 2.8 Outgoing-Call-Reply 938 The Outgoing-Call-Reply is a PPTP control message sent by the PAC to 939 the PNS in response to a received Outgoing-Call-Request message. The 940 reply indicates the result of the outgoing call attempt. It also 941 provides information to the PNS about particular parameters used for 942 the call. It provides information to allow the PNS to regulate the 943 transmission of data to the PAC for this session. 945 0 1 2 3 946 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 947 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 948 | Length | PPTP Message Type | 949 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 950 | Magic Cookie | 951 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 952 | Control Message Type | Reserved0 | 953 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 954 | Call ID | Peer's Call ID | 955 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 956 | Result Code | Error Code | Cause Code | 957 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 958 | Connect Speed | 959 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 960 | Packet Recv. Window Size | Packet Processing Delay | 961 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 962 | Physical Channel ID | 963 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 965 Length Total length in octets of this PPTP 966 message, including the entire PPTP 967 header. 969 PTPP Message Type 1 for Control Message. 971 Magic Cookie 0x1A2B3C4D. 973 Control Message Type 8 for Outgoing-Call-Reply. 975 Reserved0 This field MUST be 0. 977 Call ID A unique identifier for the tunnel, 978 assigned by the PAC to this session. It 979 is used to multiplex and demultiplex data 980 sent over the tunnel between the PNS and 981 PAC involved in this session. 983 Peer's Call ID This field is set to the value received 984 in the Call ID field of the corresponding 985 Outgoing-Call-Request message. It is 986 used by the PNS to match the Outgoing- 987 Call-Reply with the Outgoing-Call-Request 988 it issued. It also is used as the value 989 sent in the GRE header for mux/demuxing. 991 Result Code This value indicates the result of the 992 Outgoing-Call-Request attempt. Currently 993 valid values are: 995 1 (Connected) - Call established with 996 no errors 998 2 (General Error) - Outgoing Call not 999 established for the reason indicated 1000 in Error Code 1002 3 (No Carrier) - Outgoing Call failed 1003 due to no carrier detected 1005 4 (Busy) - Outgoing Call failed due to 1006 detection of a busy signal 1008 5 (No Dial Tone) - Outgoing Call 1009 failed due to lack of a dial tone 1011 6 (Time-out) - Outgoing Call was not 1012 established within time allotted by 1013 PAC 1015 7 (Do Not Accept) - Outgoing Call 1016 administratively prohibited 1018 Error Code This field is set to 0 unless a "General 1019 Error" condition exists, in which case 1020 Result Code is set to 2 and this field is 1021 set to the value corresponding to the 1022 general error condition as specified in 1023 Section 2.16. 1025 Cause Code This field gives additional failure 1026 information. Its value can vary 1027 depending upon the type of call 1028 attempted. For ISDN call attempts it is 1029 the Q.931 cause code. 1031 Connect Speed The actual connection speed used, in 1032 bits/second. 1034 Packet Recv. Window Size The number of received data packets the 1035 PAC will buffer for this session. 1037 Packet Processing Delay A measure of the packet processing delay 1038 that might be imposed on data sent to the 1039 PAC from the PNS. This value is 1040 specified in units of 1/10 seconds. For 1041 the PAC, this number is related to the 1042 size of the buffer used to hold packets 1043 to be sent to the client and to the speed 1044 of the link to the client. This value 1045 should be set to the maximum delay that 1046 can normally occur between the time a 1047 packet arrives at the PAC and is 1048 delivered to the client. See Appendix A 1049 for an example of how this value is 1050 determined and used. 1052 Physical Channel ID This field is set by the PAC in a 1053 vendor-specific manner to the physical 1054 channel number used to place this call. 1055 It is used for logging purposes only. 1057 2.9 Incoming-Call-Request 1059 The Incoming-Call-Request is a PPTP control message sent by the PAC 1060 to the PNS to indicate that an inbound call is to be established from 1061 the PAC. This request provides the PNS with parameter information 1062 for the incoming call. 1064 This message is the first in the "three-way handshake" used by PPTP 1065 for establishing incoming calls. The PAC may defer answering the 1066 call until it has received an Incoming-Call-Reply from the PNS 1067 indicating that the call should be established. This mechanism allows 1068 the PNS to obtain sufficient information about the call before it is 1069 answered to determine whether the call should be answered or not. 1071 0 1 2 3 1072 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 1073 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1074 | Length | PPTP Message Type | 1075 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1076 | Magic Cookie | 1077 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1078 | Control Message Type | Reserved0 | 1079 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1080 | Call ID | Call Serial Number | 1081 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1082 | Call Bearer Type | 1083 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1084 | Physical Channel ID | 1085 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1086 | Dialed Number Length | Dialing Number Length | 1087 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1088 | | 1089 + Dialed Number (64 octets) + 1090 | | 1091 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1092 | | 1093 + Dialing Number (64 octets) + 1094 | | 1095 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1096 | | 1097 + Subaddress (64 octets) + 1098 | | 1099 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1101 Length Total length in octets of this PPTP 1102 message, including the entire PPTP 1103 header. 1105 PTPP Message Type 1 for Control Message. 1107 Magic Cookie 0x1A2B3C4D. 1109 Control Message Type 9 for Incoming-Call-Request. 1111 Reserved0 This field MUST be 0. 1113 Call ID A unique identifier for this tunnel, 1114 assigned by the PAC to this session. It 1115 is used to multiplex and demultiplex data 1116 sent over the tunnel between the PNS and 1117 PAC involved in this session. 1119 Call Serial Number An identifier assigned by the PAC to this 1120 session for the purpose of identifying 1121 this particular session in logged session 1122 information. Unlike the Call ID, both 1123 the PNS and PAC associate the same Call 1124 Serial Number to a given session. The 1125 combination of IP address and call serial 1126 number should be unique. 1128 Bearer Type A value indicating the bearer capability 1129 used for this incoming call. Currently 1130 defined values are: 1132 1 - Call is on an analog channel 1134 2 - Call is on a digital channel 1136 Physical Channel ID This field is set by the PAC in a 1137 vendor-specific manner to the number of 1138 the physical channel this call arrived 1139 on. 1141 Dialed Number Length The actual number of valid digits in the 1142 Dialed Number field. 1144 Dialing Number Length The actual number of valid digits in the 1145 Dialing Number field. 1147 Dialed Number The number that was dialed by the caller. 1148 For ISDN and analog calls this field is 1149 an ASCII string. If the Dialed Number is 1150 less than 64 octets in length, the 1151 remainder of this field is filled with 1152 octets of value 0. 1154 Dialing Number The number from which the call was 1155 placed. For ISDN and analog calls this 1156 field is an ASCII string. If the Dialing 1157 Number is less than 64 octets in length, 1158 the remainder of this field is filled 1159 with octets of value 0. 1161 Subaddress A 64 octet field used to specify 1162 additional dialing information. If the 1163 subaddress is less than 64 octets long, 1164 the remainder of this field is filled 1165 with octets of value 0. 1167 2.10 Incoming-Call-Reply 1169 The Incoming-Call-Reply is a PPTP control message sent by the PNS to 1170 the PAC in response to a received Incoming-Call-Request message. The 1171 reply indicates the result of the incoming call attempt. It also 1172 provides information to allow the PAC to regulate the transmission of 1173 data to the PNS for this session. 1175 This message is the second in the three-way handshake used by PPTP 1176 for establishing incoming calls. It indicates to the PAC whether the 1177 call should be answered or not. 1179 0 1 2 3 1180 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 1181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1182 | Length | PPTP Message Type | 1183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1184 | Magic Cookie | 1185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1186 | Control Message Type | Reserved0 | 1187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1188 | Call ID | Peer's Call ID | 1189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1190 | Result Code | Error Code | Packet Recv. Window Size | 1191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1192 | Packet Transmit Delay | Reserved1 | 1193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1195 Length Total length in octets of this PPTP 1196 message, including the entire PPTP 1197 header. 1199 PTPP Message Type 1 for Control Message. 1201 Magic Cookie 0x1A2B3C4D. 1203 Control Message Type 10 for Incoming-Call-Reply. 1205 Reserved0 This field MUST be 0. 1207 Call ID A unique identifier for this tunnel 1208 assigned by the PAC to this session. It 1209 is used to multiplex and demultiplex data 1210 sent over the tunnel between the PNS and 1211 PAC involved in this session. 1213 Peer's Call ID This field is set to the value received 1214 in the Call ID field of the corresponding 1215 Incoming-Call-Request message. It is used 1216 by the PAC to match the Incoming-Call- 1217 Reply with the Incoming-Call-Request it 1218 issued. This value is included in the GRE 1219 header of transmitted data packets for 1220 this session. 1222 Result Code This value indicates the result of the 1223 Incoming-Call-Request attempt. Current 1224 valid Result Code values are: 1226 1 (Connect) - The PAC should answer 1227 the incoming call 1229 2 (General Error) - The Incoming Call 1230 should not be established due to the 1231 reason indicated in Error Code 1233 3 (Do Not Accept) - The PAC should not 1234 accept the incoming call. It should 1235 hang up or issue a busy indication 1237 Error Code This field is set to 0 unless a "General 1238 Error" condition exists, in which case 1239 Result Code is set to 2 and this field is 1240 set to the value corresponding to the 1241 general error condition as specified in 1242 Section 2.16. 1244 Packet Recv. Window Size The number of received data packets the 1245 PAC will buffer for this session. 1247 Packet Transmit Delay A measure of the packet processing delay 1248 that might be imposed on data sent to the 1249 PAC from the PNS. This value is 1250 specified in units of 1/10 seconds. See 1251 Appendix A for a description of how this 1252 value is determined and used. 1254 Reserved1 This field MUST be 0. 1256 2.11 Incoming-Call-Connected 1258 The Incoming-Call-Connected message is a PPTP control message sent by 1259 the PAC to the PNS in response to a received Incoming-Call-Reply. It 1260 provides information to the PNS about particular parameters used for 1261 the call. It also provides information to allow the PNS to regulate 1262 the transmission of data to the PAC for this session. 1264 This message is the third in the three-way handshake used by PPTP for 1265 establishing incoming calls. It provides a mechanism for providing 1266 the PNS with additional information about the call that cannot, in 1267 general, be obtained at the time the Incoming-Call-Request is issued 1268 by the PAC. 1270 0 1 2 3 1271 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 1272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1273 | Length | PPTP Message Type | 1274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1275 | Magic Cookie | 1276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1277 | Control Message Type | Reserved0 | 1278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1279 | Peer's Call ID | Reserved1 | 1280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1281 | Connect Speed | 1282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1283 | Packet Recv. Window Size | Packet Transmit Delay | 1284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1285 | Framing Type | 1286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1288 Length Total length in octets of this PPTP 1289 message, including the entire PPTP 1290 header. 1292 PTPP Message Type 1 for Control Message. 1294 Magic Cookie 0x1A2B3C4D. 1296 Control Message Type 11 for Incoming-Call-Connected. 1298 Reserved0 This field MUST be 0. 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-Reply message. It is used 1303 by the PNS to match the Incoming-Call- 1304 Connected with the Incoming-Call-Reply it 1305 issued. 1307 Connect Speed The actual connection speed used, in 1308 bits/second. 1310 Packet Recv. Window Size The number of received data packets the 1311 PAC will buffer for this session. 1313 Packet Transmit Delay A measure of the packet processing delay 1314 that might be imposed on data sent to the 1315 PAC from the PNS. This value is 1316 specified in units of 1/10 seconds. See 1317 Appendix A for a description of how this 1318 value is determined and used. 1320 Framing Type A value indicating the type of PPP 1321 framing being used by this incoming call. 1323 1 - Call uses asynchronous framing 1325 2 - Call uses synchronous framing 1327 2.12 Call-Clear-Request 1329 The Call-Clear-Request is a PPTP control message sent by the PNS to 1330 the PAC indicating that a particular call is to be disconnected. The 1331 call being cleared can be either an incoming or outgoing call, in any 1332 state. The PAC responds to this message with a Call-Disconnect- 1333 Notify message. 1335 0 1 2 3 1336 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 1337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1338 | Length | PPTP Message Type | 1339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1340 | Magic Cookie | 1341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1342 | Control Message Type | Reserved0 | 1343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1344 | Call ID | Reserved1 | 1345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1347 Length Total length in octets of this PPTP 1348 message, including the entire PPTP 1349 header. 1351 PTPP Message Type 1 for Control Message. 1353 Magic Cookie 0x1A2B3C4D. 1355 Control Message Type 12 for Call-Clear-Request. 1357 Reserved0 This field MUST be 0. 1359 Call ID The Call ID assigned by the PNS to this 1360 call. This value is used instead of the 1361 Peer's Call ID because the latter may not 1362 be known to the PNS if the call must be 1363 aborted during call establishment. 1365 Reserved1 This field MUST be 0. 1367 2.13 Call-Disconnect-Notify 1369 The Call-Disconnect-Notify message is a PPTP control message sent by 1370 the PAC to the PNS. It is issued whenever a call is disconnected, 1371 due to the receipt by the PAC of a Call-Clear-Request or for any 1372 other reason. Its purpose is to inform the PNS of both the 1373 disconnection and the reason for it. 1375 0 1 2 3 1376 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 1377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1378 | Length | PPTP Message Type | 1379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1380 | Magic Cookie | 1381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1382 | Control Message Type | Reserved0 | 1383 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1384 | Call ID | Result Code | Error Code | 1385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1386 | Cause Code | Reserved1 | 1387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1388 | | 1389 + Call Statistics (128 octets) + 1390 | | 1391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1393 Length Total length in octets of this PPTP 1394 message, including the entire PPTP 1395 header. 1397 PTPP Message Type 1 for Control Message. 1399 Magic Cookie 0x1A2B3C4D. 1401 Control Message Type 13 for Call-Disconnect-Notify. 1403 Reserved0 This field MUST be 0. 1405 Call ID The value of the Call ID assigned by the 1406 PAC to this call. This value is used 1407 instead of the Peer's Call ID because the 1408 latter may not be known to the PNS if the 1409 call must be aborted during call 1410 establishment. 1412 Result Code This value indicates the reason for the 1413 disconnect. Current valid Result Code 1414 values are: 1416 1 (Lost Carrier) - Call disconnected 1417 due to loss of carrier 1419 2 (General Error) - Call disconnected 1420 for the reason indicated in Error 1421 Code 1423 3 (Admin Shutdown) - Call disconnected 1424 for administrative reasons 1426 4 (Request) - Call disconnected due to 1427 received Call-Clear-Request 1429 Error Code This field is set to 0 unless a "General 1430 Error" condition exists, in which case 1431 the Result Code is set to 2 and this 1432 field is set to the value corresponding 1433 to the general error condition as 1434 specified in Section 2.16. 1436 Cause Code This field gives additional disconnect 1437 information. Its value varies depending 1438 on the type of call being disconnected. 1439 For ISDN calls it is the Q.931 cause 1440 code. 1442 Call Statistics This field is an ASCII string containing 1443 vendor-specific call statistics that can 1444 be logged for diagnostic purposes. If 1445 the length of the string is less than 1446 128, the remainder of the field is filled 1447 with octets of value 0. 1449 2.14 WAN-Error-Notify 1451 The WAN-Error-Notify message is a PPTP control message sent by the 1452 PAC to the PNS to indicate WAN error conditions (conditions that 1453 occur on the interface supporting PPP). The counters in this message 1454 are cumulative. This message should only be sent when an error 1455 occurs, and not more than once every 60 seconds. The counters are 1456 reset when a new call is established. 1458 0 1 2 3 1459 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 1460 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1461 | Length | PPTP Message Type | 1462 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1463 | Magic Cookie | 1464 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1465 | Control Message type | Reserved0 | 1466 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1467 | Peer's Call ID | Reserved1 | 1468 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1469 | CRC Errors | 1470 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1471 | Framing Errors | 1472 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1473 | Hardware Overruns | 1474 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1475 | Buffer Overruns | 1476 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1477 | Time-out Errors | 1478 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1479 | Alignment Errors | 1480 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1482 Length Total length in octets of this PPTP 1483 message, including the entire PPTP 1484 header. 1486 PTPP Message Type 1 for Control Message. 1488 Magic Cookie 0x1A2B3C4D. 1490 Control Message Type 14 for WAN-Error-Notify. 1492 Reserved0 This field MUST be 0. 1494 Peer's Call ID Th Call ID assigned by the PNS to this 1495 call. 1497 CRC Errors Number of PPP frames received with CRC 1498 errors since session was established. 1500 Framing Errors Number of improperly framed PPP packets 1501 received. 1503 Hardware Overruns Number of receive buffer over-runs since 1504 session was established. 1506 Buffer Overruns Number of buffer over-runs detected since 1507 session was established. 1509 Time-out Errors Number of time-outs since call was 1510 established. 1512 Alignment Errors Number of alignment errors since call was 1513 established. 1515 2.15 Set-Link-Info 1517 The Set-Link-Info message is a PPTP control message sent by the PNS 1518 to the PAC to set PPP-negotiated options. Because these options can 1519 change at any time during the life of the call, the PAC must be able 1520 to update its internal call information dynamically and perform PPP 1521 negotiation on an active PPP session. 1523 0 1 2 3 1524 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 1525 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1526 | Length | PPTP Message Type | 1527 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1528 | Magic Cookie | 1529 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1530 | Control Message type | Reserved0 | 1531 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1532 | Peer's Call ID | Reserved1 | 1533 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1534 | Send ACCM | 1535 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1536 | Receive ACCM | 1537 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1539 Length Total length in octets of this PPTP 1540 message, including the entire PPTP 1541 header. 1543 PTPP Message Type 1 for Control Message. 1545 Magic Cookie 0x1A2B3C4D. 1547 Control Message Type 15 for Set-Link-Info. 1549 Reserved0 This field MUST be 0. 1551 Peer's Call ID The value of the Call ID assigned by the 1552 PAC to this call. 1554 Reserved1 This field MUST be 0. 1556 Send ACCM The send ACCM value the client should use 1557 to process outgoing PPP packets. The 1558 default value used by the client until 1559 this message is received is 0XFFFFFFFF. 1560 See [7]. 1562 Receive ACCM The receive ACCM value the client should 1563 use to process incoming PPP packets. The 1564 default value used by the client until 1565 this message is received is 0XFFFFFFFF. 1566 See [7]. 1568 2.16 General Error Codes 1570 General error codes pertain to types of errors which are not specific 1571 to any particular PPTP request, but rather to protocol or message 1572 format errors. If a PPTP reply indicates in its Result Code that a 1573 general error occurred, the General Error value should be examined to 1574 determined what the error was. The currently defined General Error 1575 codes and their meanings are: 1577 0 (None) - No general error 1579 1 (Not-Connected) - No control connection exists yet for this 1580 PAC-PNS pair 1582 2 (Bad-Format) - Length is wrong or Magic Cookie value is 1583 incorrect 1585 3 (Bad-Value) - One of the field values was out of range or 1586 reserved field was non-zero 1588 4 (No-Resource) - Insufficient resources to handle this command 1589 now 1591 5 (Bad-Call ID) - The Call ID is invalid in this context 1593 6 (PAC-Error) - A generic vendor-specific error occurred in 1594 the PAC 1596 3.0 Control Connection Protocol Operation 1598 This section describes the operation of various PPTP control 1599 connection functions and the Control Connection messages which are 1600 used to support them. The protocol operation of the control 1601 connection is simplified because TCP is used to provide a reliable 1602 transport mechanism. 1603 Ordering and retransmission of messages is not a concern at this 1604 level. The TCP connection itself, however, can close at any time and 1605 an appropriate error recovery mechanism must be provided to handle 1606 this case. 1608 Some error recovery procedures are common to all states of the 1609 control connection. If an expected reply does not arrive within 60 1610 seconds, the control connection is closed, unless otherwise 1611 specified. Appropriate logging should be implemented for easy 1612 determination of the problems and the reasons for closing the control 1613 connection. 1615 Receipt of an invalid or malformed Control Connection message should 1616 be logged appropriately, and the control connection should be closed 1617 and restarted to ensure recovery into a known state. 1619 3.1 Control Connection States 1621 The control connection relies on a standard TCP connection for its 1622 service. The PPTP control connection protocol is not distinguishable 1623 between the PNS and PAC, but is distinguishable between the 1624 originator and receiver. The originating peer is the one which first 1625 attempts the TCP open. Since either PAC or PNS may originate a 1626 connection, it is possible for a TCP collision to occur. See Section 1627 3.1.3 for a description of this situation. 1629 3.1.1 Control Connection Originator (may be PAC or PNS) 1631 TCP Open Indication 1632 /Send Start Control 1633 Connection Request +-----------------+ 1634 +------------------------------------>| wait_ctl_reply | 1635 | +-----------------+ 1636 | Collision/See (3.1.3) Close TCP V V V Receive Start Ctl 1637 | +-------------------------------+ | | Connection Reply 1638 | | | | Version OK 1639 ^ V | V 1640 +-----------------+ Receive Start Ctl | +-----------------+ 1641 | idle | Connection Reply | | established | 1642 +-----------------+ Version Not OK | +-----------------+ 1643 ^ | V Local Terminate 1644 | Receive Stop Control | | /Send Stop 1645 | Connection Request | | Control Request 1646 | /Send Stop Control Reply V V 1647 | Close TCP +-----------------+ 1648 +-------------------------------------| wait_stop_reply | 1649 +-----------------+ 1651 idle 1653 The control connection originator attempts to open a TCP connection 1654 to the peer during idle state. When the TCP connection is open, the 1655 originator transmits a send Start-Control-Connection-Request and then 1656 enters the wait_ctl_reply state. 1658 wait_ctl_reply 1660 The originator checks to see if another TCP connection has been 1661 requested from the same peer, and if so, handles the collision 1662 situation described in Section 3.1.3. 1664 When a Start-Control-Connection-Reply is received, it is examined for 1665 a compatible version. If the version of the reply is lower than the 1666 version sent in the request, the older (lower) version should be used 1667 provided it is supported. If the version in the reply is earlier and 1668 supported, the originator moves to the established state. If the 1669 version is earlier and not supported, a Stop-Control-Connection- 1670 Request SHOULD be sent to the peer and the originator moves into the 1671 wait_stop_reply state. 1673 established 1675 An established connection may be terminated by either a local 1676 condition or the receipt of a Stop-Control-Connection-Request. In the 1677 event of a local termination, the originator MUST send a Stop- 1678 Control-Connection-Request and enter the wait_stop_reply state. 1680 If the originator receives a Stop-Control-Connection-Request it 1681 SHOULD send a Stop-Control-Connection-Reply and close the TCP 1682 connection making sure that the final TCP information has been 1683 "pushed" properly. 1685 wait_stop_reply 1687 If a Stop-Control-Connection-Reply is received, the TCP connection 1688 SHOULD be closed and the control connection becomes idle. 1690 3.1.2 Control connection Receiver (may be PAC or PNS) 1692 Receive Start Control Connection Request 1693 Version Not OK/Send Start Control Connection 1694 Reply with Error 1695 +--------+ 1696 | | Receive Control Connection Request Version OK 1697 | | /Send Start Control Connection Reply 1698 | | +----------------------------------------+ 1699 ^ V ^ V 1700 +-----------------+ Receive Start Ctl +-----------------+ 1701 | Idle | Connection Request | Established | 1702 +-----------------+ /Send Stop Reply +-----------------+ 1703 ^ ^ Close TCP V V Local Terminate 1704 | +-------------------------------------+ | /Send Stop 1705 | | Control Conn. 1706 | V Request 1707 | +-----------------+ 1708 +-------------------------------------| Wait-Stop-Reply | 1709 Receive Stop Control +-----------------+ 1710 Connection Reply 1711 /Close TCP 1713 idle 1715 The control connection receiver waits for a TCP open attempt on port 1716 5678. When notified of an open TCP connection, it should prepare to 1717 receive PPTP messages. When a Start-Control-Connection-Request is 1718 received its version field should be examined. If the version is 1719 earlier than the receiver's version and the earlier version can be 1720 supported by the receiver, the receiver SHOULD send a Start-Control- 1721 Connection-Reply. If the version is earlier than the receiver's 1722 version and the version cannot be supported, the receiver SHOULD send 1723 a Start- Connection-Reply message, close the TCP connection and 1724 remain in the idle state. If the receiver's version is the same as 1725 earlier than the peer's, the receiver SHOULD send a Start-Control- 1726 Connection-Reply with the receiver's version and enter the 1727 established state. 1729 established 1731 An established connection may be terminated by either a local 1732 condition or the reception of a Stop-Control-Connection-Request. In 1733 the event of a local termination, the originator MUST send a Stop- 1734 Control-Connection-Request and enter the wait_stop_reply state. 1736 If the originator receives a Stop-Control-Connection-Request it 1737 SHOULD send a Stop-Control-Connection-Reply and close the TCP 1738 connection, making sure that the final TCP information has been 1739 "pushed" properly. 1741 wait_stop_reply 1743 If a Stop-Control-Connection-Reply is received, the TCP connection 1744 SHOULD be closed and the control connection becomes idle. 1746 3.1.3 Start Control Connection Initiation Request Collision 1748 A PAC and PNS must have only one control connection between them. It 1749 is possible, however, for a PNS and a PAC to simultaneously attempt 1750 to establish a control connection to each other. When a Start- 1751 Control-Connection-Request is received on one TCP connection and 1752 another Start-Control-Connection-Request has already been sent on 1753 another TCP connection to the same peer, a collision has occurred. 1755 The "winner" of the initiation race is the peer with the higher IP 1756 address (compared as 32 bit unsigned values, network number more 1757 significant). For example, if the peers 192.33.45.17 and 192.33.45.89 1758 collide, the latter will be declared the winner. 1760 The loser will immediately close the TCP connection it initiated, 1761 without sending any further PPTP control messages on it and will 1762 respond to the winner's request with a Start-Control-Connection-Reply 1763 message. The winner will wait for the Start-Control-Connection-Reply 1764 on the connection it initiated and also wait for a TCP termination 1765 indication on the connection the loser opened. The winner MUST NOT 1766 send any messages on the connection the loser initiated. 1768 3.1.3 Keep Alives and Timers 1770 A control connection SHOULD be closed by closing the underlying TCP 1771 connection under the following circumstances: 1773 1. If a control connection is not in the established state (i.e., 1774 Start-Control-Connection-Request and Start-Control-Connection- 1775 Reply have not been exchanged), a control connection SHOULD be 1776 closed after 60 seconds by a peer waiting for a Start-Control- 1777 Connection-Request or Start-Control-Connection-Reply message. 1779 2. If a peer's control connection is in the established state and has 1780 not received a control message for 60 seconds, it SHOULD send a 1781 Echo-Request message. If an Echo-Reply is not received 60 seconds 1782 after the Echo-Request message transmission, the control 1783 connection SHOULD be closed. 1785 3.2 Call States 1787 3.2.1 Timing considerations 1789 Because of the real-time nature of telephone signaling, both the PNS 1790 and PAC should be implemented with multi-threaded architectures such 1791 that messages related to multiple calls are not serialized and 1792 blocked. The transit delay between the PAC and PNS should not exceed 1793 one second. The call and connection state figures do not specify 1794 exceptions caused by timers. The implicit assumption is that since 1795 the TCP-based control connection is being verified with keep-alives, 1796 there is less need to maintain strict timers for call control 1797 messages. 1799 Establishing outbound international calls, including the modem 1800 training and negotiation sequences, may take in excess of 1 minute so 1801 the use of short timers is discouraged. 1803 If a state transition does not occur within 1 minute (except for 1804 connections in the idle or established states), the integrity of the 1805 protocol processing between the peers is suspect and the ENTIRE 1806 CONTROL CONNECTION should be closed and restarted. All Call IDs are 1807 logically released whenever a control connection is started. This 1808 presumably also helps in preventing toll calls from being "lost" and 1809 never cleared. 1811 3.2.2 Call ID values 1813 Each peer assigns a Call ID value to each user session it requests or 1814 accepts. This Call ID value MUST be unique for the tunnel between the 1815 PNS and PAC to which it belongs. Tunnels to other peers can use the 1816 same Call ID number so the receiver of a packet on a tunnel needs to 1817 associate a user session with a particular tunnel and Call ID. It is 1818 suggested that the number of potential Call ID values for each tunnel 1819 be at least twice as large as the maximum number of calls expected on 1820 a given tunnel. 1822 A session is defined by the triple (PAC, PNS, Call ID). 1824 3.2.3 Incoming calls 1826 An Incoming-Call-Request message is generated by the PAC when an 1827 associated telephone line rings. The PAC selects a Call ID and serial 1828 number and indicates the call bearer type. Modems should always 1829 indicate analog call type. ISDN calls should indicate digital when 1830 unrestricted digital service or rate adaption is used and analog if 1831 digital modems are involved. Dialing number, dialed number, and 1832 subaddress may be included in the message if they are available from 1833 the telephone network. 1835 Once the PAC sends the Incoming-Call-Request, it waits for a response 1836 from the PNS but does not answer the call from the telephone network. 1837 The PNS may choose not to accept the call if: 1839 - No resources are available to handle more sessions 1841 - The dialed, dialing, or subaddress fields are not indicative of 1842 an authorized user 1844 - The bearer service is not authorized or supported 1846 If the PNS chooses to accept the call, it responds with an Outgoing- 1847 Call-Reply which also indicates window sizes (see Appendix B). When 1848 the PAC receives the Outgoing-Call-Reply, it attempts to connect the 1849 call, assuming the calling party has not hung up. A final call 1850 connected message from the PAC to the PNS indicates that the call 1851 states for both the PAC and the PNS should enter the established 1852 state. 1854 When the dialed-in client hangs up, the call is cleared normally and 1855 the PAC sends a Call-Disconnect-Notify message. If the PNS wishes to 1856 clear a call, it sends a Call-Clear-Request message and then waits 1857 for a Call-Disconnect-Notify. 1859 3.2.3.1 PAC Incoming Call States 1861 Ring/Send Incoming Call Request +-----------------+ 1862 +----------------------------------------->| wait_reply | 1863 | +-----------------+ 1864 | Receive Incoming Call Reply V V V 1865 | Not Accepting | | | Receive Incoming 1866 | +--------------------------------+ | | Call Reply Accepting 1867 | | +------------------------------+ | /Answer call; Send 1868 | | | Abort/Send Call | Call Connected 1869 ^ V V Disconnect Notify V 1870 +-----------------+ +-----------------+ 1871 | idle |<-----------------------------| established | 1872 +-----------------+ Receive Clear Call Request +-----------------+ 1873 or telco call dropped 1874 or local disconnect 1875 /Send Call Disconnect Notify 1877 The states associated with the PAC for incoming calls are: 1879 idle 1881 The PAC detects an incoming call on one of its telco interfaces. 1882 Typically this means an analog line is ringing or an ISDN TE has 1883 detected an incoming Q.931 SETUP message. The PAC sends an Incoming- 1884 Call-Request message and moves to the wait_reply state. 1886 wait_reply 1888 The PAC receives an Incoming-Call-Reply message indicating non- 1889 willingness to accept the call (general error or don't accept) and 1890 moves back into the idle state. If the reply message indicates that 1891 the call is accepted, the PAC sends an Incoming-Call-Connected 1892 message and enters the established state. 1894 established 1896 Data is exchanged over the tunnel. The call may be cleared following: 1898 An event on the telco connection. The PAC sends a Call- 1899 Disconnect-Notify message 1901 Receipt of a Call-Clear-Request. The PAC sends a Call-Disconnect- 1902 Notify message 1903 A local reason. The PAC sends a Call-Disconnect-Notify message. 1905 3.2.3.2 PNS Incoming Call States 1907 Receive Incoming Call Request 1908 /Send Incoming Call Reply +-----------------+ 1909 Not Accepting if Error | Wait-Connect | 1910 +-----+ +-----------------+ 1911 | | Receive Incoming Call Req. ^ V V 1912 | | /Send Incoming Call Reply OK | | | Receive Incoming 1913 | | +--------------------------------+ | | Call Connect 1914 ^ V ^ V------------------------------+ V 1915 +-----------------+ Receive Call Disconnect +-----------------+ 1916 | Idle | Notify +- | Established | 1917 +-----------------+ | +-----------------+ 1918 ^ ^ | V Local Terminate 1919 | +----------------------------+ | /Send Call Clear 1920 | Receive Call Disconnect | Request 1921 | Notify V 1922 | +-----------------+ 1923 +--------------------------------------| Wait-Disconnect | 1924 Receive Call Disconnect +-----------------+ 1925 Notify 1927 The states associated with the PNS for incoming calls are: 1929 idle 1931 An Incoming-Call-Request message is received. If the request is not 1932 acceptable, an Incoming-Call-Reply is sent back to the PAC and the 1933 PNS remains in the idle state. If the Incoming-Call-Request message 1934 is acceptable, an Incoming-Call-Reply is sent indicating accept in 1935 the result code. The session moves to the wait_connect state. 1937 wait_connect 1939 If the session is connected on the PAC, the PAC sends an incoming 1940 call connect message to the PNS which then moves into established 1941 state. The PAC may send a Call-Disconnect-Notify to indicate that the 1942 incoming caller could not be connected. This could happen, for 1943 example, if a telephone user accidently places a standard voice call 1944 to a PAC resulting in a handshake failure on the called modem. 1946 established 1948 The session is terminated either by receipt of a Call-Disconnect- 1949 Notify message from the PAC or by sending a Call-Clear-Request. Once 1950 a Call-Clear-Request has been sent, the session enters the 1951 wait_disconnect state. 1953 wait_disconnect 1955 Once a Call-Disconnect-Notify is received the session moves back to 1956 the idle state. 1958 3.2.4 Outgoing calls 1960 Outgoing messages are initiated by a PNS and instruct a PAC to place 1961 a call on a telco interface. There are only two messages for outgoing 1962 calls: Outgoing-Call-Request and Outgoing-Call-Reply. The PNS sends 1963 an Outgoing-Call-Request specifying the dialed party phone number and 1964 subaddress as well as speed and window parameters. The PAC MUST 1965 respond to the Outgoing-Call-Request message with an Outgoing-Call- 1966 Reply message once the PAC determines that: 1968 The call has been successfully connected 1970 A call failure has occurred for reasons such as: no interfaces are 1971 available for dial-out, the called party is busy or does not 1972 answer, or no dial tone is detected on the interface chosen for 1973 dialing 1975 3.2.4.1 PAC Outgoing Call States 1977 Receive Outgoing Call Request in Error 1978 /Send Outgoing Call Reply with Error 1979 |--------+ 1980 | | Receive Outgoing Call Request No Error 1981 | | /Off Hook; Dial 1982 | | +----------------------------------------- 1983 ^ V ^ V 1984 +-----------------+ Incomplete Call +-----------------+ 1985 | idle | /Send Outgoing Call | wait_cs_ans | 1986 +-----------------+ Reply with Error +-----------------+ 1987 ^ ^ or Recv. Call Clear Req. V V Telco Answer 1988 | | /Send Disconnect Notify| | /Send Outgoing 1989 | +-------------------------------------+ | Call Reply. 1990 | V 1991 | +-----------------+ 1992 +-------------------------------------| established | 1993 Receive Call Clear Request +-----------------+ 1994 or local terminate 1995 or telco disconnect 1996 /Hangup call and send 1997 Call Disconnect Notify 1999 The states associated with the PAC for outgoing calls are: 2001 idle 2003 Received Outgoing-Call-Request. If this is received in error, respond 2004 with an Outgoing-Call-Reply with error condition set. Otherwise, 2005 allocate physical channel to dial on. Place the outbound call, wait 2006 for a connection, and move to the wait_cs_ans state. 2008 wait_cs_ans 2010 If the call is incomplete, send an Outgoing-Call-Reply with a non- 2011 zero Error Code. If a timer expires on an outbound call, send back an 2012 Outgoing-Call-Reply with a non-zero Error Code. If a circuit switched 2013 connection is established, send an Outgoing-Call-Reply indicating 2014 success. 2016 established 2018 If a Call-Clear-Request is received, the telco call SHOULD be 2019 released via appropriate mechanisms and a Call-Disconnect-Notify 2020 message SHOULD BE sent to the PNS. If the call is disconnected by the 2021 client or by the telco interface, a Call-Disconnect-Notify message 2022 SHOULD be sent to the PNS. 2024 3.2.4.2 PNS Outgoing Call States 2026 Open Indication Abort/Send 2027 /Send Outgoing Call Call Clear 2028 Request +-----------------+ Request 2029 +-------------------------------->| Wait-Reply |------------+ 2030 | +-----------------+ | 2031 | Receive Outgoing Call Reply V V Receive Outgoing | 2032 | with Error | | Call Reply | 2033 | +-------------------------------+ | No Error | 2034 ^ V V | 2035 +-----------------+ +-----------------+ | 2036 | Idle |<-----------------------------| Established | | 2037 +-----------------+ Receive Call Disconnect +-----------------+ | 2038 ^ Notify V Local Terminate | 2039 | | /Send Call Clear | 2040 | | Request | 2041 | Receive Call Disconnect V | 2042 | Notify +-----------------+ | 2043 +---------------------------------| Wait-Disconnect |<-----------+ 2044 +-----------------+ 2046 The states associated with the PNS for outgoing calls are: 2048 idle 2050 An Outgoing-Call-Request message is sent to the PAC and the session 2051 moves into the wait_reply state. 2053 wait_reply 2055 An Outgoing-Call-Reply is received which indicates an error. The 2056 session returns to idle state. No telco call is active. If the 2057 Outgoing-Call-Reply does not indicate an error, the telco call is 2058 connected and the session moves to the established state. 2060 established 2062 If a Call-Disconnect-Notify is received, the telco call has been 2063 terminated for the reason indicated in the Result and Cause Codes. 2064 The session moves back to the idle state. If the PNS chooses to 2065 terminate the session, it sends a Call-Clear-Request to the PAC and 2066 then enters the wait_disconnect state. 2068 wait_disconnect 2070 A session disconnection is waiting to be confirmed by the PAC. Once 2071 the PNS receives the Call-Disconnect-Notify message, the session 2072 enters idle state. 2074 4.0 Tunnel Protocol Operation 2076 The user data carried by the PPTP protocol are PPP data packets. PPP 2077 packets are carried between the PAC and PNS, encapsulated in GRE 2078 packets which in turn are carried over IP. The encapsulated PPP 2079 packets are essentially PPP data packets less any media specific 2080 framing elements. No HDLC flags, bit insertion, control characters, 2081 or control character escapes are included. No CRCs are sent through 2082 the tunnel. The IP packets transmitted over the tunnels between a PAC 2083 and PNS has the following general structure: 2085 +--------------------------------+ 2086 | Media Header | 2087 +--------------------------------+ 2088 | IP Header | 2089 +--------------------------------+ 2090 | GRE Header | 2091 +--------------------------------+ 2092 | PPP Packet | 2093 +--------------------------------+ 2095 4.1 Enhanced GRE header 2097 The GRE header used in PPTP is enhanced slightly from that specified 2098 in the current GRE protocol specification [1,2]. The main difference 2099 involves the definition of a new Acknowledgment Number field, used to 2100 determine if a particular GRE packet or set of packets has arrived at 2101 the remote end of the tunnel. This Acknowledgment capability is not 2102 used in conjunction with any retransmission of user data packets. It 2103 is used instead to determine the rate at which user data packets are 2104 to be transmitted over the tunnel for a given user session. 2106 The format of the enhanced GRE header is as follows: 2108 0 1 2 3 2109 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 2110 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2111 |C|R|K|S|s|Recur|A| Flags | Ver | Protocol Type | 2112 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2113 | Key (HW) Payload Length | Key (LW) Call ID | 2114 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2115 | Sequence Number (Optional) | 2116 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2117 | Acknowledgment Number (Optional) | 2118 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2120 C (Bit 0) Checksum Present. Set to zero 2121 (0). 2123 R (Bit 1) Routing Present. Set to zero 2124 (0). 2126 K (Bit 2) Key Present. Set to one (1). 2128 S (Bit 3) Sequence Number Present. Set to 2129 one (1) if a payload (data) packet is 2130 present. Set to zero (0) if payload is 2131 not present (GRE packet is an 2132 Acknowledgment only). 2134 s (Bit 4) Strict source route present. Set 2135 to zero (0). 2137 Recur (Bits 5-7) Recursion control. Set to 2138 zero (0). 2140 A (Bit 8) Acknowledgment sequence number 2141 present. Set to one (1) if packet 2142 contains Acknowledgment Number to be used 2143 for acknowledging previously transmitted 2144 data. 2146 Flags (Bits 9-12) Must be set to zero (0). 2148 Ver (Bits 13-15) Must contain 1 (enhanced 2149 GRE). 2151 Protocol Type Contains the protocol ID for PPTP [6]. 2153 Key Use of the Key field is up to the 2154 implementation. 2155 PPTP uses it as follows: 2157 Payload Length 2158 (High 2 octets of Key) Size of the 2159 payload, not including the GRE header 2161 Call ID 2162 (Low 2 octets) Contains the Peer's 2163 Call ID for the session to which this 2164 packet belongs. 2166 Sequence Number Contains the sequence number of the 2167 payload. Present if S bit (Bit 3) is one 2168 (1). 2170 Acknowledgment Number Contains the sequence number of the 2171 highest numbered GRE packet received by 2172 the sending peer for this user session. 2173 Present if A bit (Bit 8) is one (1). 2175 The payload section contains a PPP data packet without any media 2176 specific framing elements. 2178 The sequence numbers involved are per packet sequence numbers. The 2179 sequence number for each user session is set to zero at session 2180 startup. Each packet sent for a given user session which contains a 2181 payload (and has the S bit (Bit 3) set to one) is assigned the next 2182 consecutive sequence number for that session. 2184 This protocol allows acknowledgments to be carried with the data and 2185 makes the overall protocol more efficient, which in turn requires 2186 less buffering of packets. 2188 4.2 Sliding Window Protocol 2190 The sliding window protocol used on the PPTP data path is used for 2191 flow control by each side of the data exchange. The enhanced GRE 2192 protocol allows packet acknowledgments to be piggybacked on data 2193 packets. Acknowledgments can also be sent separately from data 2194 packets. Again, the main purpose of the sliding window protocol is 2195 for flow control--retransmissions are not performed by the tunnel 2196 peers. 2198 4.3 Multi Packet Acknowledgment 2200 One feature of the PPTP sliding window protocol is that it allows the 2201 acknowledgment of multiple packets with a single acknowledgment. All 2202 outstanding packets with a sequence number lower or equal to the 2203 acknowledgment number are considered acknowledged. Time-out 2204 calculations are performed using the time the packet corresponding to 2205 the highest sequence number being acknowledged was transmitted. 2207 Adaptive time-out calculations are only performed when an 2208 Acknowledgment is received. When multi-packet acknowledgments are 2209 used, the overhead of the adaptive time-out algorithm is reduced. The 2210 PAC is not required to transmit multi-packet acknowledgments; it can 2211 instead acknowledge each packet individually as it is delivered to 2212 the PPP client. 2214 4.4 Out-of-Sequence Packets 2216 Occasionally packets lose their sequencing across a complicated 2217 internetwork. Say, for example that a PNS sends packets 0 to 5 to a 2218 PAC. Because of rerouting in the internetwork, packet 4 arrives at 2219 the PAC before packet 3. The PAC acknowledges packet 4, and may 2220 assume packet 3 is lost. This acknowledgment grants window credit 2221 beyond packet 4. 2223 When the PAC does receive packet 3, it MUST not attempt to transmit 2224 it to the corresponding PPP client. To do so could cause problems, 2225 as proper PPP protocol operation is premised upon receiving packets 2226 in sequence. PPP does properly deal with the loss of packets, but 2227 not with reordering so out of sequence packets between the PNS and 2228 PAC MUST be silently discarded, or they may be reordered by the 2229 receiver. When packet 5 comes in, it is acknowledged by the PAC 2230 since it has a higher sequence number than 4, which was the last 2231 highest packet acknowledged by the PAC. Packets with duplicate 2232 sequence numbers should never occur since the PAC and PNS never 2233 retransmit GRE packets. A robust implementation will silently 2234 discard duplicate GRE packets, should it receive any. 2236 5.0 Security Considerations 2238 Security issues are not addressed in this document. End to end 2239 security is addressed by PPP. Further security considerations will be 2240 addressed by the next version of PPTP. 2242 6.0 Authors' Addresses 2244 Kory Hamzeh 2245 Ascend Communications 2246 1275 Harbor Bay Parkway 2247 Alameda, CA 94502 2248 Email: kory@ascend.com 2250 Gurdeep Singh Pall 2251 Microsoft Corporation 2252 Redmond, WA 2253 Email: gurdeep@microsoft.com 2255 William Verthein 2256 U.S. Robotics 2258 Jeff Taarud 2259 3COM Corporation 2261 W. Andrew Little 2262 ECI Telematics 2264 7.0 References 2266 [1] Hanks, S. Li, T., Farinacci, D. Traina, P., "Generic Routing 2267 Encapsulation (GRE)", RFC 1701, October 1994. 2269 [2] Hanks, S. Li, T., Farinacci, D. Traina, P., "Generic Routing 2270 Encapsulation (GRE) over IPv4 Networks", RFC 1702, October 1994. 2272 [3] Lloyd, B. Simpson, W., "PPP Authentication Protocols", RFC 1334, 2273 October 1992. 2275 [4] Postel, J. B., "Transmission Control Protocol", RFC 791, 2276 September 1981 2278 [5] Postel, J. B., "User Data Protocol", RFC 768, August 1980. 2280 [6] Reynolds, J., Postel, J., "Assigned Numbers", RFC 1700, October, 2281 1994. 2283 [7] Simpson, W., editor, "The Point-to-Point Protocol (PPP)", RFC 2284 1661, July 1994. 2286 Appendix A. Acknowledgment Time-Outs 2288 PPTP uses sliding windows and time-outs to provide both user session 2289 flow-control across the internetwork and to perform efficient data 2290 buffering to keep the PAC-PNS data channels full without causing 2291 receive buffer overflow. PPTP requires that a time-out be used to 2292 recover from dropped data or acknowledgment packets. The exact 2293 implementation of the time-out is vendor-specific. It is suggested 2294 that an adaptive time-out be implemented with backoff for congestion 2295 control. The time-out mechanism proposed here has the following 2296 properties: 2298 Independent time-outs for each session. A device (PAC or PNS) will 2299 have to maintain and calculate time-outs for every active session. 2301 An administrator-adjustable maximum time-out, MaxTimeOut, unique 2302 to each device. 2304 An adaptive time-out mechanism that compensates for changing 2305 throughput. To reduce packet processing overhead, vendors may 2306 choose not to recompute the adaptive time-out for every received 2307 acknowledgment. The result of this overhead reduction is that the 2308 time-out will not respond as quickly to rapid network changes. 2310 Timer backoff on time-out to reduce congestion. The backed-off 2311 timer value is limited by the configurable maximum time-out value. 2312 Timer backoff is done every time an acknowledgment time-out 2313 occurs. 2315 In general, this mechanism has the desirable behavior of quickly 2316 backing off upon a time-out and of slowly decreasing the time-out 2317 value as packets are delivered without time-outs. 2319 Some definitions: 2321 Packet Processing Delay (PPD) is the amount of time required for 2322 each side to process the maximum amount of data buffered in their 2323 receive packet sliding window. The PPD is the value exchanged 2324 between the PAC and PNS when a call is established. For the PNS, 2325 this number should be small. For a PAC making modem connections, 2326 this number could be significant. 2328 Sample is the actual amount of time incurred receiving an 2329 acknowledgment for a packet. The Sample is measured, not 2330 calculated. 2332 Round-Trip Time (RTT) is the estimated round-trip time for an 2333 Acknowledgment to be received for a given transmitted packet. When 2334 the network link is a local network, this delay will be minimal 2335 (if not zero). When the network link is the Internet, this delay 2336 could be substantial and vary widely. RTT is adaptive: it will 2337 adjust to include the PPD and whatever shifting network delays 2338 contribute to the time between a packet being transmitted and 2339 receiving its acknowledgment. 2341 Adaptive Time-Out (ATO) is the time that must elapse before an 2342 acknowledgment is considered lost. After a time-out, the sliding 2343 window is partially closed and the ATO is backed off. 2345 Packet Processing Delay (PPD) 2347 The PPD parameter is a 16-bit word exchanged during the Call Control 2348 phase that represents tenths of a second (64 means 6.4 seconds). The 2349 protocol only specifies that the parameter is exchanged, it does not 2350 specify how it is calculated. The way values for PPD are calculated 2351 is implementation-dependent and need not be variable (static time- 2352 outs are allowed). The PPD must be exchanged in the call connect 2353 sequences, even if it remains constant in an implementation. One 2354 possible way to calculate the PPD is: 2356 PPD' = ((PPP_MAX_DATA_MTU - Header) * WindowSize * 8) / ConnectRate 2357 PPD = PPD' + PACFudge 2359 Header is the total size of the IP and GRE headers, which is 36. The 2360 MTU is the overall MTU for the internetwork link between the PAC and 2361 PNS. WindowSize represents the number of packets in the sliding 2362 window, and is implementation-dependent. The latency of the 2363 internetwork could be used to pick a window size sufficient to keep 2364 the current session's pipe full. The constant 8 converts octets to 2365 bits (assuming ConnectRate is in bits per second). If ConnectRate is 2366 in bytes per second, omit the 8. PACFudge is not required but can be 2367 used to take overall processing overhead of the PAC into account. 2369 The value of PPD is used to seed the adaptive algorithm with the 2370 initial RTT[n-1] value. 2372 Sample 2374 Sample is the actual measured time for a returned acknowledgment. 2376 Round-Trip Time (RTT) 2378 The RTT value represents an estimate of the average time it takes for 2379 an acknowledgment to be received after a packet is sent to the remote 2380 end of the tunnel. 2382 A.1 Calculating Adaptive Acknowledgment Time-Out 2384 We still must decide how much time to allow for acknowledgments to 2385 return. If the time-out is set too high, we may wait an unnecessarily 2386 long time for dropped packets. If the time-out is too short, we may 2387 time out just before the acknowledgment arrives. The acknowledgment 2388 time-out should also be reasonable and responsive to changing network 2389 conditions. 2391 The suggested adaptive algorithm detailed below is based on the TCP 2392 1989 implementation and is explained in Richard Steven's book TCP/IP 2393 Illustrated, Volume 1 (page 300). 'n' means this iteration of the 2394 calculation, and 'n-1' refers to values from the last calculation. 2396 DIFF[n] = SAMPLE[n] - RTT[n-1] 2397 DEV[n] = DEV[n-1] + (beta * (|DIFF[n]| - DEV[n-1])) 2398 RTT[n] = RTT[n-1] + (alpha * DIFF[n]) 2399 ATO[n] = MIN (RTT[n] + (chi * DEV[n]), MaxTimeOut) 2401 DIFF represents the error between the last estimated round-trip 2402 time and the measured time. DIFF is calculated on each iteration. 2404 DEV is the estimated mean deviation. This approximates the 2405 standard deviation. DEV is calculated on each iteration and 2406 stored for use in the next iteration. Initially, it is set to 0. 2408 RTT is the estimated round-trip time of an average packet. RTT is 2409 calculated on each iteration and stored for use in the next 2410 iteration. Initially, it is set to PPD. 2412 ATO is the adaptive time-out for the next transmitted packet. ATO 2413 is calculated on each iteration. Its value is limited, by the MIN 2414 function, to be a maximum of the configured MaxTimeOut value. 2416 Alpha is the gain for the average and is typically 1/8 (0.125). 2418 Beta is the gain for the deviation and is typically 1/4 (0.250). 2420 Chi is the gain for the time-out and is typically set to 4. 2422 To eliminate division operations for fractional gain elements, the 2423 entire set of equations can be scaled. With the suggested gain 2424 constants, they should be scaled by 8 to eliminate all division. To 2425 simplify calculations, all gain values are kept to powers of two so 2426 that shift operations can be used in place of multiplication or 2427 division. 2429 A.2 Congestion Control: Adjusting for Time-Out 2431 This section describes how the calculation of ATO is modified in the 2432 case where a time-out does occur. When a time-out occurs, the time- 2433 out value should be adjusted rapidly upward. Although the GRE 2434 packets are not retransmitted when a time-out occurs, the time-out 2435 should be adjusted up toward a maximum limit. To compensate for 2436 shifting internetwork time delays, a strategy must be employed to 2437 increase the time-out when it expires. A simple formula called 2438 Karn's Algorithm is used in TCP implementations and may be used in 2439 implementing the backoff timers for the PNS or the PAC. Notice that 2440 in addition to increasing the time-out, we are also shrinking the 2441 size of the window as described in the next section. 2443 Karn's timer backoff algorithm, as used in TCP, is: 2445 NewTIMEOUT = delta * TIMEOUT 2447 Adapted to our time-out calculations, for an interval in which a 2448 time-out occurs, the new ATO is calculated as: 2450 RTT[n] = delta * RTT[n-1] 2451 DEV[n] = DEV[n-1] 2452 ATO[n] = MIN (RTT[n] + (chi * DEV[n]), MaxTimeOut) 2454 In this modified calculation of ATO, only the two values that 2455 contribute to ATO and that are stored for the next iteration are 2456 calculated. RTT is scaled by chi, and DEV is unmodified. DIFF is not 2457 carried forward and is not used in this scenario. A value of 2 for 2458 Delta, the time-out gain factor for RTT, is suggested. 2460 Appendix B. Acknowledgment Time-Out and Window Adjustment 2462 B.1 Initial Window Size 2464 Although each side has indicated the maximum size of its receive 2465 window, it is recommended that a slow start method be used to begin 2466 transmitting data. The initial window size on the transmitter is set 2467 to half the maximum size the receiver requested, with a minimum size 2468 of one packet. The transmitter stops sending packets when the number 2469 of packets awaiting acknowledgment is equal to the current window 2470 size. As the receiver successfully digests each window, the window 2471 size on the transmitter is bumped up by one packet until the maximum 2472 is reached. This method prevents a system from flooding an already 2473 congested network because no history has been established. 2475 B.2 Closing the Window 2477 When a time-out does occur on a packet, the sender adjusts the size 2478 of the transmit window down to one half its value when it failed. 2479 Fractions are rounded up, and the minimum window size is one. 2481 B.3 Opening the Window 2483 With every successful transmission of a window's worth of packets 2484 without a time-out, the transmit window size is increased by one 2485 packet until it reaches the maximum window size that was sent by the 2486 other side when the call was connected. As stated earlier, no 2487 retransmission is done on a time-out. After a time-out, the 2488 transmission resumes with the window starting at one half the size of 2489 the transmit window when the time-out occurred and adjusting upward 2490 by one each time the transmit window is filled with packets that are 2491 all acknowledged without time-outs. 2493 B.4 Window Overflow 2495 When a receiver's window overflows with too many incoming packets, 2496 excess packets are thrown away. This situation should not arise if 2497 the sliding window procedures are being properly followed by the 2498 transmitter and receiver. It is assumed that, on the transmit side, 2499 packets are buffered for transmission and are no longer accepted from 2500 the packet source when the transmit buffer fills.