idnits 2.17.1 draft-ietf-pppext-pptp-05.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 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** The document is more than 15 pages and seems to lack a Table of Contents. 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 396 instances of weird spacing in the document. Is it really formatted ragged-right, rather than justified? ** There are 42 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, or t...' RFC 2119 keyword, line 283: '... MUST NOT This phrase mea...' RFC 2119 keyword, line 286: '... SHOULD This word, or t...' RFC 2119 keyword, line 294: '... MAY This word, or t...' RFC 2119 keyword, line 297: '...nclude this option MUST be prepared to...' (57 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 20 has weird spacing: '...This document...' == Line 21 has weird spacing: '...as, and its...' == Line 26 has weird spacing: '...and may be ...' == Line 27 has weird spacing: '...ference mater...' == Line 30 has weird spacing: '...To learn the...' == (391 more instances...) == 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 implemen-tation 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 (October 1998) is 9324 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: '5' is defined on line 2249, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1334 (ref. '3') (Obsoleted by RFC 1994) ** Obsolete normative reference: RFC 793 (ref. '4') (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 1700 (ref. '6') (Obsoleted by RFC 3232) ** Obsolete normative reference: RFC 2284 (ref. '10') (Obsoleted by RFC 3748) Summary: 16 errors (**), 0 flaws (~~), 9 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group K. Hamzeh 3 Internet-Draft Ascend Communications 4 Category: Informational G. S. Pall 5 Microsoft Corporation 6 W. Verthein 7 3Com 8 J. Taarud 9 Copper Mountain Networks 10 W. A. Little 11 ECI Telematics 12 G. Zorn 13 Microsoft Corporation 14 October 1998 16 Point-to-Point Tunneling Protocol (PPTP) 18 Status of this Memo 20 This document is an Internet-Draft. Internet-Drafts are working docu- 21 ments of the Internet Engineering Task Force (IETF), its areas, and its 22 working groups. Note that other groups may also distribute working doc- 23 uments as Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference material 28 or to cite them other than as ``work in progress''. 30 To learn the current status of any Internet-Draft, please check the 31 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 32 Directories on ftp.ietf.org (US East Coast), nic.nordu.net (Europe), 33 ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). 35 This memo provides information for the Internet community. This memo 36 does not specify an Internet standard of any kind. The distribution of 37 this memo is unlimited. It is filed as 38 and expires April 15, 1999. Please send comments to the PPP Extensions 39 Working Group mailing list (ietf-ppp@merit.edu). 41 Abstract 43 This document specifies a protocol which allows the Point to Point 44 Protocol (PPP) to be tunneled through an IP network. PPTP does not 45 specify any changes to the PPP protocol but rather describes a new 46 vehicle for carrying PPP. A client-server architecture is defined in 47 order to decouple functions which exist in current Network Access 48 Servers (NAS) and support Virtual Private Networks (VPNs). The PPTP 49 Network Server (PNS) is envisioned to run on a general purpose 50 operating system while the client, referred to as a PPTP Access Con- 51 centrator (PAC) operates on a dial access platform. PPTP specifies a 52 call-control and management protocol which allows the server to con- 53 trol access for dial-in circuit switched calls originating from a 54 PSTN or ISDN or to initiate outbound circuit-switched connections. 55 PPTP uses an enhanced GRE (Generic Routing Encapsulation) mechanism 56 to provide a flow- and congestion-controlled encapsulated datagram 57 service for carrying PPP packets. 59 1. Introduction 61 PPTP allows existing Network Access Server (NAS) functions to be sepa- 62 rated using a client-server architecture. Traditionally, the following 63 functions are implemented by a NAS: 65 1) Physical native interfacing to PSTN or ISDN and control of 66 external modems or terminal adapters. 68 A NAS may interface directly to a telco analog or digital circuit 69 or attach via an external modem or terminal adapter. Control of a 70 circuit-switched connection is accomplished with either modem 71 control or DSS1 ISDN call control protocols. 73 The NAS, in conjunction with the modem or terminal adapters, may 74 perform rate adaption, analog to digital conversion, sync to async 75 conversion or a number of other alterations of data streams. 77 2) Logical termination of a Point-to-Point-Protocol (PPP) Link 78 Control Protocol (LCP) session. 80 3) Participation in PPP authentication protocols [3,9,10]. 82 4) Channel aggregation and bundle management for PPP Multilink 83 Protocol. 85 5) Logical termination of various PPP network control protocols 86 (NCP). 88 6) Multiprotocol routing and bridging between NAS interfaces. 90 PPTP divides these functions between the PAC and PNS. The PAC is respon- 91 sible for functions 1, 2, and possibly 3. The PNS may be responsible for 92 function 3 and is responsible for functions 4, 5, and 6. The protocol 93 used to carry PPP protocol data units (PDUs) between the PAC and PNS, as 94 well as call control and management is addressed by PPTP. 96 The decoupling of NAS functions offers these benefits: 98 Flexible IP address management. Dial-in users may maintain a single 99 IP address as they dial into different PACs as long as they are 100 served from a common PNS. If an enterprise network uses unregistered 101 addresses, a PNS associated with the enterprise assigns addresses 102 meaningful to the private network. 104 Support of non-IP protocols for dial networks behind IP networks. 105 This allows Appletalk and IPX, for example to be tunneled through an 106 IP-only provider. The PAC need not be capable of processing these 107 protocols. 109 A solution to the "multilink hunt-group splitting" problem. Multi- 110 link PPP, typically used to aggregate ISDN B channels, requires that 111 all of the channels composing a multilink bundle be grouped at a sin- 112 gle NAS. Since a multilink PPP bundle can be handled by a single PNS, 113 the channels comprising the bundle may be spread across multiple 114 PACs. 116 1.1. Protocol Goals and Assumptions 118 The PPTP protocol is implemented only by the PAC and PNS. No other sys- 119 tems need to be aware of PPTP. Dial networks may be connected to a PAC 120 without being aware of PPTP. Standard PPP client software should con- 121 tinue to operate on tunneled PPP links. 123 PPTP can also be used to tunnel a PPP session over an IP network. In 124 this configuration the PPTP tunnel and the PPP session runs between the 125 same two machines with the caller acting as a PNS. 127 It is envisioned that there will be a many-to-many relationship between 128 PACs and PNSs. A PAC may provide service to many PNSs. For example, an 129 Internet service provider may choose to support PPTP for a number of 130 private network clients and create VPNs for them. Each private network 131 may operate one or more PNSs. A single PNS may associate with many PACs 132 to concentrate traffic from a large number of geographically diverse 133 sites. 135 PPTP uses an extended version of GRE to carry user PPP packets. These 136 enhancements allow for low-level congestion and flow control to be pro- 137 vided on the tunnels used to carry user data between PAC and PNS. This 138 mechanism allows for efficient use of the bandwidth available for the 139 tunnels and avoids unnecessary retransmisions and buffer overruns. PPTP 140 does not dictate the particular algorithms to be used for this low level 141 control but it does define the parameters that must be communicated in 142 order to allow such algorithms to work. Suggested algorithms are 143 included in Appendix A. 145 1.2. Terminology 147 Analog Channel 149 A circuit-switched communication path which is intended to carry 150 3.1 Khz audio in each direction. 152 Digital Channel 154 A circuit-switched communication path which is intended to carry 155 digital information in each direction. 157 Call 159 A connection or attempted connection between two terminal end- 160 points on a PSTN or ISDN -- for example, a telephone call between 161 two modems. 163 Control Connection 165 A control connection is created for each PAC, PNS pair and oper- 166 ates over TCP [4]. The control connection governs aspects of the 167 tunnel and of sessions assigned to the tunnel. 169 Dial User 171 An end-system or router attached to an on-demand PSTN or ISDN 172 which is either the initiator or recipient of a call. 174 Network Access Server (NAS) 176 A device providing temporary, on-demand network access to users. 177 This access is point-to-point using PSTN or ISDN lines. 179 PPTP Access Concentrator (PAC) 181 A device attached to one or more PSTN or ISDN lines capable of PPP 182 operation and of handling the PPTP protocol. The PAC need only 183 implement TCP/IP to pass traffic to one or more PNSs. It may also 184 tunnel non-IP protocols. 186 PPTP Network Server (PNS) 188 A PNS is envisioned to operate on general-purpose computing/server 189 platforms. The PNS handles the server side of the PPTP protocol. 190 Since PPTP relies completely on TCP/IP and is independent of the 191 interface hardware, the PNS may use any combination of IP inter- 192 face hardware including LAN and WAN devices. 194 Session 196 PPTP is connection-oriented. The PNS and PAC maintain state for 197 each user that is attached to a PAC. A session is created when 198 end-to-end PPP connection is attempted between a dial user and the 199 PNS. The datagrams related to a session are sent over the tunnel 200 between the PAC and PNS. 202 Tunnel 204 A tunnel is defined by a PNS-PAC pair. The tunnel protocol is 205 defined by a modified version of GRE [1,2]. The tunnel carries 206 PPP datagrams between the PAC and the PNS. Many sessions are mul- 207 tiplexed on a single tunnel. A control connection operating over 208 TCP controls the establishment, release, and maintenance of ses- 209 sions and of the tunnel itself. 211 1.3. Protocol Overview 213 There are two parallel components of PPTP: 1) a Control Connection 214 between each PAC-PNS pair operating over TCP and 2) an IP tunnel operat- 215 ing between the same PAC-PNS pair which is used to transport GRE encap- 216 sulated PPP packets for user sessions between the pair. 218 1.3.1. Control Connection Overview 220 Before PPP tunneling can occur between a PAC and PNS, a control connec- 221 tion must be established between them. The control connection is a stan- 222 dard TCP session over which PPTP call control and management information 223 is passed. The control session is logically associated with, but sepa- 224 rate from, the sessions being tunneled through a PPTP tunnel. For each 225 PAC-PNS pair both a tunnel and a control connection exist. The control 226 connection is responsible for establishment, management, and release of 227 sessions carried through the tunnel. It is the means by which a PNS is 228 notified of an incoming call at an associated PAC, as well as the means 229 by which a PAC is instructed to place an outgoing dial call. 231 A control connection can be established by either the PNS or the PAC. 232 Following the establishment of the required TCP connection, the PNS and 233 PAC establish the control connection using the Start-Control- Connec- 234 tion-Request and -Reply messages. These messages are also used to 235 exchange information about basic operating capabilities of the PAC and 236 PNS. Once the control connection is established, the PAC or PNS may 237 initiate sessions by requesting outbound calls or responding to inbound 238 requests. The control connection may communicate changes in operating 239 characteristics of an individual user session with a Set- Link-Info 240 message. Individual sessions may be released by either the PAC or PNS, 241 also through Control Connection messages. 243 The control connection itself is maintained by keep-alive echo messages. 244 This ensures that a connectivity failure between the PNS and the PAC can 245 be detected in a timely manner. Other failures can be reported via the 246 Wan-Error-Notify message, also on the control connection. 248 It is intended that the control connection will also carry management 249 related messages in the future, such as a message allowing the PNS to 250 request the status of a given PAC; these message types have not yet been 251 defined. 253 1.3.2. Tunnel Protocol Overview 255 PPTP requires the establishment of a tunnel for each communicating PNS- 256 PAC pair. This tunnel is used to carry all user session PPP packets for 257 sessions involving a given PNS-PAC pair. A key which is present in the 258 GRE header indicates which session a particular PPP packet belongs to. 259 In this manner, PPP packets are multiplexed and demultiplexed over a 260 single tunnel between a given PNS-PAC pair. The value to use in the key 261 field is established by the call establishment procedure which takes 262 place on the control connection. 264 The GRE header also contains acknowledgment and sequencing information 265 that is used to perform some level of congestion-control and error 266 detection over the tunnel. Again the control connection is used to 267 determine rate and buffering parameters that are used to regulate the 268 flow of PPP packets for a particular session over the tunnel. PPTP does 269 not specify the particular algorithms to use for congestion-control and 270 flow-control. Suggested algorithms for the determination of adaptive 271 time-outs to recover from dropped data or acknowledgments on the tunnel 272 are included in Appendix A of this document. 274 1.4. Specification Language 276 In this document, several words are used to signify the requirements of 277 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 connec- 312 tion between a PNS and a given PAC. The TCP session for the control 313 connection is established by initiating a TCP connection to port 1723 314 [6]. The source port is assigned to any unused port number. 316 Each PPTP Control Connection message begins with an 8 octet fixed header 317 portion. This fixed header contains the following: the total length of 318 the message, the PPTP Message Type indicator, and a "Magic Cookie". 320 Two Control Connection message types are indicated by the PPTP Message 321 Type field: 323 1 - Control Message 324 2 - Management Message 326 Management messages are currently not defined. 328 The Magic Cookie is always sent as the constant 0x1A2B3C4D. Its basic 329 purpose is to allow the receiver to ensure that it is properly synchro- 330 nized with the TCP data stream. It should not be used as a means for 331 resynchronizing the TCP data stream in the event that a transmitter 332 issues an improperly formatted message. Loss of synchronization must 333 result in immediate closing of the control connection's TCP session. 335 For clarity, all Control Connection message templates in the next sec- 336 tion include the entire PPTP Control Connection message header. Numbers 337 preceded by 0x are hexadecimal values. 339 The currently defined Control Messages, grouped by function, are: 341 Control Message Message Code 343 (Control Connection Management) 345 Start-Control-Connection-Request 1 346 Start-Control-Connection-Reply 2 347 Stop-Control-Connection-Request 3 348 Stop-Control-Connection-Reply 4 349 Echo-Request 5 350 Echo-Reply 6 352 (Call Management) 354 Outgoing-Call-Request 7 355 Outgoing-Call-Reply 8 356 Incoming-Call-Request 9 357 Incoming-Call-Reply 10 358 Incoming-Call-Connected 11 359 Call-Clear-Request 12 360 Call-Disconnect-Notify 13 362 (Error Reporting) 364 WAN-Error-Notify 14 366 (PPP Session Control) 368 Set-Link-Info 15 370 The Start-Control-Connection-Request and -Reply messages determine which 371 version of the Control Connection protocol will be used. The version 372 number field carried in these messages consists of a version number in 373 the high octet and a revision number in the low octet. Version handling 374 is described in Section 3. The current value of the version number field 375 is 0x0100 for version 1, revision 0. 377 The use of the GRE-like header for the encapsulation of PPP user packets 378 is specified in Section 4. 380 The MTU for the user data packets encapsulated in GRE is 1532 octets, 381 not including the IP and GRE headers. 383 2. Control Connection Protocol Specification 385 Control Connection messages are used to establish and clear user ses- 386 sions. The first set of Control Connection messages are used to main- 387 tain the control connection itself. The control connection is initiated 388 by either the PNS or PAC after they establish the underlying TCP connec- 389 tion. The procedure and configuration information required to determine 390 which TCP connections are established is not covered by this protocol. 392 The following Control Connection messages are all sent as user data on 393 the established TCP connection between a given PNS-PAC pair. Note that 394 care has been taken to ensure that all word (2 octet) and longword (4 395 octet) values begin on appropriate boundaries. All data is sent in net- 396 work order (high order octets first). Any "reserved" fields MUST be 397 sent as 0 values to allow for protocol extensibility. 399 2.1. Start-Control-Connection-Request 401 The Start-Control-Connection-Request is a PPTP control message used to 402 establish the control connection between a PNS and a PAC. Each PNS-PAC 403 pair requires a dedicated control connection to be established. A con- 404 trol connection must be established before any other PPTP messages can 405 be issued. The establishment of the control connection can be initiated 406 by either the PNS or PAC. A procedure which handles the occurrence of a 407 collision between PNS and PAC Start-Control-Connection-Requests is 408 described in Section 3. 410 0 1 2 3 411 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 412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 413 | Length | PPTP Message Type | 414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 415 | Magic Cookie | 416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 417 | Control Message Type | Reserved0 | 418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 419 | Protocol Version | Reserved1 | 420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 421 | Framing Capabilities | 422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 423 | Bearer Capabilities | 424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 425 | Maximum Channels | Firmware Revision | 426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 427 | | 428 + Host Name (64 octets) + 429 | | 430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 431 | | 432 + Vendor String (64 octets) + 433 | | 434 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 436 Length Total length in octets of this PPTP 437 message, including the entire PPTP 438 header. 440 PPTP Message Type 1 for Control Message. 442 Magic Cookie 0x1A2B3C4D. This constant value is used 443 as a sanity check on received messages 444 (see Section 1.5). 446 Control Message Type 1 for Start-Control-Connection-Request. 448 Reserved0 This field MUST be 0. 450 Protocol Version The version of the PPTP protocol that the 451 sender wishes to use. 453 Reserved1 This field MUST be 0. 455 Framing Capabilities A set of bits indicating the type of 456 framing that the sender of this message 457 can provide. The currently defined bit 458 settings are: 460 1 - Asynchronous Framing supported 462 2 - Synchronous Framing supported 464 Bearer Capabilities A set of bits indicating the bearer 465 capabilities that the sender of this 466 message can provide. The currently 467 defined bit settings are: 469 1 - Analog access supported 471 2 - Digital access supported 473 Maximum Channels The total number of individual PPP 474 sessions this PAC can support. In 475 Start-Control-Connection-Requests issued 476 by the PNS, this value SHOULD be set to 477 0. It MUST be ignored by the PAC. 479 Firmware Revision This field contains the firmware revision 480 number of the issuing PAC, when issued by 481 the PAC, or the version of the PNS PPTP 482 driver if issued by the PNS. 484 Host Name A 64 octet field containing the DNS name 485 of the issuing PAC or PNS. If less than 486 64 octets in length, the remainder of 487 this field SHOULD be filled with octets 488 of value 0. 490 Vendor Name A 64 octet field containing a vendor 491 specific string describing the type of 492 PAC being used, or the type of PNS 493 software being used if this request is 494 issued by the PNS. If less than 64 495 octets in length, the remainder of this 496 field SHOULD be filled with octets of 497 value 0. 499 2.2. Start-Control-Connection-Reply 501 The Start-Control-Connection-Reply is a PPTP control message sent in 502 reply to a received Start-Control-Connection-Request message. This mes- 503 sage contains a result code indicating the result of the control connec- 504 tion establishment attempt. 506 0 1 2 3 507 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 508 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 509 | Length | PPTP Message Type | 510 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 511 | Magic Cookie | 512 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 513 | Control Message Type | Reserved0 | 514 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 515 | Protocol Version | Result Code | Error Code | 516 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 517 | Framing Capability | 518 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 519 | Bearer Capability | 520 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 521 | Maximum Channels | Firmware Revision | 522 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 523 | | 524 + Host Name (64 octets) + 525 | | 526 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 527 | | 528 + Vendor String (64 octets) + 529 | | 530 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 532 Length Total length in octets of this PPTP 533 message, including the entire PPTP 534 header. 536 PPTP Message Type 1 for Control Message. 538 Magic Cookie 0x1A2B3C4D. 540 Control Message Type 2 for Start-Control-Connection-Reply. 542 Reserved0 This field MUST be 0. 544 Protocol Version The version of the PPTP protocol that the 545 sender wishes to use. 547 Result Code Indicates the result of the command 548 channel establishment attempt. Current 549 valid Result Code values are: 551 1 - Successful channel establishment 553 2 - General error -- Error Code 554 indicates the problem 556 3 - Command channel already exists; 558 4 - Requester is not authorized to 559 establish a command channel 561 5 - The protocol version of the 562 requester is not supported 564 Error Code This field is set to 0 unless a "General 565 Error" exists, in which case Result Code 566 is set to 2 and this field is set to the 567 value corresponding to the general error 568 condition as specified in Section 2.16. 570 Framing Capabilities A set of bits indicating the type of 571 framing that the sender of this message 572 can provide. The currently defined bit 573 settings are: 575 1 - Asynchronous Framing supported 577 2 - Synchronous Framing supported. 579 Bearer Capabilities A set of bits indicating the bearer 580 capabilities that the sender of this 581 message can provide. The currently 582 defined bit settings are: 584 1 - Analog access supported 586 2 - Digital access supported 588 Maximum Channels The total number of individual PPP 589 sessions this PAC can support. In a 590 Start-Control-Connection-Reply issued by 591 the PNS, this value SHOULD be set to 0 592 and it must be ignored by the PAC. The 593 PNS MUST NOT use this value to try to 594 track the remaining number of PPP 595 sessions that the PAC will allow. 597 Firmware Revision This field contains the firmware revision 598 number of the issuing PAC, or the version 599 of the PNS PPTP driver if issued by the 600 PNS. 602 Host Name A 64 octet field containing the DNS name 603 of the issuing PAC or PNS. If less than 604 64 octets in length, the remainder of 605 this field SHOULD be filled with octets 606 of value 0. 608 Vendor Name A 64 octet field containing a vendor 609 specific string describing the type of 610 PAC being used, or the type of PNS 611 software being used if this request is 612 issued by the PNS. If less than 64 613 octets in length, the remainder of this 614 field SHOULD be filled with octets of 615 value 0. 617 2.3. Stop-Control-Connection-Request 619 The Stop-Control-Connection-Request is a PPTP control message sent by 620 one peer of a PAC-PNS control connection to inform the other peer that 621 the control connection should be closed. In addition to closing the 622 control connection, all active user calls are implicitly cleared. The 623 reason for issuing this request is indicated in the Reason field. 625 0 1 2 3 626 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 627 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 628 | Length | PPTP Message Type | 629 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 630 | Magic Cookie | 631 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 632 | Control Message Type | Reserved0 | 633 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 634 | Reason | Reserved1 | Reserved2 | 635 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 637 Length Total length in octets of this PPTP 638 message, including the entire PPTP 639 header. 641 PPTP Message Type 1 for Control Message. 643 Magic Cookie 0x1A2B3C4D. 645 Control Message Type 3 for Stop-Control-Connection-Request. 647 Reserved0 This field MUST be 0. 649 Reason Indicates the reason for the control 650 connection being closed. Current valid 651 Reason values are: 653 1 (None) - General request to clear 654 control connection 656 2 (Stop-Protocol) - Can't support 657 peer's version of the protocol 659 3 (Stop-Local-Shutdown) - Requester is 660 being shut down 662 Reserved1, Reserved2 These fields MUST be 0. 664 2.4. Stop-Control-Connection-Reply 666 The Stop-Control-Connection-Reply is a PPTP control message sent by one 667 peer of a PAC-PNS control connection upon receipt of a Stop- Control- 668 Connection-Request from the other peer. 670 0 1 2 3 671 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 672 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 673 | Length | PPTP Message Type | 674 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 675 | Magic Cookie | 676 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 677 | Control Message Type | Reserved0 | 678 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 679 | Result Code | Error Code | Reserved1 | 680 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 682 Length Total length in octets of this PPTP 683 message, including the entire PPTP 684 header. 686 PPTP Message Type 1 for Control Message. 688 Magic Cookie 0x1A2B3C4D. 690 Control Message Type 4 for Stop-Control-Connection-Reply. 692 Reserved0 This field MUST be 0. 694 Result Code Indicates the result of the attempt to 695 close the control connection. Current 696 valid Result Code values are: 698 1 (OK) - Control connection closed 700 2 (General Error) - Control connection 701 not closed for reason indicated in 702 Error Code 704 Error Code This field is set to 0 unless a "General 705 Error" exists, in which case Result Code 706 is set to 2 and this field is set to the 707 value corresponding to the general error 708 condition as specified in Section 2.16. 710 Reserved1 This field MUST be 0. 712 2.5. Echo-Request 714 The Echo-Request is a PPTP control message sent by either peer of a PAC- 715 PNS control connection. This control message is used as a "keep- Alive" 716 for the control connection. The receiving peer issues an Echo-Reply to 717 each Echo-Request received. As specified in Section 3, if the sender 718 does not receive an Echo Reply in response to an Echo- Request, it will 719 eventually clear the control connection. 721 0 1 2 3 722 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 723 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 724 | Length | PPTP Message Type | 725 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 726 | Magic Cookie | 727 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 728 | Control Message Type | Reserved0 | 729 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 730 | Identifier | 731 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 733 Length Total length in octets of this PPTP 734 message, including the entire PPTP 735 header. 737 PPTP Message Type 1 for Control Message. 739 Magic Cookie 0x1A2B3C4D. 741 Control Message Type 5 for Echo-Request. 743 Reserved0 This field MUST be 0. 745 Identifier A value set by the sender of the Echo- 746 Request that is used to match the reply 747 with the corresponding request. 749 2.6. Echo-Reply 751 The Echo-Reply is a PPTP control message sent by either peer of a PAC- 752 PNS control connection in response to the receipt of an Echo- Request. 754 0 1 2 3 755 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 756 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 757 | Length | PPTP Message Type | 758 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 759 | Magic Cookie | 760 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 761 | Control Message Type | Reserved0 | 762 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 763 | Identifier | 764 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 765 | Result Code | Error Code | Reserved1 | 766 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 768 Length Total length in octets of this PPTP 769 message, including the entire PPTP 770 header. 772 PPTP Message Type 1 for Control Message. 774 Magic Cookie 0x1A2B3C4D. 776 Control Message Type 6 for Echo-Reply. 778 Reserved0 This field MUST be 0. 780 Identifier The contents of the identify field from 781 the received Echo-Request is copied to 782 this field. 784 Result Code Indicates the result of the receipt of 785 the Echo-Request. Current valid Result 786 Code values are: 788 1 (OK) - The Echo-Reply is valid 790 2 (General Error) - Echo-Request not 791 accepted for the reason indicated in 792 Error Code 794 Error Code This field is set to 0 unless a "General 795 Error" condition exists, in which case 796 Result Code is set to 2 and this field is 797 set to the value corresponding to the 798 general error condition as specified in 799 Section 2.16. 801 Reserved1 This field MUST be 0. 803 2.7. Outgoing-Call-Request 805 The Outgoing-Call-Request is a PPTP control message sent by the PNS to 806 the PAC to indicate that an outbound call from the PAC is to be estab- 807 lished. This request provides the PAC with information required to make 808 the call. It also provides information to the PAC that is used to regu- 809 late the transmission of data to the PNS for this session once it is 810 established. 812 0 1 2 3 813 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 814 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 815 | Length | PPTP Message Type | 816 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 817 | Magic Cookie | 818 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 819 | Control Message Type | Reserved0 | 820 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 821 | Call ID | Call Serial Number | 822 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 823 | Minimum BPS | 824 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 825 | Maximum BPS | 826 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 827 | Bearer Type | 828 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 829 | Framing Type | 830 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 831 | Packet Recv. Window Size | Packet Processing Delay | 832 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 833 | Phone Number Length | Reserved1 | 834 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 835 | | 836 + Phone Number (64 octets) + 837 | | 838 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 839 | | 840 + Subaddress (64 octets) + 841 | | 842 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 844 Length Total length in octets of this PPTP 845 message, including the entire PPTP 846 header. 848 PPTP Message Type 1 for Control Message. 850 Magic Cookie 0x1A2B3C4D. 852 Control Message Type 7 for Outgoing-Call-Request. 854 Reserved0 This field MUST be 0. 856 Call ID A unique identifier, unique to a 857 particular PAC-PNS pair assigned by the 858 PNS to this session. It is used to 859 multiplex and demultiplex data sent over 860 the tunnel between the PNS and PAC 861 involved in this session. 863 Call Serial Number An identifier assigned by the PNS to this 864 session for the purpose of identifying 865 this particular session in logged session 866 information. Unlike the Call ID, both 867 the PNS and PAC associate the same Call 868 Serial Number with a given session. The 869 combination of IP address and call serial 870 number SHOULD be unique. 872 Minimum BPS The lowest acceptable line speed (in 873 bits/second) for this session. 875 Maximum BPS The highest acceptable line speed (in 876 bits/second) for this session. 878 Bearer Type A value indicating the bearer capability 879 required for this outgoing call. The 880 currently defined values are: 882 1 - Call to be placed on an analog 883 channel 885 2 - Call to be placed on a digital 886 channel 888 3 - Call can be placed on any type of 889 channel 891 Framing Type A value indicating the type of PPP 892 framing to be used for this outgoing 893 call. 895 1 - Call to use Asynchronous framing 897 2 - Call to use Synchronous framing 898 3 - Call can use either type of 899 framing 901 Packet Recv. Window Size The number of received data packets the 902 PNS will buffer for this session. 904 Packet Processing Delay A measure of the packet processing delay 905 that might be imposed on data sent to the 906 PNS from the PAC. This value is 907 specified in units of 1/10 seconds. For 908 the PNS this number should be very small. 909 See appendix A for a description of how 910 this value is determined and used. 912 Phone Number Length The actual number of valid digits in the 913 Phone Number field. 915 Reserved1 This field MUST be 0. 917 Phone Number The number to be dialed to establish the 918 outgoing session. For ISDN and analog 919 calls this field is an ASCII string. If 920 the Phone Number is less than 64 octets 921 in length, the remainder of this field is 922 filled with octets of value 0. 924 Subaddress A 64 octet field used to specify 925 additional dialing information. If the 926 subaddress is less than 64 octets long, 927 the remainder of this field is filled 928 with octets of value 0. 930 2.8. Outgoing-Call-Reply 932 The Outgoing-Call-Reply is a PPTP control message sent by the PAC to the 933 PNS in response to a received Outgoing-Call-Request message. The reply 934 indicates the result of the outgoing call attempt. It also provides 935 information to the PNS about particular parameters used for the call. 936 It provides information to allow the PNS to regulate the transmission of 937 data to the PAC for this session. 939 0 1 2 3 940 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 941 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 942 | Length | PPTP Message Type | 943 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 944 | Magic Cookie | 945 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 946 | Control Message Type | Reserved0 | 947 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 948 | Call ID | Peer's Call ID | 949 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 950 | Result Code | Error Code | Cause Code | 951 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 952 | Connect Speed | 953 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 954 | Packet Recv. Window Size | Packet Processing Delay | 955 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 956 | Physical Channel ID | 957 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 959 Length Total length in octets of this PPTP 960 message, including the entire PPTP 961 header. 963 PPTP Message Type 1 for Control Message. 965 Magic Cookie 0x1A2B3C4D. 967 Control Message Type 8 for Outgoing-Call-Reply. 969 Reserved0 This field MUST be 0. 971 Call ID A unique identifier for the tunnel, 972 assigned by the PAC to this session. It 973 is used to multiplex and demultiplex data 974 sent over the tunnel between the PNS and 975 PAC involved in this session. 977 Peer's Call ID This field is set to the value received 978 in the Call ID field of the corresponding 979 Outgoing-Call-Request message. It is 980 used by the PNS to match the Outgoing- 981 Call-Reply with the Outgoing-Call-Request 982 it issued. It also is used as the value 983 sent in the GRE header for mux/demuxing. 985 Result Code This value indicates the result of the 986 Outgoing-Call-Request attempt. Currently 987 valid values are: 989 1 (Connected) - Call established with 990 no errors 992 2 (General Error) - Outgoing Call not 993 established for the reason indicated 994 in Error Code 996 3 (No Carrier) - Outgoing Call failed 997 due to no carrier detected 999 4 (Busy) - Outgoing Call failed due to 1000 detection of a busy signal 1002 5 (No Dial Tone) - Outgoing Call 1003 failed due to lack of a dial tone 1005 6 (Time-out) - Outgoing Call was not 1006 established within time allotted by 1007 PAC 1009 7 (Do Not Accept) - Outgoing Call 1010 administratively prohibited 1012 Error Code This field is set to 0 unless a "General 1013 Error" condition exists, in which case 1014 Result Code is set to 2 and this field is 1015 set to the value corresponding to the 1016 general error condition as specified in 1017 Section 2.16. 1019 Cause Code This field gives additional failure 1020 information. Its value can vary 1021 depending upon the type of call 1022 attempted. For ISDN call attempts it is 1023 the Q.931 cause code. 1025 Connect Speed The actual connection speed used, in 1026 bits/second. 1028 Packet Recv. Window Size The number of received data packets the 1029 PAC will buffer for this session. 1031 Packet Processing Delay A measure of the packet processing delay 1032 that might be imposed on data sent to the 1033 PAC from the PNS. This value is 1034 specified in units of 1/10 seconds. For 1035 the PAC, this number is related to the 1036 size of the buffer used to hold packets 1037 to be sent to the client and to the speed 1038 of the link to the client. This value 1039 should be set to the maximum delay that 1040 can normally occur between the time a 1041 packet arrives at the PAC and is 1042 delivered to the client. See Appendix A 1043 for an example of how this value is 1044 determined and used. 1046 Physical Channel ID This field is set by the PAC in a 1047 vendor-specific manner to the physical 1048 channel number used to place this call. 1049 It is used for logging purposes only. 1051 2.9. Incoming-Call-Request 1053 The Incoming-Call-Request is a PPTP control message sent by the PAC to 1054 the PNS to indicate that an inbound call is to be established from the 1055 PAC. This request provides the PNS with parameter information for the 1056 incoming call. 1058 This message is the first in the "three-way handshake" used by PPTP for 1059 establishing incoming calls. The PAC may defer answering the call until 1060 it has received an Incoming-Call-Reply from the PNS indicating that the 1061 call should be established. This mechanism allows the PNS to obtain suf- 1062 ficient information about the call before it is answered to determine 1063 whether the call should be answered or not. 1065 0 1 2 3 1066 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 1067 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1068 | Length | PPTP Message Type | 1069 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1070 | Magic Cookie | 1071 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1072 | Control Message Type | Reserved0 | 1073 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1074 | Call ID | Call Serial Number | 1075 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1076 | Call Bearer Type | 1077 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1078 | Physical Channel ID | 1079 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1080 | Dialed Number Length | Dialing Number Length | 1081 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1082 | | 1083 + Dialed Number (64 octets) + 1084 | | 1085 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1086 | | 1087 + Dialing Number (64 octets) + 1088 | 1089 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1090 | | 1091 + Subaddress (64 octets) + 1092 | | 1093 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1095 Length Total length in octets of this PPTP 1096 message, including the entire PPTP 1097 header. 1099 PPTP Message Type 1 for Control Message. 1101 Magic Cookie 0x1A2B3C4D. 1103 Control Message Type 9 for Incoming-Call-Request. 1105 Reserved0 This field MUST be 0. 1107 Call ID A unique identifier for this tunnel, 1108 assigned by the PAC to this session. It 1109 is used to multiplex and demultiplex data 1110 sent over the tunnel between the PNS and 1111 PAC involved in this session. 1113 Call Serial Number An identifier assigned by the PAC to this 1114 session for the purpose of identifying 1115 this particular session in logged session 1116 information. Unlike the Call ID, both 1117 the PNS and PAC associate the same Call 1118 Serial Number to a given session. The 1119 combination of IP address and call serial 1120 number should be unique. 1122 Bearer Type A value indicating the bearer capability 1123 used for this incoming call. Currently 1124 defined values are: 1126 1 - Call is on an analog channel 1128 2 - Call is on a digital channel 1130 Physical Channel ID This field is set by the PAC in a 1131 vendor-specific manner to the number of 1132 the physical channel this call arrived 1133 on. 1135 Dialed Number Length The actual number of valid digits in the 1136 Dialed Number field. 1138 Dialing Number Length The actual number of valid digits in the 1139 Dialing Number field. 1141 Dialed Number The number that was dialed by the caller. 1142 For ISDN and analog calls this field is 1143 an ASCII string. If the Dialed Number is 1144 less than 64 octets in length, the 1145 remainder of this field is filled with 1146 octets of value 0. 1148 Dialing Number The number from which the call was 1149 placed. For ISDN and analog calls this 1150 field is an ASCII string. If the Dialing 1151 Number is less than 64 octets in length, 1152 the remainder of this field is filled 1153 with octets of value 0. 1155 Subaddress A 64 octet field used to specify 1156 additional dialing information. If the 1157 subaddress is less than 64 octets long, 1158 the remainder of this field is filled 1159 with octets of value 0. 1161 2.10. Incoming-Call-Reply 1163 The Incoming-Call-Reply is a PPTP control message sent by the PNS to the 1164 PAC in response to a received Incoming-Call-Request message. The reply 1165 indicates the result of the incoming call attempt. It also provides 1166 information to allow the PAC to regulate the transmission of data to the 1167 PNS for this session. 1169 This message is the second in the three-way handshake used by PPTP for 1170 establishing incoming calls. It indicates to the PAC whether the call 1171 should be answered or not. 1173 0 1 2 3 1174 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 1175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1176 | Length | PPTP Message Type | 1177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1178 | Magic Cookie | 1179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1180 | Control Message Type | Reserved0 | 1181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1182 | Call ID | Peer's Call ID | 1183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1184 | Result Code | Error Code | Packet Recv. Window Size | 1185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1186 | Packet Transmit Delay | Reserved1 | 1187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1189 Length Total length in octets of this PPTP 1190 message, including the entire PPTP 1191 header. 1193 PPTP Message Type 1 for Control Message. 1195 Magic Cookie 0x1A2B3C4D. 1197 Control Message Type 10 for Incoming-Call-Reply. 1199 Reserved0 This field MUST be 0. 1201 Call ID A unique identifier for this tunnel 1202 assigned by the PNS to this session. It 1203 is used to multiplex and demultiplex data 1204 sent over the tunnel between the PNS and 1205 PAC involved in this session. 1207 Peer's Call ID This field is set to the value received 1208 in the Call ID field of the corresponding 1209 Incoming-Call-Request message. It is used 1210 by the PAC to match the Incoming-Call- 1211 Reply with the Incoming-Call-Request it 1212 issued. This value is included in the GRE 1213 header of transmitted data packets for 1214 this session. 1216 Result Code This value indicates the result of the 1217 Incoming-Call-Request attempt. Current 1218 valid Result Code values are: 1220 1 (Connect) - The PAC should answer 1221 the incoming call 1223 2 (General Error) - The Incoming Call 1224 should not be established due to the 1225 reason indicated in Error Code 1227 3 (Do Not Accept) - The PAC should not 1228 accept the incoming call. It should 1229 hang up or issue a busy indication 1231 Error Code This field is set to 0 unless a "General 1232 Error" condition exists, in which case 1233 Result Code is set to 2 and this field is 1234 set to the value corresponding to the 1235 general error condition as specified in 1236 Section 2.16. 1238 Packet Recv. Window Size The number of received data packets the 1239 PAC will buffer for this session. 1241 Packet Transmit Delay A measure of the packet processing delay 1242 that might be imposed on data sent to the 1243 PAC from the PNS. This value is 1244 specified in units of 1/10 seconds. See 1245 Appendix A for a description of how this 1246 value is determined and used. 1248 Reserved1 This field MUST be 0. 1250 2.11. Incoming-Call-Connected 1252 The Incoming-Call-Connected message is a PPTP control message sent by 1253 the PAC to the PNS in response to a received Incoming-Call-Reply. It 1254 provides information to the PNS about particular parameters used for the 1255 call. It also provides information to allow the PNS to regulate the 1256 transmission of data to the PAC for this session. 1258 This message is the third in the three-way handshake used by PPTP for 1259 establishing incoming calls. It provides a mechanism for providing the 1260 PNS with additional information about the call that cannot, in general, 1261 be obtained at the time the Incoming-Call-Request is issued by the PAC. 1263 0 1 2 3 1264 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 1265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1266 | Length | PPTP Message Type | 1267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1268 | Magic Cookie | 1269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1270 | Control Message Type | Reserved0 | 1271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1272 | Peer's Call ID | Reserved1 | 1273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1274 | Connect Speed | 1275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1276 | Packet Recv. Window Size | Packet Transmit Delay | 1277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1278 | Framing Type | 1279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1281 Length Total length in octets of this PPTP 1282 message, including the entire PPTP 1283 header. 1285 PPTP Message Type 1 for Control Message. 1287 Magic Cookie 0x1A2B3C4D. 1289 Control Message Type 11 for Incoming-Call-Connected. 1291 Reserved0 This field MUST be 0. 1293 Peer's Call ID This field is set to the value received 1294 in the Call ID field of the corresponding 1295 Incoming-Call-Reply message. It is used 1296 by the PNS to match the Incoming-Call- 1297 Connected with the Incoming-Call-Reply it 1298 issued. 1300 Connect Speed The actual connection speed used, in 1301 bits/second. 1303 Packet Recv. Window Size The number of received data packets the 1304 PAC will buffer for this session. 1306 Packet Transmit Delay A measure of the packet processing delay 1307 that might be imposed on data sent to the 1308 PAC from the PNS. This value is 1309 specified in units of 1/10 seconds. See 1310 Appendix A for a description of how this 1311 value is determined and used. 1313 Framing Type A value indicating the type of PPP 1314 framing being used by this incoming call. 1316 1 - Call uses asynchronous framing 1318 2 - Call uses synchronous framing 1320 2.12. Call-Clear-Request 1322 The Call-Clear-Request is a PPTP control message sent by the PNS to the 1323 PAC indicating that a particular call is to be disconnected. The call 1324 being cleared can be either an incoming or outgoing call, in any state. 1325 The PAC responds to this message with a Call-Disconnect- Notify message. 1327 0 1 2 3 1328 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 1329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1330 | Length | PPTP Message Type | 1331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1332 | Magic Cookie | 1333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1334 | Control Message Type | Reserved0 | 1335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1336 | Call ID | Reserved1 | 1337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1339 Length Total length in octets of this PPTP 1340 message, including the entire PPTP 1341 header. 1343 PPTP Message Type 1 for Control Message. 1345 Magic Cookie 0x1A2B3C4D. 1347 Control Message Type 12 for Call-Clear-Request. 1349 Reserved0 This field MUST be 0. 1351 Call ID The Call ID assigned by the PNS to this 1352 call. This value is used instead of the 1353 Peer's Call ID because the latter may not 1354 be known to the PNS if the call must be 1355 aborted during call establishment. 1357 Reserved1 This field MUST be 0. 1359 2.13. Call-Disconnect-Notify 1361 The Call-Disconnect-Notify message is a PPTP control message sent by the 1362 PAC to the PNS. It is issued whenever a call is disconnected, due to 1363 the receipt by the PAC of a Call-Clear-Request or for any other reason. 1364 Its purpose is to inform the PNS of both the disconnection and the rea- 1365 son for it. 1367 0 1 2 3 1368 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 1369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1370 | Length | PPTP Message Type | 1371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1372 | Magic Cookie | 1373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1374 | Control Message Type | Reserved0 | 1375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1376 | Call ID | Result Code | Error Code | 1377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1378 | Cause Code | Reserved1 | 1379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1380 | | 1381 + Call Statistics (128 octets) + 1382 | | 1383 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1385 Length Total length in octets of this PPTP 1386 message, including the entire PPTP 1387 header. 1389 PPTP Message Type 1 for Control Message. 1391 Magic Cookie 0x1A2B3C4D. 1393 Control Message Type 13 for Call-Disconnect-Notify. 1395 Reserved0 This field MUST be 0. 1397 Call ID The value of the Call ID assigned by the 1398 PAC to this call. This value is used 1399 instead of the Peer's Call ID because the 1400 latter may not be known to the PNS if the 1401 call must be aborted during call 1402 establishment. 1404 Result Code This value indicates the reason for the 1405 disconnect. Current valid Result Code 1406 values are: 1408 1 (Lost Carrier) - Call disconnected 1409 due to loss of carrier 1411 2 (General Error) - Call disconnected 1412 for the reason indicated in Error 1413 Code 1415 3 (Admin Shutdown) - Call disconnected 1416 for administrative reasons 1418 4 (Request) - Call disconnected due to 1419 received Call-Clear-Request 1421 Error Code This field is set to 0 unless a "General 1422 Error" condition exists, in which case 1423 the Result Code is set to 2 and this 1424 field is set to the value corresponding 1425 to the general error condition as 1426 specified in Section 2.16. 1428 Cause Code This field gives additional disconnect 1429 information. Its value varies depending 1430 on the type of call being disconnected. 1431 For ISDN calls it is the Q.931 cause 1432 code. 1434 Call Statistics This field is an ASCII string containing 1435 vendor-specific call statistics that can 1436 be logged for diagnostic purposes. If 1437 the length of the string is less than 1438 128, the remainder of the field is filled 1439 with octets of value 0. 1441 2.14. WAN-Error-Notify 1443 The WAN-Error-Notify message is a PPTP control message sent by the PAC 1444 to the PNS to indicate WAN error conditions (conditions that occur on 1445 the interface supporting PPP). The counters in this message are cumula- 1446 tive. This message should only be sent when an error occurs, and not 1447 more than once every 60 seconds. The counters are reset when a new call 1448 is established. 1450 0 1 2 3 1451 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 1452 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1453 | Length | PPTP Message Type | 1454 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1455 | Magic Cookie | 1456 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1457 | Control Message type | Reserved0 | 1458 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1459 | Peer's Call ID | Reserved1 | 1460 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1461 | CRC Errors | 1462 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1463 | Framing Errors | 1464 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1465 | Hardware Overruns | 1466 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1467 | Buffer Overruns | 1468 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1469 | Time-out Errors | 1470 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1471 | Alignment Errors | 1472 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1474 Length Total length in octets of this PPTP 1475 message, including the entire PPTP 1476 header. 1478 PPTP Message Type 1 for Control Message. 1480 Magic Cookie 0x1A2B3C4D. 1482 Control Message Type 14 for WAN-Error-Notify. 1484 Reserved0 This field MUST be 0. 1486 Peer's Call ID Th Call ID assigned by the PNS to this 1487 call. 1489 CRC Errors Number of PPP frames received with CRC 1490 errors since session was established. 1492 Framing Errors Number of improperly framed PPP packets 1493 received. 1495 Hardware Overruns Number of receive buffer over-runs since 1496 session was established. 1498 Buffer Overruns Number of buffer over-runs detected since 1499 session was established. 1501 Time-out Errors Number of time-outs since call was 1502 established. 1504 Alignment Errors Number of alignment errors since call was 1505 established. 1507 2.15. Set-Link-Info 1509 The Set-Link-Info message is a PPTP control message sent by the PNS to 1510 the PAC to set PPP-negotiated options. Because these options can change 1511 at any time during the life of the call, the PAC must be able to update 1512 its internal call information dynamically and perform PPP negotiation on 1513 an active PPP session. 1515 0 1 2 3 1516 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 1517 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1518 | Length | PPTP Message Type | 1519 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1520 | Magic Cookie | 1521 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1522 | Control Message type | Reserved0 | 1523 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1524 | Peer's Call ID | Reserved1 | 1525 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1526 | Send ACCM | 1527 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1528 | Receive ACCM | 1529 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1531 Length Total length in octets of this PPTP 1532 message, including the entire PPTP 1533 header. 1535 PPTP Message Type 1 for Control Message. 1537 Magic Cookie 0x1A2B3C4D. 1539 Control Message Type 15 for Set-Link-Info. 1541 Reserved0 This field MUST be 0. 1543 Peer's Call ID The value of the Call ID assigned by the 1544 PAC to this call. 1546 Reserved1 This field MUST be 0. 1548 Send ACCM The send ACCM value the client should use 1549 to process outgoing PPP packets. The 1550 default value used by the client until 1551 this message is received is 0XFFFFFFFF. 1552 See [7]. 1554 Receive ACCM The receive ACCM value the client should 1555 use to process incoming PPP packets. The 1556 default value used by the client until 1557 this message is received is 0XFFFFFFFF. 1558 See [7]. 1560 2.16. General Error Codes 1562 General error codes pertain to types of errors which are not specific to 1563 any particular PPTP request, but rather to protocol or message format 1564 errors. If a PPTP reply indicates in its Result Code that a general 1565 error occurred, the General Error value should be examined to determined 1566 what the error was. The currently defined General Error codes and their 1567 meanings are: 1569 0 (None) - No general error 1571 1 (Not-Connected) - No control connection exists yet for this 1572 PAC-PNS pair 1574 2 (Bad-Format) - Length is wrong or Magic Cookie value is 1575 incorrect 1577 3 (Bad-Value) - One of the field values was out of range or 1578 reserved field was non-zero 1580 4 (No-Resource) - Insufficient resources to handle this command 1581 now 1583 5 (Bad-Call ID) - The Call ID is invalid in this context 1585 6 (PAC-Error) - A generic vendor-specific error occurred in 1586 the PAC 1588 3. Control Connection Protocol Operation 1590 This section describes the operation of various PPTP control connection 1591 functions and the Control Connection messages which are used to support 1592 them. The protocol operation of the control connection is simplified 1593 because TCP is used to provide a reliable transport mechanism. Ordering 1594 and retransmission of messages is not a concern at this level. The TCP 1595 connection itself, however, can close at any time and an appropriate 1596 error recovery mechanism must be provided to handle this case. 1598 Some error recovery procedures are common to all states of the control 1599 connection. If an expected reply does not arrive within 60 seconds, the 1600 control connection is closed, unless otherwise specified. Appropriate 1601 logging should be implemented for easy determination of the problems and 1602 the reasons for closing the control connection. 1604 Receipt of an invalid or malformed Control Connection message should be 1605 logged appropriately, and the control connection should be closed and 1606 restarted to ensure recovery into a known state. 1608 3.1. Control Connection States 1610 The control connection relies on a standard TCP connection for its ser- 1611 vice. The PPTP control connection protocol is not distinguishable 1612 between the PNS and PAC, but is distinguishable between the originator 1613 and receiver. The originating peer is the one which first attempts the 1614 TCP open. Since either PAC or PNS may originate a connection, it is pos- 1615 sible for a TCP collision to occur. See Section 3.1.3 for a description 1616 of this situation. 1618 3.1.1. Control Connection Originator (may be PAC or PNS) 1620 TCP Open Indication 1621 /Send Start Control 1622 Connection Request +-----------------+ 1623 +------------------------------------>| wait_ctl_reply | 1624 | +-----------------+ 1625 | Collision/See (3.1.3) Close TCP V V V Receive Start Ctl 1626 | +-------------------------------+ | | Connection Reply 1627 | | | | Version OK 1628 ^ V | V 1629 +-----------------+ Receive Start Ctl | +-----------------+ 1630 | idle | Connection Reply | | established | 1631 +-----------------+ Version Not OK | +-----------------+ 1632 ^ | V Local Terminate 1633 | Receive Stop Control | | /Send Stop 1634 | Connection Request | | Control Request 1635 | /Send Stop Control Reply V V 1636 | Close TCP +-----------------+ 1637 +-------------------------------------| wait_stop_reply | 1638 +-----------------+ 1640 idle 1641 The control connection originator attempts to open a TCP connec- 1642 tion to the peer during idle state. When the TCP connection is 1643 open, the originator transmits a send Start-Control-Connection- 1644 Request and then enters the wait_ctl_reply state. 1646 wait_ctl_reply 1647 The originator checks to see if another TCP connection has been 1648 requested from the same peer, and if so, handles the collision 1649 situation described in Section 3.1.3. 1651 When a Start-Control-Connection-Reply is received, it is examined 1652 for a compatible version. If the version of the reply is lower 1653 than the version sent in the request, the older (lower) version 1654 should be used provided it is supported. If the version in the 1655 reply is earlier and supported, the originator moves to the estab- 1656 lished state. If the version is earlier and not supported, a Stop- 1657 Control-Connection- Request SHOULD be sent to the peer and the 1658 originator moves into the wait_stop_reply state. 1660 established 1661 An established connection may be terminated by either a local con- 1662 dition or the receipt of a Stop-Control-Connection-Request. In the 1663 event of a local termination, the originator MUST send a Stop- 1664 Control-Connection-Request and enter the wait_stop_reply state. 1666 If the originator receives a Stop-Control-Connection-Request it 1667 SHOULD send a Stop-Control-Connection-Reply and close the TCP con- 1668 nection making sure that the final TCP information has been 1669 "pushed" properly. 1671 wait_stop_reply 1672 If a Stop-Control-Connection-Reply is received, the TCP connection 1673 SHOULD be closed and the control connection becomes idle. 1675 3.1.2. Control connection Receiver (may be PAC or PNS) 1677 Receive Start Control Connection Request 1678 Version Not OK/Send Start Control Connection 1679 Reply with Error 1680 +--------+ 1681 | | Receive Control Connection Request Version OK 1682 | | /Send Start Control Connection Reply 1683 | | +----------------------------------------+ 1684 ^ V ^ V 1685 +-----------------+ Receive Start Ctl +-----------------+ 1686 | Idle | Connection Request | Established | 1687 +-----------------+ /Send Stop Reply +-----------------+ 1688 ^ ^ Close TCP V V Local Terminate 1689 | +-------------------------------------+ | /Send Stop 1690 | | Control Conn. 1691 | V Request 1692 | +-----------------+ 1693 +-------------------------------------| Wait-Stop-Reply | 1694 Receive Stop Control +-----------------+ 1695 Connection Reply 1696 /Close TCP 1698 idle 1699 The control connection receiver waits for a TCP open attempt on port 1700 1723. When notified of an open TCP connection, it should prepare to 1701 receive PPTP messages. When a Start-Control-Connection-Request is 1702 received its version field should be examined. If the version is ear- 1703 lier than the receiver's version and the earlier version can be sup- 1704 ported by the receiver, the receiver SHOULD send a Start-Control- 1705 Connection-Reply. If the version is earlier than the receiver's ver- 1706 sion and the version cannot be supported, the receiver SHOULD send a 1707 Start- Connection-Reply message, close the TCP connection and remain 1708 in the idle state. If the receiver's version is the same as earlier 1709 than the peer's, the receiver SHOULD send a Start-Control- Connec- 1710 tion-Reply with the receiver's version and enter the established 1711 state. 1713 established 1714 An established connection may be terminated by either a local condi- 1715 tion or the reception of a Stop-Control-Connection-Request. In the 1716 event of a local termination, the originator MUST send a Stop- Con- 1717 trol-Connection-Request and enter the wait_stop_reply state. 1719 If the originator receives a Stop-Control-Connection-Request it 1720 SHOULD send a Stop-Control-Connection-Reply and close the TCP connec- 1721 tion, making sure that the final TCP information has been "pushed" 1722 properly. 1724 wait_stop_reply 1725 If a Stop-Control-Connection-Reply is received, the TCP connection 1726 SHOULD be closed and the control connection becomes idle. 1728 3.1.3. Start Control Connection Initiation Request Collision 1730 A PAC and PNS must have only one control connection between them. It is 1731 possible, however, for a PNS and a PAC to simultaneously attempt to 1732 establish a control connection to each other. When a Start- Control-Con- 1733 nection-Request is received on one TCP connection and another Start-Con- 1734 trol-Connection-Request has already been sent on another TCP connection 1735 to the same peer, a collision has occurred. 1737 The "winner" of the initiation race is the peer with the higher IP 1738 address (compared as 32 bit unsigned values, network number more signif- 1739 icant). For example, if the peers 192.33.45.17 and 192.33.45.89 collide, 1740 the latter will be declared the winner. The loser will immediately 1741 close the TCP connection it initiated, without sending any further PPTP 1742 control messages on it and will respond to the winner's request with a 1743 Start-Control-Connection-Reply message. The winner will wait for the 1744 Start-Control-Connection-Reply on the connection it initiated and also 1745 wait for a TCP termination indication on the connection the loser 1746 opened. The winner MUST NOT send any messages on the connection the 1747 loser initiated. 1749 3.1.4. Keep Alives and Timers 1751 A control connection SHOULD be closed by closing the underlying TCP con- 1752 nection under the following circumstances: 1754 1. If a control connection is not in the established state (i.e., 1755 Start-Control-Connection-Request and Start-Control-Connection- 1756 Reply have not been exchanged), a control connection SHOULD be 1757 closed after 60 seconds by a peer waiting for a Start-Control- 1758 Connection-Request or Start-Control-Connection-Reply message. 1760 2. If a peer's control connection is in the established state and has 1761 not received a control message for 60 seconds, it SHOULD send a 1762 Echo-Request message. If an Echo-Reply is not received 60 seconds 1763 after the Echo-Request message transmission, the control connec- 1764 tion SHOULD be closed. 1766 3.2. Call States 1768 3.2.1. Timing considerations 1770 Because of the real-time nature of telephone signaling, both the PNS and 1771 PAC should be implemented with multi-threaded architectures such that 1772 messages related to multiple calls are not serialized and blocked. The 1773 transit delay between the PAC and PNS should not exceed one second. The 1774 call and connection state figures do not specify exceptions caused by 1775 timers. The implicit assumption is that since the TCP-based control con- 1776 nection is being verified with keep-alives, there is less need to main- 1777 tain strict timers for call control messages. 1779 Establishing outbound international calls, including the modem training 1780 and negotiation sequences, may take in excess of 1 minute so the use of 1781 short timers is discouraged. 1783 If a state transition does not occur within 1 minute (except for connec- 1784 tions in the idle or established states), the integrity of the protocol 1785 processing between the peers is suspect and the ENTIRE CONTROL CONNEC- 1786 TION should be closed and restarted. All Call IDs are logically released 1787 whenever a control connection is started. This presumably also helps in 1788 preventing toll calls from being "lost" and never cleared. 1790 3.2.2. Call ID values 1792 Each peer assigns a Call ID value to each user session it requests or 1793 accepts. This Call ID value MUST be unique for the tunnel between the 1794 PNS and PAC to which it belongs. Tunnels to other peers can use the same 1795 Call ID number so the receiver of a packet on a tunnel needs to associ- 1796 ate a user session with a particular tunnel and Call ID. It is sug- 1797 gested that the number of potential Call ID values for each tunnel be at 1798 least twice as large as the maximum number of calls expected on a given 1799 tunnel. 1801 A session is defined by the triple (PAC, PNS, Call ID). 1803 3.2.3. Incoming calls 1805 An Incoming-Call-Request message is generated by the PAC when an associ- 1806 ated telephone line rings. The PAC selects a Call ID and serial number 1807 and indicates the call bearer type. Modems should always indicate ana- 1808 log call type. ISDN calls should indicate digital when unrestricted 1809 digital service or rate adaption is used and analog if digital modems 1810 are involved. Dialing number, dialed number, and subaddress may be 1811 included in the message if they are available from the telephone net- 1812 work. 1814 Once the PAC sends the Incoming-Call-Request, it waits for a response 1815 from the PNS but does not answer the call from the telephone network. 1816 The PNS may choose not to accept the call if: 1818 - No resources are available to handle more sessions 1820 - The dialed, dialing, or subaddress fields are not indicative of 1821 an authorized user 1823 - The bearer service is not authorized or supported 1825 If the PNS chooses to accept the call, it responds with an Incoming- 1826 Call-Reply which also indicates window sizes (see Appendix B). When the 1827 PAC receives the Outgoing-Call-Reply, it attempts to connect the call, 1828 assuming the calling party has not hung up. A final call connected mes- 1829 sage from the PAC to the PNS indicates that the call states for both the 1830 PAC and the PNS should enter the established state. 1832 When the dialed-in client hangs up, the call is cleared normally and the 1833 PAC sends a Call-Disconnect-Notify message. If the PNS wishes to clear a 1834 call, it sends a Call-Clear-Request message and then waits for a Call- 1835 Disconnect-Notify. 1837 3.2.3.1. PAC Incoming Call States 1839 Ring/Send Incoming Call Request +-----------------+ 1840 +----------------------------------------->| wait_reply | 1841 | +-----------------+ 1842 | Receive Incoming Call Reply V V V 1843 | Not Accepting | | | Receive Incoming 1844 | +--------------------------------+ | | Call Reply Accepting 1845 | | +------------------------------+ | /Answer call; Send 1846 | | | Abort/Send Call | Call Connected 1847 ^ V V Disconnect Notify V 1848 +-----------------+ +-----------------+ 1849 | idle |<-----------------------------| established | 1850 +-----------------+ Receive Clear Call Request +-----------------+ 1851 or telco call dropped 1852 or local disconnect 1853 /Send Call Disconnect Notify 1855 The states associated with the PAC for incoming calls are: 1857 idle 1858 The PAC detects an incoming call on one of its telco interfaces. 1859 Typically this means an analog line is ringing or an ISDN TE has 1860 detected an incoming Q.931 SETUP message. The PAC sends an Incoming- 1861 Call-Request message and moves to the wait_reply state. 1863 wait_reply 1864 The PAC receives an Incoming-Call-Reply message indicating non- will- 1865 ingness to accept the call (general error or don't accept) and moves 1866 back into the idle state. If the reply message indicates that the 1867 call is accepted, the PAC sends an Incoming-Call-Connected message 1868 and enters the established state. 1870 established 1871 Data is exchanged over the tunnel. The call may be cleared follow- 1872 ing: 1873 An event on the telco connection. The PAC sends a Call-Disconnect- 1874 Notify message 1876 Receipt of a Call-Clear-Request. The PAC sends a Call-Disconnect- 1877 Notify message 1879 A local reason. The PAC sends a Call-Disconnect-Notify message. 1881 3.2.3.2. PNS Incoming Call States 1883 Receive Incoming Call Request 1884 /Send Incoming Call Reply +-----------------+ 1885 Not Accepting if Error | Wait-Connect | 1886 +-----+ +-----------------+ 1887 | | Receive Incoming Call Req. ^ V V 1888 | | /Send Incoming Call Reply OK | | | Receive Incoming 1889 | | +--------------------------------+ | | Call Connect 1890 ^ V ^ V------------------------------+ V 1891 +-----------------+ Receive Call Disconnect +-----------------+ 1892 | Idle | Notify +- | Established | 1893 +-----------------+ | +-----------------+ 1894 ^ ^ | V Local Terminate 1895 | +----------------------------+ | /Send Call Clear 1896 | Receive Call Disconnect | Request 1897 | Notify V 1898 | +-----------------+ 1899 +--------------------------------------| Wait-Disconnect | 1900 Receive Call Disconnect +-----------------+ 1901 Notify 1903 The states associated with the PNS for incoming calls are: 1905 idle 1906 An Incoming-Call-Request message is received. If the request is 1907 not acceptable, an Incoming-Call-Reply is sent back to the PAC and 1908 the PNS remains in the idle state. If the Incoming-Call-Request 1909 message is acceptable, an Incoming-Call-Reply is sent indicating 1910 accept in the result code. The session moves to the wait_connect 1911 state. 1913 wait_connect 1914 If the session is connected on the PAC, the PAC sends an incoming 1915 call connect message to the PNS which then moves into established 1916 state. The PAC may send a Call-Disconnect-Notify to indicate that 1917 the incoming caller could not be connected. This could happen, 1918 for example, if a telephone user accidently places a standard 1919 voice call to a PAC resulting in a handshake failure on the called 1920 modem. 1922 established 1923 The session is terminated either by receipt of a Call-Disconnect- 1924 Notify message from the PAC or by sending a Call-Clear-Request. 1925 Once a Call-Clear-Request has been sent, the session enters the 1926 wait_disconnect state. 1928 wait_disconnect 1929 Once a Call-Disconnect-Notify is received the session moves 1930 back to the idle state. 1932 3.2.4. Outgoing calls 1934 Outgoing messages are initiated by a PNS and instruct a PAC to place a 1935 call on a telco interface. There are only two messages for outgoing 1936 calls: Outgoing-Call-Request and Outgoing-Call-Reply. The PNS sends an 1937 Outgoing-Call-Request specifying the dialed party phone number and sub- 1938 address as well as speed and window parameters. The PAC MUST respond to 1939 the Outgoing-Call-Request message with an Outgoing-Call- Reply message 1940 once the PAC determines that: 1942 The call has been successfully connected 1944 A call failure has occurred for reasons such as: no interfaces are 1945 available for dial-out, the called party is busy or does not answer, 1946 or no dial tone is detected on the interface chosen for dialing 1948 3.2.4.1. PAC Outgoing Call States 1950 Receive Outgoing Call Request in Error 1951 /Send Outgoing Call Reply with Error 1952 |--------+ 1953 | | Receive Outgoing Call Request No Error 1954 | | /Off Hook; Dial 1955 | | +----------------------------------------- 1956 ^ V ^ V 1957 +-----------------+ Incomplete Call +-----------------+ 1958 | idle | /Send Outgoing Call | wait_cs_ans | 1959 +-----------------+ Reply with Error +-----------------+ 1960 ^ ^ or Recv. Call Clear Req. V V Telco Answer 1961 | | /Send Disconnect Notify| | /Send Outgoing 1962 | +-------------------------------------+ | Call Reply. 1963 | V 1964 | +-----------------+ 1965 +-------------------------------------| established | 1966 Receive Call Clear Request +-----------------+ 1967 or local terminate 1968 or telco disconnect 1969 /Hangup call and send 1970 Call Disconnect Notify 1972 The states associated with the PAC for outgoing calls are: 1974 idle 1975 Received Outgoing-Call-Request. If this is received in error, 1976 respond with an Outgoing-Call-Reply with error condition set. Oth- 1977 erwise, allocate physical channel to dial on. Place the outbound 1978 call, wait for a connection, and move to the wait_cs_ans state. 1980 wait_cs_ans 1981 If the call is incomplete, send an Outgoing-Call-Reply with a non- 1982 zero Error Code. If a timer expires on an outbound call, send back 1983 an Outgoing-Call-Reply with a non-zero Error Code. If a circuit 1984 switched connection is established, send an Outgoing-Call-Reply 1985 indicating success. 1987 established 1988 If a Call-Clear-Request is received, the telco call SHOULD be 1989 released via appropriate mechanisms and a Call-Disconnect-Notify 1990 message SHOULD BE sent to the PNS. If the call is disconnected by 1991 the client or by the telco interface, a Call-Disconnect-Notify 1992 message SHOULD be sent to the PNS. 1994 3.2.4.2. PNS Outgoing Call States 1996 Open Indication Abort/Send 1997 /Send Outgoing Call Call Clear 1998 Request +-----------------+ Request 1999 +-------------------------------->| Wait-Reply |------------+ 2000 | +-----------------+ | 2001 | Receive Outgoing Call Reply V V Receive Outgoing | 2002 | with Error | | Call Reply | 2003 | +-------------------------------+ | No Error | 2004 ^ V V | 2005 +-----------------+ +-----------------+ | 2006 | Idle |<-----------------------------| Established | | 2007 +-----------------+ Receive Call Disconnect +-----------------+ | 2008 ^ Notify V Local Terminate | 2009 | | /Send Call Clear | 2010 | | Request | 2011 | Receive Call Disconnect V | 2012 | Notify +-----------------+ | 2013 +---------------------------------| Wait-Disconnect |<-----------+ 2014 +-----------------+ 2016 The states associated with the PNS for outgoing calls are: 2018 idle 2019 An Outgoing-Call-Request message is sent to the PAC and the ses- 2020 sion moves into the wait_reply state. 2022 wait_reply 2023 An Outgoing-Call-Reply is received which indicates an error. The 2024 session returns to idle state. No telco call is active. If the 2025 Outgoing-Call-Reply does not indicate an error, the telco call is 2026 connected and the session moves to the established state. 2028 established 2029 If a Call-Disconnect-Notify is received, the telco call has been 2030 terminated for the reason indicated in the Result and Cause Codes. 2031 The session moves back to the idle state. If the PNS chooses to 2032 terminate the session, it sends a Call-Clear-Request to the PAC 2033 and then enters the wait_disconnect state. 2035 wait_disconnect 2036 A session disconnection is waiting to be confirmed by the PAC. 2037 Once the PNS receives the Call-Disconnect-Notify message, the ses- 2038 sion enters idle state. 2040 4. Tunnel Protocol Operation 2042 The user data carried by the PPTP protocol are PPP data packets. PPP 2043 packets are carried between the PAC and PNS, encapsulated in GRE packets 2044 which in turn are carried over IP. The encapsulated PPP packets are 2045 essentially PPP data packets less any media specific framing elements. 2046 No HDLC flags, bit insertion, control characters, or control character 2047 escapes are included. No CRCs are sent through the tunnel. The IP 2048 packets transmitted over the tunnels between a PAC and PNS has the fol- 2049 lowing general structure: 2050 +--------------------------------+ 2051 | Media Header | 2052 +--------------------------------+ 2053 | IP Header | 2054 +--------------------------------+ 2055 | GRE Header | 2056 +--------------------------------+ 2057 | PPP Packet | 2058 +--------------------------------+ 2060 4.1. Enhanced GRE header 2062 The GRE header used in PPTP is enhanced slightly from that specified in 2063 the current GRE protocol specification [1,2]. The main difference 2064 involves the definition of a new Acknowledgment Number field, used to 2065 determine if a particular GRE packet or set of packets has arrived at 2066 the remote end of the tunnel. This Acknowledgment capability is not 2067 used in conjunction with any retransmission of user data packets. It is 2068 used instead to determine the rate at which user data packets are to be 2069 transmitted over the tunnel for a given user session. The format of the 2070 enhanced GRE header is as follows: 2072 0 1 2 3 2073 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 2074 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2075 |C|R|K|S|s|Recur|A| Flags | Ver | Protocol Type | 2076 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2077 | Key (HW) Payload Length | Key (LW) Call ID | 2078 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2079 | Sequence Number (Optional) | 2080 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2081 | Acknowledgment Number (Optional) | 2082 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2084 C 2085 (Bit 0) Checksum Present. Set to zero (0). 2087 R 2088 (Bit 1) Routing Present. Set to zero (0). 2090 K 2091 (Bit 2) Key Present. Set to one (1). 2093 S 2094 (Bit 3) Sequence Number Present. Set to one (1) if a payload 2095 (data) packet is present. Set to zero (0) if payload is not pre- 2096 sent (GRE packet is an Acknowledgment only). 2098 s 2099 (Bit 4) Strict source route present. Set to zero (0). 2101 Recur 2102 (Bits 5-7) Recursion control. Set to zero (0). 2104 A 2105 (Bit 8) Acknowledgment sequence number present. Set to one (1) if 2106 packet contains Acknowledgment Number to be used for acknowledging 2107 previously transmitted data. 2109 Flags 2110 (Bits 9-12) Must be set to zero (0). 2112 Ver 2113 (Bits 13-15) Must contain 1 (enhanced GRE). 2115 Protocol Type 2116 Set to hex 880B [8]. 2118 Key 2119 Use of the Key field is up to the implementation. PPTP uses it as 2120 follows: 2121 Payload Length 2122 (High 2 octets of Key) Size of the payload, not including 2123 the GRE header 2125 Call ID 2126 (Low 2 octets) Contains the Peer's Call ID for the session 2127 to which this packet belongs. 2129 Sequence Number 2130 Contains the sequence number of the payload. Present if S 2131 bit (Bit 3) is one (1). 2133 Acknowledgment Number 2134 Contains the sequence number of the highest numbered GRE 2135 packet received by the sending peer for this user session. 2136 Present if A bit (Bit 8) is one (1). 2138 The payload section contains a PPP data packet without any media 2139 specific framing elements. 2141 The sequence numbers involved are per packet sequence numbers. 2143 The sequence number for each user session is set to zero at ses- 2144 sion startup. Each packet sent for a given user session which 2145 contains a payload (and has the S bit (Bit 3) set to one) is 2146 assigned the next consecutive sequence number for that session. 2148 This protocol allows acknowledgments to be carried with the data 2149 and makes the overall protocol more efficient, which in turn 2150 requires less buffering of packets. 2152 4.2. Sliding Window Protocol 2154 The sliding window protocol used on the PPTP data path is used for flow 2155 control by each side of the data exchange. The enhanced GRE protocol 2156 allows packet acknowledgments to be piggybacked on data packets. 2157 Acknowledgments can also be sent separately from data packets. Again, 2158 the main purpose of the sliding window protocol is for flow con- 2159 trol--retransmissions are not performed by the tunnel peers. 2161 4.3. Multi-packet Acknowledgment 2163 One feature of the PPTP sliding window protocol is that it allows the 2164 acknowledgment of multiple packets with a single acknowledgment. All 2165 outstanding packets with a sequence number lower or equal to the 2166 acknowledgment number are considered acknowledged. Time-out calculations 2167 are performed using the time the packet corresponding to the highest 2168 sequence number being acknowledged was transmitted. 2170 Adaptive time-out calculations are only performed when an Acknowledgment 2171 is received. When multi-packet acknowledgments are used, the overhead 2172 of the adaptive time-out algorithm is reduced. The PAC is not required 2173 to transmit multi-packet acknowledgments; it can instead acknowledge 2174 each packet individually as it is delivered to the PPP client. 2176 4.4. Out-of-sequence Packets 2178 Occasionally packets lose their sequencing across a complicated inter- 2179 network. Say, for example that a PNS sends packets 0 to 5 to a PAC. 2180 Because of rerouting in the internetwork, packet 4 arrives at the PAC 2181 before packet 3. The PAC acknowledges packet 4, and may assume packet 3 2182 is lost. This acknowledgment grants window credit beyond packet 4. 2184 When the PAC does receive packet 3, it MUST not attempt to transmit it 2185 to the corresponding PPP client. To do so could cause problems, as 2186 proper PPP protocol operation is premised upon receiving packets in 2187 sequence. PPP does properly deal with the loss of packets, but not with 2188 reordering so out of sequence packets between the PNS and PAC MUST be 2189 silently discarded, or they may be reordered by the receiver. When 2190 packet 5 comes in, it is acknowledged by the PAC since it has a higher 2191 sequence number than 4, which was the last highest packet acknowledged 2192 by the PAC. Packets with duplicate sequence numbers should never occur 2193 since the PAC and PNS never retransmit GRE packets. A robust implemen- 2194 tation will silently discard duplicate GRE packets, should it receive 2195 any. 2197 5. Security Considerations 2199 Security issues are not addressed in this document. End to end security 2200 is addressed by PPP. Further security considerations will be addressed 2201 by the next version of PPTP. 2203 6. Authors' Addresses 2205 Kory Hamzeh 2206 Ascend Communications 2207 1275 Harbor Bay Parkway 2208 Alameda, CA 94502 2209 Email: kory@ascend.com 2211 Gurdeep Singh Pall 2212 Microsoft Corporation 2213 Redmond, WA 2214 Email: gurdeep@microsoft.com 2216 William Verthein 2217 U.S. Robotics/3Com 2219 Jeff Taarud 2220 Copper Mountain Networks 2222 W. Andrew Little 2223 ECI Telematics 2225 Glen Zorn 2226 Microsoft Corporation 2227 Redmond, WA 2228 Email: glennz@microsoft.com 2230 7. Expiration Date 2232 This memo is filed as and expires April 2233 15, 1999. 2235 8. References 2237 [1] Hanks, S., Li, T., Farinacci, D., Traina, P., "Generic Routing 2238 Encapsulation (GRE)", RFC 1701, October 1994 2240 [2] Hanks, S., Li, T., Farinacci, D., Traina, P., "Generic Routing 2241 Encapsulation (GRE) over IPv4 Networks", RFC 1702, October 1994 2243 [3] Lloyd, B., Simpson, W., "PPP Authentication Protocols", RFC 1334, 2244 October 1992 2246 [4] Postel, J. B., "Transmission Control Protocol", STD 7, RFC 793, 2247 September 1981 2249 [5] Postel, J. B., "User Data Protocol", STD 6, RFC 768, August 1980 2251 [6] Reynolds, J., Postel, J., "Assigned Numbers", STD 2, RFC 1700, 2252 October, 1994 2254 [7] Simpson, W., editor, "The Point-to-Point Protocol (PPP)", STD 51, 2255 RFC 1661, July 1994 2257 [8] Ethertype for PPP, Reserved with Xerox Corporation. 2259 [9] Simpson, W., "PPP Challenge Handshake Authentication Protocol 2260 (CHAP)", RFC 1994, August 1996 2262 [10] Blunk, L., Vollbrecht, J., "PPP Extensible Authentication Protocol 2263 (EAP)", RFC 2284, March 1998 2265 Appendix A. Acknowledgment Time-Outs 2267 PPTP uses sliding windows and time-outs to provide both user session 2268 flow-control across the internetwork and to perform efficient data 2269 buffering to keep the PAC-PNS data channels full without causing receive 2270 buffer overflow. PPTP requires that a time-out be used to recover from 2271 dropped data or acknowledgment packets. The exact implementation of the 2272 time-out is vendor-specific. It is suggested that an adaptive time-out 2273 be implemented with backoff for congestion control. The time-out mecha- 2274 nism proposed here has the following properties: 2276 Independent time-outs for each session. A device (PAC or PNS) will 2277 have to maintain and calculate time-outs for every active session. 2279 An administrator-adjustable maximum time-out, MaxTimeOut, unique to 2280 each device. 2282 An adaptive time-out mechanism that compensates for changing through- 2283 put. To reduce packet processing overhead, vendors may choose not to 2284 recompute the adaptive time-out for every received acknowledgment. 2285 The result of this overhead reduction is that the time-out will not 2286 respond as quickly to rapid network changes. 2288 Timer backoff on time-out to reduce congestion. The backed-off timer 2289 value is limited by the configurable maximum time-out value. Timer 2290 backoff is done every time an acknowledgment time-out occurs. 2292 In general, this mechanism has the desirable behavior of quickly backing 2293 off upon a time-out and of slowly decreasing the time-out value as pack- 2294 ets are delivered without time-outs. 2296 Some definitions: 2298 Packet Processing Delay (PPD) is the amount of time required for each 2299 side to process the maximum amount of data buffered in their receive 2300 packet sliding window. The PPD is the value exchanged between the PAC 2301 and PNS when a call is established. For the PNS, this number should 2302 be small. For a PAC making modem connections, this number could be 2303 significant. 2305 Sample is the actual amount of time incurred receiving an acknowledg- 2306 ment for a packet. The Sample is measured, not calculated. 2308 Round-Trip Time (RTT) is the estimated round-trip time for an 2309 Acknowledgment to be received for a given transmitted packet. When 2310 the network link is a local network, this delay will be minimal (if 2311 not zero). When the network link is the Internet, this delay could be 2312 substantial and vary widely. RTT is adaptive: it will adjust to 2313 include the PPD and whatever shifting network delays contribute to 2314 the time between a packet being transmitted and receiving its 2315 acknowledgment. 2317 Adaptive Time-Out (ATO) is the time that must elapse before an 2318 acknowledgment is considered lost. After a time-out, the sliding 2319 window is partially closed and the ATO is backed off. 2321 Packet Processing Delay (PPD) 2322 The PPD parameter is a 16-bit word exchanged during the Call Control 2323 phase that represents tenths of a second (64 means 6.4 seconds). The 2324 protocol only specifies that the parameter is exchanged, it does not 2325 specify how it is calculated. The way values for PPD are calculated 2326 is implementation-dependent and need not be variable (static time- 2327 outs are allowed). The PPD must be exchanged in the call connect 2328 sequences, even if it remains constant in an implementation. One pos- 2329 sible way to calculate the PPD is: 2331 PPD' = ((PPP_MAX_DATA_MTU - Header) * WindowSize * 8) / Connec- 2332 tRate PPD = PPD' + PACFudge 2334 Header is the total size of the IP and GRE headers, which is 36. The 2335 MTU is the overall MTU for the internetwork link between the PAC and 2336 PNS. WindowSize represents the number of packets in the sliding win- 2337 dow, and is implementation-dependent. The latency of the internetwork 2338 could be used to pick a window size sufficient to keep the current 2339 session's pipe full. The constant 8 converts octets to bits (assuming 2340 ConnectRate is in bits per second). If ConnectRate is in bytes per 2341 second, omit the 8. PACFudge is not required but can be used to take 2342 overall processing overhead of the PAC into account. 2344 The value of PPD is used to seed the adaptive algorithm with the ini- 2345 tial RTT[n-1] value. 2347 Sample 2349 Sample is the actual measured time for a returned acknowledgment. 2351 Round-Trip Time (RTT) 2353 The RTT value represents an estimate of the average time it takes 2354 for an acknowledgment to be received after a packet is sent to the 2355 remote end of the tunnel. 2357 A.1 Calculating Adaptive Acknowledgment Time-Out 2359 We still must decide how much time to allow for acknowledgments to 2360 return. If the time-out is set too high, we may wait an unnecessarily 2361 long time for dropped packets. If the time-out is too short, we may time 2362 out just before the acknowledgment arrives. The acknowledgment time-out 2363 should also be reasonable and responsive to changing network conditions. 2365 The suggested adaptive algorithm detailed below is based on the TCP 1989 2366 implementation and is explained in Richard Steven's book TCP/IP Illus- 2367 trated, Volume 1 (page 300). 'n' means this iteration of the calcula- 2368 tion, and 'n-1' refers to values from the last calculation. 2370 DIFF[n] = SAMPLE[n] - RTT[n-1] DEV[n] = DEV[n-1] + (beta * (|DIFF[n]| 2371 - DEV[n-1])) RTT[n] = RTT[n-1] + (alpha * DIFF[n]) ATO[n] = MIN 2372 (RTT[n] + (chi * DEV[n]), MaxTimeOut) 2374 DIFF represents the error between the last estimated round-trip time 2375 and the measured time. DIFF is calculated on each iteration. 2377 DEV is the estimated mean deviation. This approximates the standard 2378 deviation. DEV is calculated on each iteration and stored for use in 2379 the next iteration. Initially, it is set to 0. 2381 RTT is the estimated round-trip time of an average packet. RTT is 2382 calculated on each iteration and stored for use in the next itera- 2383 tion. Initially, it is set to PPD. 2385 ATO is the adaptive time-out for the next transmitted packet. ATO is 2386 calculated on each iteration. Its value is limited, by the MIN func- 2387 tion, to be a maximum of the configured MaxTimeOut value. 2389 Alpha is the gain for the average and is typically 1/8 (0.125). 2391 Beta is the gain for the deviation and is typically 1/4 (0.250). 2393 Chi is the gain for the time-out and is typically set to 4. 2395 To eliminate division operations for fractional gain elements, the 2396 entire set of equations can be scaled. With the suggested gain con- 2397 stants, they should be scaled by 8 to eliminate all division. To sim- 2398 plify calculations, all gain values are kept to powers of two so that 2399 shift operations can be used in place of multiplication or division. 2401 A.2 Congestion Control: Adjusting for Time-Out 2403 This section describes how the calculation of ATO is modified in the 2404 case where a time-out does occur. When a time-out occurs, the time- out 2405 value should be adjusted rapidly upward. Although the GRE packets are 2406 not retransmitted when a time-out occurs, the time-out should be 2407 adjusted up toward a maximum limit. To compensate for shifting inter- 2408 network time delays, a strategy must be employed to increase the time- 2409 out when it expires. A simple formula called Karn's Algorithm is used 2410 in TCP implementations and may be used in implementing the backoff 2411 timers for the PNS or the PAC. Notice that in addition to increasing 2412 the time-out, we are also shrinking the size of the window as described 2413 in the next section. 2415 Karn's timer backoff algorithm, as used in TCP, is: 2417 NewTIMEOUT = delta * TIMEOUT 2419 Adapted to our time-out calculations, for an interval in which a time- 2420 out occurs, the new ATO is calculated as: 2422 RTT[n] = delta * RTT[n-1] DEV[n] = DEV[n-1] ATO[n] = MIN (RTT[n] + 2423 (chi * DEV[n]), MaxTimeOut) 2425 In this modified calculation of ATO, only the two values that contribute 2426 to ATO and that are stored for the next iteration are calculated. RTT is 2427 scaled by chi, and DEV is unmodified. DIFF is not carried forward and is 2428 not used in this scenario. A value of 2 for Delta, the time-out gain 2429 factor for RTT, is suggested. 2431 Appendix B. Acknowledgment Time-Out and Window Adjustment 2433 B.1 Initial Window Size 2435 Although each side has indicated the maximum size of its receive window, 2436 it is recommended that a slow start method be used to begin transmitting 2437 data. The initial window size on the transmitter is set to half the 2438 maximum size the receiver requested, with a minimum size of one packet. 2439 The transmitter stops sending packets when the number of packets await- 2440 ing acknowledgment is equal to the current window size. As the receiver 2441 successfully digests each window, the window size on the transmitter is 2442 bumped up by one packet until the maximum is reached. This method pre- 2443 vents a system from flooding an already congested network because no 2444 history has been established. 2446 B.2 Closing the Window 2448 When a time-out does occur on a packet, the sender adjusts the size of 2449 the transmit window down to one half its value when it failed. Frac- 2450 tions are rounded up, and the minimum window size is one. 2452 B.3 Opening the Window 2454 With every successful transmission of a window's worth of packets with- 2455 out a time-out, the transmit window size is increased by one packet 2456 until it reaches the maximum window size that was sent by the other side 2457 when the call was connected. As stated earlier, no retransmission is 2458 done on a time-out. After a time-out, the transmission resumes with the 2459 window starting at one half the size of the transmit window when the 2460 time-out occurred and adjusting upward by one each time the transmit 2461 window is filled with packets that are all acknowledged without time- 2462 outs. 2464 B.4 Window Overflow 2466 When a receiver's window overflows with too many incoming packets, 2467 excess packets are thrown away. This situation should not arise if the 2468 sliding window procedures are being properly followed by the transmitter 2469 and receiver. It is assumed that, on the transmit side, packets are 2470 buffered for transmission and are no longer accepted from the packet 2471 source when the transmit buffer fills.