idnits 2.17.1 draft-ietf-pppext-pptp-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-25) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 42 instances of too long lines in the document, the longest one being 6 characters in excess of 72. ** There are 18 instances of lines with control characters in the document. == 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 280: '... MUST This word, o...' RFC 2119 keyword, line 284: '... MUST NOT This phrase ...' RFC 2119 keyword, line 287: '... SHOULD This word, o...' RFC 2119 keyword, line 295: '... MAY This word, o...' RFC 2119 keyword, line 298: '...nclude this option MUST be prepared to...' (57 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 107 has weird spacing: '...ltilink hunt-...' == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: When the PAC does receive packet 3, it MUST not attempt to transmit it to the corresponding PPP client. To do so could cause problems, as proper PPP protocol operation is premised upon receiving packets in sequence. PPP does properly deal with the loss of packets, but not with reordering so out of sequence packets between the PNS and PAC MUST be silently discarded, or they may be reordered by the receiver. When packet 5 comes in, it is acknowledged by the PAC since it has a higher sequence number than 4, which was the last highest packet acknowledged by the PAC. Packets with duplicate sequence numbers should never occur since the PAC and PNS never retransmit GRE packets. A robust implementation will silently discard duplicate GRE packets, should it receive any. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 1997) is 9781 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '5' is defined on line 2279, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 1701 (ref. '1') ** Downref: Normative reference to an Informational RFC: RFC 1702 (ref. '2') ** Obsolete normative reference: RFC 1334 (ref. '3') (Obsoleted by RFC 1994) ** Obsolete normative reference: RFC 1700 (ref. '6') (Obsoleted by RFC 3232) -- Possible downref: Non-RFC (?) normative reference: ref. '8' Summary: 15 errors (**), 0 flaws (~~), 5 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft Kory Hamzeh 2 Ascend Communications 3 Gurdeep Singh Pall 4 Microsoft Corporation 5 William Verthein 6 U.S. Robotics/3Com 7 Jeff Taarud 8 Copper Mountain Networks 9 W. Andrew Little 10 ECI Telematics 11 July 1997 12 Expire in six months 14 Point-to-Point Tunneling Protocol--PPTP 15 draft-ietf-pppext-pptp-02.txt 17 Status of this Memo 19 This document is an Internet-Draft. Internet-Drafts are working 20 documents of the Internet Engineering Task Force (IETF), its areas, 21 and its working groups. Note that other groups may also distribute 22 working documents as Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 To learn the current status of any Internet-Draft, please check the 30 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 31 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 32 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 33 ftp.isi.edu (US West Coast). 35 Abstract 37 This document specifies a protocol which allows the Point 38 to Point Protocol (PPP) to be tunneled through an IP 39 network. PPTP does not specify any changes to the PPP 40 protocol but rather describes a new vehicle for carrying 41 PPP. A client-server architecture is defined in order to 42 decouple functions which exist in current Network Access 43 Servers (NAS) and support Virtual Private Networks (VPNs). 44 The PPTP Network Server (PNS) is envisioned to run on a 45 general purpose operating system while the client, referred 46 to as a PPTP Access Concentrator (PAC) operates on a dial 47 access platform. PPTP specifies a call-control and 48 management protocol which allows the server to control 49 access for dial-in circuit switched calls originating from 50 a PSTN or ISDN or to initiate outbound circuit-switched 51 connections. PPTP uses an enhanced GRE (Generic Routing 52 Encapsulation) mechanism to provide a flow- and 53 congestion-controlled encapsulated datagram service for 54 carrying PPP packets. 56 1. Introduction 58 PPTP allows existing Network Access Server (NAS) functions to be 59 separated using a client-server architecture. Traditionally, the 60 following functions are implemented by a NAS: 62 1) Physical native interfacing to PSTN or ISDN and control of 63 external modems or terminal adapters. 65 A NAS may interface directly to a telco analog or digital circuit 66 or attach via an external modem or terminal adapter. Control of a 67 circuit-switched connection is accomplished with either modem 68 control or DSS1 ISDN call control protocols. 70 The NAS, in conjunction with the modem or terminal adapters, may 71 perform rate adaption, analog to digital conversion, sync to async 72 conversion or a number of other alterations of data streams. 74 2) Logical termination of a Point-to-Point-Protocol (PPP) Link 75 Control Protocol (LCP) session. 77 3) Participation in PPP authentication protocols [3]. 79 4) Channel aggregation and bundle management for PPP Multilink 80 Protocol. 82 5) Logical termination of various PPP network control protocols 83 (NCP). 85 6) Multiprotocol routing and bridging between NAS interfaces. 87 PPTP divides these functions between the PAC and PNS. The PAC is 88 responsible for functions 1, 2, and possibly 3. The PNS may be 89 responsible for function 3 and is responsible for functions 4, 5, and 90 6. The protocol used to carry PPP protocol data units (PDUs) between 91 the PAC and PNS, as well as call control and management is addressed 92 by PPTP. 94 The decoupling of NAS functions offers these benefits: 96 Flexible IP address management. Dial-in users may maintain a 97 single IP address as they dial into different PACs as long as they 98 are served from a common PNS. If an enterprise network uses 99 unregistered addresses, a PNS associated with the enterprise 100 assigns addresses meaningful to the private network. 102 Support of non-IP protocols for dial networks behind IP networks. 103 This allows Appletalk and IPX, for example to be tunneled through 104 an IP-only provider. The PAC need not be capable of processing 105 these protocols. 107 A solution to the "multilink hunt-group splitting" problem. 108 Multilink PPP, typically used to aggregate ISDN B channels, 109 requires that all of the channels composing a multilink bundle be 110 grouped at a single NAS. Since a multilink PPP bundle can be 111 handled by a single PNS, the channels comprising the bundle may be 112 spread across multiple PACs. 114 1.1 Protocol Goals and Assumptions 116 The PPTP protocol is implemented only by the PAC and PNS. No other 117 systems need to be aware of PPTP. Dial networks may be connected to a 118 PAC without being aware of PPTP. Standard PPP client software should 119 continue to operate on tunneled PPP links. 121 PPTP can also be used to tunnel a PPP session over an IP network. In 122 this configuration the PPTP tunnel and the PPP session runs between 123 the same two machines with the caller acting as a PNS. 125 It is envisioned that there will be a many-to-many relationship 126 between PACs and PNSs. A PAC may provide service to many PNSs. For 127 example, an Internet service provider may choose to support PPTP for 128 a number of private network clients and create VPNs for them. Each 129 private network may operate one or more PNSs. A single PNS may 130 associate with many PACs to concentrate traffic from a large number 131 of geographically diverse sites. 133 PPTP uses an extended version of GRE to carry user PPP packets. These 134 enhancements allow for low-level congestion and flow control to be 135 provided on the tunnels used to carry user data between PAC and PNS. 136 This mechanism allows for efficient use of the bandwidth available 137 for the tunnels and avoids unnecessary retransmisions and buffer 138 overruns. PPTP does not dictate the particular algorithms to be used 139 for this low level control but it does define the parameters that 140 must be communicated in order to allow such algorithms to work. 141 Suggested algorithms are included in Appendix A. 143 1.2 Terminology 144 Analog Channel 146 A circuit-switched communication path which is intended to 147 carry 3.1 Khz audio in each direction. 149 Digital Channel 151 A circuit-switched communication path which is intended to 152 carry digital information in each direction. 154 Call 156 A connection or attempted connection between two terminal 157 endpoints on a PSTN or ISDN--for example, a telephone call 158 between two modems. 160 Control Connection 162 A control connection is created for each PAC, PNS pair and 163 operates over TCP [4]. The control connection governs aspects 164 of the tunnel and of sessions assigned to the tunnel. 166 Dial User 168 An end-system or router attached to an on-demand PSTN or ISDN 169 which is either the initiator or recipient of a call. 171 Network Access Server (NAS) 173 A device providing temporary, on-demand network access to 174 users. This access is point-to-point using PSTN or ISDN lines. 176 PPTP Access Concentrator (PAC) 178 A device attached to one or more PSTN or ISDN lines capable of 179 PPP operation and of handling the PPTP protocol. The PAC need 180 only implement TCP/IP to pass traffic to one or more PNSs. It 181 may also tunnel non-IP protocols. 183 PPTP Network Server (PNS) 185 A PNS is envisioned to operate on general-purpose 186 computing/server platforms. The PNS handles the server side of 187 the PPTP protocol. Since PPTP relies completely on TCP/IP and 188 is independent of the interface hardware, the PNS may use any 189 combination of IP interface hardware including LAN and WAN 190 devices. 192 Session 194 PPTP is connection-oriented. The PNS and PAC maintain state for 195 each user that is attached to a PAC. A session is created when 196 end-to-end PPP connection is attempted between a dial user and 197 the PNS. The datagrams related to a session are sent over the 198 tunnel between the PAC and PNS. 200 Tunnel 202 A tunnel is defined by a PNS-PAC pair. The tunnel protocol is 203 defined by a modified version of GRE [1,2]. The tunnel carries 204 PPP datagrams between the PAC and the PNS. Many sessions are 205 multiplexed on a single tunnel. A control connection operating 206 over TCP controls the establishment, release, and maintenance 207 of sessions and of the tunnel itself. 209 1.3 Protocol Overview 211 There are two parallel components of PPTP: 1) a Control Connection 212 between each PAC-PNS pair operating over TCP and 2) an IP tunnel 213 operating between the same PAC-PNS pair which is used to transport 214 GRE encapsulated PPP packets for user sessions between the pair. 216 1.3.1 Control Connection Overview 218 Before PPP tunneling can occur between a PAC and PNS, a control 219 connection must be established between them. The control connection 220 is a standard TCP session over which PPTP call control and management 221 information is passed. The control session is logically associated 222 with, but separate from, the sessions being tunneled through a PPTP 223 tunnel. For each PAC-PNS pair both a tunnel and a control connection 224 exist. The control connection is responsible for establishment, 225 management, and release of sessions carried through the tunnel. It is 226 the means by which a PNS is notified of an incoming call at an 227 associated PAC, as well as the means by which a PAC is instructed to 228 place an outgoing dial call. 230 A control connection can be established by either the PNS or the PAC. 231 Following the establishment of the required TCP connection, the PNS 232 and PAC establish the control connection using the Start-Control- 233 Connection-Request and -Reply messages. These messages are also used 234 to exchange information about basic operating capabilities of the PAC 235 and PNS. Once the control connection is established, the PAC or PNS 236 may initiate sessions by requesting outbound calls or responding to 237 inbound requests. The control connection may communicate changes in 238 operating characteristics of an individual user session with a Set- 239 Link-Info message. Individual sessions may be released by either the 240 PAC or PNS, also through Control Connection messages. 242 The control connection itself is maintained by keep-alive echo 243 messages. This ensures that a connectivity failure between the PNS 244 and the PAC can be detected in a timely manner. Other failures can be 245 reported via the Wan-Error-Notify message, also on the control 246 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 251 been defined. 253 1.3.2 Tunnel Protocol Overview 255 PPTP requires the establishment of a tunnel for each communicating 256 PNS-PAC pair. This tunnel is used to carry all user session PPP 257 packets for sessions involving a given PNS-PAC pair. A key which is 258 present in the GRE header indicates which session a particular PPP 259 packet belongs to. In this manner, PPP packets are multiplexed and 260 demultiplexed over a single tunnel between a given PNS-PAC pair. The 261 value to use in the key field is established by the call 262 establishment procedure which takes place on the control connection. 264 The GRE header also contains acknowledgment and sequencing 265 information that is used to perform some level of congestion-control 266 and error detection over the tunnel. Again the control connection is 267 used to determine rate and buffering parameters that are used to 268 regulate the flow of PPP packets for a particular session over the 269 tunnel. PPTP does not specify the particular algorithms to use for 270 congestion-control and flow-control. Suggested algorithms for the 271 determination of adaptive time-outs to recover from dropped data or 272 acknowledgments on the tunnel are included in Appendix A of this 273 document. 275 1.4 Specification Language 277 In this document, several words are used to signify the requirements 278 of the specification. These words are often capitalized. 280 MUST This word, or the adjective "required", means 281 that the definition is an absolute requirement 282 of the specification. 284 MUST NOT This phrase means that the definition is an 285 absolute prohibition of the specification. 287 SHOULD This word, or the adjective "recommended", 288 means that, in some circumstances, valid 289 reasons may exist to ignore this item, but the 290 full implications must be understood and 291 carefully weighed before choosing a different 292 course. Unexpected results may result 293 otherwise. 295 MAY This word, or the adjective "optional", means 296 that this item is one of an allowed set of 297 alternatives. An implementation which does 298 not include this option MUST be prepared to 299 interoperate with another implementation which 300 does include the option. 302 silently discard The implementation discards the datagram 303 without further processing, and without 304 indicating an error to the sender. The 305 implementation SHOULD provide the capability 306 of logging the error, including the contents 307 of the discarded datagram, and SHOULD record 308 the event in a statistics counter. 310 1.5 Message Format and Protocol Extensibility 312 PPTP defines a set of messages sent as TCP data on the control 313 connection between a PNS and a given PAC. The TCP session for the 314 control connection is established by initiating a TCP connection to 315 port 1723 [6]. The source port is assigned to any unused port number. 317 Each PPTP Control Connection message begins with an 8 octet fixed 318 header portion. This fixed header contains the following: the total 319 length of the message, the PPTP Message Type indicator, and a "Magic 320 Cookie". 322 Two Control Connection message types are indicated by the PPTP 323 Message Type field: 325 1 - Control Message 326 2 - Management Message 328 Management messages are currently not defined. 330 The Magic Cookie is always sent as the constant 0x1A2B3C4D. Its 331 basic purpose is to allow the receiver to ensure that it is properly 332 synchronized with the TCP data stream. It should not be used as a 333 means for resynchronizing the TCP data stream in the event that a 334 transmitter issues an improperly formatted message. Loss of 335 synchronization must result in immediate closing of the control 336 connection's TCP session. 338 For clarity, all Control Connection message templates in the next 339 section include the entire PPTP Control Connection message header. 340 Numbers preceded by 0x are hexadecimal values. 342 The currently defined Control Messages, grouped by function, are: 344 Control Message Message Code 346 (Control Connection Management) 348 Start-Control-Connection-Request 1 349 Start-Control-Connection-Reply 2 350 Stop-Control-Connection-Request 3 351 Stop-Control-Connection-Reply 4 352 Echo-Request 5 353 Echo-Reply 6 355 (Call Management) 357 Outgoing-Call-Request 7 358 Outgoing-Call-Reply 8 359 Incoming-Call-Request 9 360 Incoming-Call-Reply 10 361 Incoming-Call-Connected 11 362 Call-Clear-Request 12 363 Call-Disconnect-Notify 13 365 (Error Reporting) 367 WAN-Error-Notify 14 369 (PPP Session Control) 371 Set-Link-Info 15 373 The Start-Control-Connection-Request and -Reply messages determine 374 which version of the Control Connection protocol will be used. The 375 version number field carried in these messages consists of a version 376 number in the high octet and a revision number in the low octet. 377 Version handling is described in Section 3. The current value of the 378 version number field is 0x0100 for version 1, revision 0. 380 The use of the GRE-like header for the encapsulation of PPP user 381 packets is specified in Section 4. 383 The MTU for the user data packets encapsulated in GRE is 1532 octets, 384 not including the IP and GRE headers. 386 2.0 Control Connection Protocol Specification 388 Control Connection messages are used to establish and clear user 389 sessions. The first set of Control Connection messages are used to 390 maintain the control connection itself. The control connection is 391 initiated by either the PNS or PAC after they establish the 392 underlying TCP connection. The procedure and configuration 393 information required to determine which TCP connections are 394 established is not covered by this protocol. 396 The following Control Connection messages are all sent as user data 397 on the established TCP connection between a given PNS-PAC pair. Note 398 that care has been taken to ensure that all word (2 octet) and 399 longword (4 octet) values begin on appropriate boundaries. All data 400 is sent in network order (high order octets first). Any "reserved" 401 fields MUST be sent as 0 values to allow for protocol extensibility. 403 The TCP header is followed by the PPTP fields shown in the following: 405 2.1 Start-Control-Connection-Request 407 The Start-Control-Connection-Request is a PPTP control message used 408 to establish the control connection between a PNS and a PAC. Each 409 PNS-PAC pair requires a dedicated control connection to be 410 established. A control connection must be established before any 411 other PPTP messages can be issued. The establishment of the control 412 connection can be initiated by either the PNS or PAC. A procedure 413 which handles the occurrence of a collision between PNS and PAC 414 Start-Control-Connection-Requests is described in Section 3. 416 0 1 2 3 417 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 418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 419 | Length | PPTP Message Type | 420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 421 | Magic Cookie | 422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 423 | Control Message Type | Reserved0 | 424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 425 | Protocol Version | Reserved1 | 426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 427 | Framing Capabilities | 428 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 429 | Bearer Capabilities | 430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 431 | Maximum Channels | Firmware Revision | 432 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 433 | | 434 + Host Name (64 octets) + 435 | | 436 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 437 | | 438 + Vendor String (64 octets) + 439 | | 440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 442 Length Total length in octets of this PPTP 443 message, including the entire PPTP 444 header. 446 PPTP Message Type 1 for Control Message. 448 Magic Cookie 0x1A2B3C4D. This constant value is used 449 as a sanity check on received messages 450 (see Section 1.5). 452 Control Message Type 1 for Start-Control-Connection-Request. 454 Reserved0 This field MUST be 0. 456 Protocol Version The version of the PPTP protocol that the 457 sender wishes to use. 459 Reserved1 This field MUST be 0. 461 Framing Capabilities A set of bits indicating the type of 462 framing that the sender of this message 463 can provide. The currently defined bit 464 settings are: 466 1 - Asynchronous Framing supported 468 2 - Synchronous Framing supported 470 Bearer Capabilities A set of bits indicating the bearer 471 capabilities that the sender of this 472 message can provide. The currently 473 defined bit settings are: 475 1 - Analog access supported 477 2 - Digital access supported 479 Maximum Channels The total number of individual PPP 480 sessions this PAC can support. In 481 Start-Control-Connection-Requests issued 482 by the PNS, this value SHOULD be set to 483 0. It MUST be ignored by the PAC. 485 Firmware Revision This field contains the firmware revision 486 number of the issuing PAC, when issued by 487 the PAC, or the version of the PNS PPTP 488 driver if issued by the PNS. 490 Host Name A 64 octet field containing the DNS name 491 of the issuing PAC or PNS. If less than 492 64 octets in length, the remainder of 493 this field SHOULD be filled with octets 494 of value 0. 496 Vendor Name A 64 octet field containing a vendor 497 specific string describing the type of 498 PAC being used, or the type of PNS 499 software being used if this request is 500 issued by the PNS. If less than 64 501 octets in length, the remainder of this 502 field SHOULD be filled with octets of 503 value 0. 505 2.2 Start-Control-Connection-Reply 507 The Start-Control-Connection-Reply is a PPTP control message sent in 508 reply to a received Start-Control-Connection-Request message. This 509 message contains a result code indicating the result of the control 510 connection establishment attempt. 512 0 1 2 3 513 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 514 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 515 | Length | PPTP Message Type | 516 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 517 | Magic Cookie | 518 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 519 | Control Message Type | Reserved0 | 520 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 521 | Protocol Version | Result Code | Error Code | 522 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 523 | Framing Capability | 524 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 525 | Bearer Capability | 526 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 527 | Maximum Channels | Firmware Revision | 528 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 529 | | 530 + Host Name (64 octets) + 531 | | 532 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 533 | | 534 + Vendor String (64 octets) + 535 | | 536 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 538 Length Total length in octets of this PPTP 539 message, including the entire PPTP 540 header. 542 PPTP Message Type 1 for Control Message. 544 Magic Cookie 0x1A2B3C4D. 546 Control Message Type 2 for Start-Control-Connection-Reply. 548 Reserved0 This field MUST be 0. 550 Protocol Version The version of the PPTP protocol that the 551 sender wishes to use. 553 Result Code Indicates the result of the command 554 channel establishment attempt. Current 555 valid Result Code values are: 557 1 - Successful channel establishment 559 2 - General error -- Error Code 560 indicates the problem 562 3 - Command channel already exists; 564 4 - Requester is not authorized to 565 establish a command channel 567 5 - The protocol version of the 568 requester is not supported 570 Error Code This field is set to 0 unless a "General 571 Error" exists, in which case Result Code 572 is set to 2 and this field is set to the 573 value corresponding to the general error 574 condition as specified in Section 2.16. 576 Framing Capabilities A set of bits indicating the type of 577 framing that the sender of this message 578 can provide. The currently defined bit 579 settings are: 581 1 - Asynchronous Framing supported 583 2 - Synchronous Framing supported. 585 Bearer Capabilities A set of bits indicating the bearer 586 capabilities that the sender of this 587 message can provide. The currently 588 defined bit settings are: 590 1 - Analog access supported 592 2 - Digital access supported 594 Maximum Channels The total number of individual PPP 595 sessions this PAC can support. In a 596 Start-Control-Connection-Reply issued by 597 the PNS, this value SHOULD be set to 0 598 and it must be ignored by the PAC. The 599 PNS MUST NOT use this value to try to 600 track the remaining number of PPP 601 sessions that the PAC will allow. 603 Firmware Revision This field contains the firmware revision 604 number of the issuing PAC, or the version 605 of the PNS PPTP driver if issued by the 606 PNS. 608 Host Name A 64 octet field containing the DNS name 609 of the issuing PAC or PNS. If less than 610 64 octets in length, the remainder of 611 this field SHOULD be filled with octets 612 of value 0. 614 Vendor Name A 64 octet field containing a vendor 615 specific string describing the type of 616 PAC being used, or the type of PNS 617 software being used if this request is 618 issued by the PNS. If less than 64 619 octets in length, the remainder of this 620 field SHOULD be filled with octets of 621 value 0. 623 2.3 Stop-Control-Connection-Request 625 The Stop-Control-Connection-Request is a PPTP control message sent by 626 one peer of a PAC-PNS control connection to inform the other peer 627 that the control connection should be closed. In addition to closing 628 the control connection, all active user calls are implicitly cleared. 629 The reason for issuing this request is indicated in the Reason field. 631 0 1 2 3 632 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 633 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 634 | Length | PPTP Message Type | 635 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 636 | Magic Cookie | 637 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 638 | Control Message Type | Reserved0 | 639 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 640 | Reason | Reserved1 | Reserved2 | 641 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 643 Length Total length in octets of this PPTP 644 message, including the entire PPTP 645 header. 647 PPTP Message Type 1 for Control Message. 649 Magic Cookie 0x1A2B3C4D. 651 Control Message Type 3 for Stop-Control-Connection-Request. 653 Reserved0 This field MUST be 0. 655 Reason Indicates the reason for the control 656 connection being closed. Current valid 657 Reason values are: 659 1 (None) - General request to clear 660 control connection 662 2 (Stop-Protocol) - Can't support 663 peer's version of the protocol 665 3 (Stop-Local-Shutdown) - Requester is 666 being shut down 668 Reserved1, Reserved2 These fields MUST be 0. 670 2.4 Stop-Control-Connection-Reply 672 The Stop-Control-Connection-Reply is a PPTP control message sent by 673 one peer of a PAC-PNS control connection upon receipt of a Stop- 674 Control-Connection-Request from the other peer. 676 0 1 2 3 677 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 678 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 679 | Length | PPTP Message Type | 680 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 681 | Magic Cookie | 682 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 683 | Control Message Type | Reserved0 | 684 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 685 | Result Code | Error Code | Reserved1 | 686 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 688 Length Total length in octets of this PPTP 689 message, including the entire PPTP 690 header. 692 PPTP Message Type 1 for Control Message. 694 Magic Cookie 0x1A2B3C4D. 696 Control Message Type 4 for Stop-Control-Connection-Reply. 698 Reserved0 This field MUST be 0. 700 Result Code Indicates the result of the attempt to 701 close the control connection. Current 702 valid Result Code values are: 704 1 (OK) - Control connection closed 706 2 (General Error) - Control connection 707 not closed for reason indicated in 708 Error Code 710 Error Code This field is set to 0 unless a "General 711 Error" exists, in which case Result Code 712 is set to 2 and this field is set to the 713 value corresponding to the general error 714 condition as specified in Section 2.16. 716 Reserved1 This field MUST be 0. 718 2.5 Echo-Request 720 The Echo-Request is a PPTP control message sent by either peer of a 721 PAC-PNS control connection. This control message is used as a "keep- 722 Alive" for the control connection. The receiving peer issues an 723 Echo-Reply to each Echo-Request received. As specified in Section 3, 724 if the sender does not receive an Echo Reply in response to an Echo- 725 Request, it will eventually clear the control connection. 727 0 1 2 3 728 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 729 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 730 | Length | PPTP Message Type | 731 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 732 | Magic Cookie | 733 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 734 | Control Message Type | Reserved0 | 735 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 736 | Identifier | 737 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 739 Length Total length in octets of this PPTP 740 message, including the entire PPTP 741 header. 743 PPTP Message Type 1 for Control Message. 745 Magic Cookie 0x1A2B3C4D. 747 Control Message Type 5 for Echo-Request. 749 Reserved0 This field MUST be 0. 751 Identifier A value set by the sender of the Echo- 752 Request that is used to match the reply 753 with the corresponding request. 755 2.6 Echo-Reply 757 The Echo-Reply is a PPTP control message sent by either peer of a 758 PAC-PNS control connection in response to the receipt of an Echo- 759 Request. 761 0 1 2 3 762 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 763 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 764 | Length | PPTP Message Type | 765 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 766 | Magic Cookie | 767 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 768 | Control Message Type | Reserved0 | 769 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 770 | Identifier | 771 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 772 | Result Code | Error Code | Reserved1 | 773 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 775 Length Total length in octets of this PPTP 776 message, including the entire PPTP 777 header. 779 PPTP Message Type 1 for Control Message. 781 Magic Cookie 0x1A2B3C4D. 783 Control Message Type 6 for Echo-Reply. 785 Reserved0 This field MUST be 0. 787 Identifier The contents of the identify field from 788 the received Echo-Request is copied to 789 this field. 791 Result Code Indicates the result of the receipt of 792 the Echo-Request. Current valid Result 793 Code values are: 795 1 (OK) - The Echo-Reply is valid 797 2 (General Error) - Echo-Request not 798 accepted for the reason indicated in 799 Error Code 801 Error Code This field is set to 0 unless a "General 802 Error" condition exists, in which case 803 Result Code is set to 2 and this field is 804 set to the value corresponding to the 805 general error condition as specified in 806 Section 2.16. 808 Reserved1 This field MUST be 0. 810 2.7 Outgoing-Call-Request 812 The Outgoing-Call-Request is a PPTP control message sent by the PNS 813 to the PAC to indicate that an outbound call from the PAC is to be 814 established. This request provides the PAC with information required 815 to make the call. It also provides information to the PAC that is 816 used to regulate the transmission of data to the PNS for this session 817 once it is established. 819 0 1 2 3 820 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 821 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 822 | Length | PPTP Message Type | 823 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 824 | Magic Cookie | 825 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 826 | Control Message Type | Reserved0 | 827 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 828 | Call ID | Call Serial Number | 829 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 830 | Minimum BPS | 831 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 832 | Maximum BPS | 833 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 834 | Bearer Type | 835 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 836 | Framing Type | 837 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 838 | Packet Recv. Window Size | Packet Processing Delay | 839 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 840 | Phone Number Length | Reserved1 | 841 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 842 | | 843 + Phone Number (64 octets) + 844 | | 845 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 846 | | 847 + Subaddress (64 octets) + 848 | | 849 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 851 Length Total length in octets of this PPTP 852 message, including the entire PPTP 853 header. 855 PPTP Message Type 1 for Control Message. 857 Magic Cookie 0x1A2B3C4D. 859 Control Message Type 7 for Outgoing-Call-Request. 861 Reserved0 This field MUST be 0. 863 Call ID A unique identifier, unique to a 864 particular PAC-PNS pair assigned by the 865 PNS to this session. It is used to 866 multiplex and demultiplex data sent over 867 the tunnel between the PNS and PAC 868 involved in this session. 870 Call Serial Number An identifier assigned by the PNS to this 871 session for the purpose of identifying 872 this particular session in logged session 873 information. Unlike the Call ID, both 874 the PNS and PAC associate the same Call 875 Serial Number with a given session. The 876 combination of IP address and call serial 877 number SHOULD be unique. 879 Minimum BPS The lowest acceptable line speed (in 880 bits/second) for this session. 882 Maximum BPS The highest acceptable line speed (in 883 bits/second) for this session. 885 Bearer Type A value indicating the bearer capability 886 required for this outgoing call. The 887 currently defined values are: 889 1 - Call to be placed on an analog 890 channel 892 2 - Call to be placed on a digital 893 channel 895 3 - Call can be placed on any type of 896 channel 898 Framing Type A value indicating the type of PPP 899 framing to be used for this outgoing 900 call. 902 1 - Call to use Asynchronous framing 904 2 - Call to use Synchronous framing 905 3 - Call can use either type of 906 framing 908 Packet Recv. Window Size The number of received data packets the 909 PNS will buffer for this session. 911 Packet Processing Delay A measure of the packet processing delay 912 that might be imposed on data sent to the 913 PNS from the PAC. This value is 914 specified in units of 1/10 seconds. For 915 the PNS this number should be very small. 916 See appendix A for a description of how 917 this value is determined and used. 919 Phone Number Length The actual number of valid digits in the 920 Phone Number field. 922 Reserved1 This field MUST be 0. 924 Phone Number The number to be dialed to establish the 925 outgoing session. For ISDN and analog 926 calls this field is an ASCII string. If 927 the Phone Number is less than 64 octets 928 in length, the remainder of this field is 929 filled with octets of value 0. 931 Subaddress A 64 octet field used to specify 932 additional dialing information. If the 933 subaddress is less than 64 octets long, 934 the remainder of this field is filled 935 with octets of value 0. 937 2.8 Outgoing-Call-Reply 939 The Outgoing-Call-Reply is a PPTP control message sent by the PAC to 940 the PNS in response to a received Outgoing-Call-Request message. The 941 reply indicates the result of the outgoing call attempt. It also 942 provides information to the PNS about particular parameters used for 943 the call. It provides information to allow the PNS to regulate the 944 transmission of data to the PAC for this session. 946 0 1 2 3 947 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 948 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 949 | Length | PPTP Message Type | 950 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 951 | Magic Cookie | 952 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 953 | Control Message Type | Reserved0 | 954 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 955 | Call ID | Peer's Call ID | 956 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 957 | Result Code | Error Code | Cause Code | 958 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 959 | Connect Speed | 960 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 961 | Packet Recv. Window Size | Packet Processing Delay | 962 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 963 | Physical Channel ID | 964 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 966 Length Total length in octets of this PPTP 967 message, including the entire PPTP 968 header. 970 PPTP Message Type 1 for Control Message. 972 Magic Cookie 0x1A2B3C4D. 974 Control Message Type 8 for Outgoing-Call-Reply. 976 Reserved0 This field MUST be 0. 978 Call ID A unique identifier for the tunnel, 979 assigned by the PAC to this session. It 980 is used to multiplex and demultiplex data 981 sent over the tunnel between the PNS and 982 PAC involved in this session. 984 Peer's Call ID This field is set to the value received 985 in the Call ID field of the corresponding 986 Outgoing-Call-Request message. It is 987 used by the PNS to match the Outgoing- 988 Call-Reply with the Outgoing-Call-Request 989 it issued. It also is used as the value 990 sent in the GRE header for mux/demuxing. 992 Result Code This value indicates the result of the 993 Outgoing-Call-Request attempt. Currently 994 valid values are: 996 1 (Connected) - Call established with 997 no errors 999 2 (General Error) - Outgoing Call not 1000 established for the reason indicated 1001 in Error Code 1003 3 (No Carrier) - Outgoing Call failed 1004 due to no carrier detected 1006 4 (Busy) - Outgoing Call failed due to 1007 detection of a busy signal 1009 5 (No Dial Tone) - Outgoing Call 1010 failed due to lack of a dial tone 1012 6 (Time-out) - Outgoing Call was not 1013 established within time allotted by 1014 PAC 1016 7 (Do Not Accept) - Outgoing Call 1017 administratively prohibited 1019 Error Code This field is set to 0 unless a "General 1020 Error" condition exists, in which case 1021 Result Code is set to 2 and this field is 1022 set to the value corresponding to the 1023 general error condition as specified in 1024 Section 2.16. 1026 Cause Code This field gives additional failure 1027 information. Its value can vary 1028 depending upon the type of call 1029 attempted. For ISDN call attempts it is 1030 the Q.931 cause code. 1032 Connect Speed The actual connection speed used, in 1033 bits/second. 1035 Packet Recv. Window Size The number of received data packets the 1036 PAC will buffer for this session. 1038 Packet Processing Delay A measure of the packet processing delay 1039 that might be imposed on data sent to the 1040 PAC from the PNS. This value is 1041 specified in units of 1/10 seconds. For 1042 the PAC, this number is related to the 1043 size of the buffer used to hold packets 1044 to be sent to the client and to the speed 1045 of the link to the client. This value 1046 should be set to the maximum delay that 1047 can normally occur between the time a 1048 packet arrives at the PAC and is 1049 delivered to the client. See Appendix A 1050 for an example of how this value is 1051 determined and used. 1053 Physical Channel ID This field is set by the PAC in a 1054 vendor-specific manner to the physical 1055 channel number used to place this call. 1056 It is used for logging purposes only. 1058 2.9 Incoming-Call-Request 1060 The Incoming-Call-Request is a PPTP control message sent by the PAC 1061 to the PNS to indicate that an inbound call is to be established from 1062 the PAC. This request provides the PNS with parameter information 1063 for the incoming call. 1065 This message is the first in the "three-way handshake" used by PPTP 1066 for establishing incoming calls. The PAC may defer answering the 1067 call until it has received an Incoming-Call-Reply from the PNS 1068 indicating that the call should be established. This mechanism allows 1069 the PNS to obtain sufficient information about the call before it is 1070 answered to determine whether the call should be answered or not. 1072 0 1 2 3 1073 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 1074 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1075 | Length | PPTP Message Type | 1076 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1077 | Magic Cookie | 1078 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1079 | Control Message Type | Reserved0 | 1080 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1081 | Call ID | Call Serial Number | 1082 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1083 | Call Bearer Type | 1084 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1085 | Physical Channel ID | 1086 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1087 | Dialed Number Length | Dialing Number Length | 1088 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1089 | | 1090 + Dialed Number (64 octets) + 1091 | | 1092 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1093 | | 1094 + Dialing Number (64 octets) + 1095 | | 1096 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1097 | | 1098 + Subaddress (64 octets) + 1099 | | 1100 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1102 Length Total length in octets of this PPTP 1103 message, including the entire PPTP 1104 header. 1106 PPTP Message Type 1 for Control Message. 1108 Magic Cookie 0x1A2B3C4D. 1110 Control Message Type 9 for Incoming-Call-Request. 1112 Reserved0 This field MUST be 0. 1114 Call ID A unique identifier for this tunnel, 1115 assigned by the PAC to this session. It 1116 is used to multiplex and demultiplex data 1117 sent over the tunnel between the PNS and 1118 PAC involved in this session. 1120 Call Serial Number An identifier assigned by the PAC to this 1121 session for the purpose of identifying 1122 this particular session in logged session 1123 information. Unlike the Call ID, both 1124 the PNS and PAC associate the same Call 1125 Serial Number to a given session. The 1126 combination of IP address and call serial 1127 number should be unique. 1129 Bearer Type A value indicating the bearer capability 1130 used for this incoming call. Currently 1131 defined values are: 1133 1 - Call is on an analog channel 1135 2 - Call is on a digital channel 1137 Physical Channel ID This field is set by the PAC in a 1138 vendor-specific manner to the number of 1139 the physical channel this call arrived 1140 on. 1142 Dialed Number Length The actual number of valid digits in the 1143 Dialed Number field. 1145 Dialing Number Length The actual number of valid digits in the 1146 Dialing Number field. 1148 Dialed Number The number that was dialed by the caller. 1149 For ISDN and analog calls this field is 1150 an ASCII string. If the Dialed Number is 1151 less than 64 octets in length, the 1152 remainder of this field is filled with 1153 octets of value 0. 1155 Dialing Number The number from which the call was 1156 placed. For ISDN and analog calls this 1157 field is an ASCII string. If the Dialing 1158 Number is less than 64 octets in length, 1159 the remainder of this field is filled 1160 with octets of value 0. 1162 Subaddress A 64 octet field used to specify 1163 additional dialing information. If the 1164 subaddress is less than 64 octets long, 1165 the remainder of this field is filled 1166 with octets of value 0. 1168 2.10 Incoming-Call-Reply 1170 The Incoming-Call-Reply is a PPTP control message sent by the PNS to 1171 the PAC in response to a received Incoming-Call-Request message. The 1172 reply indicates the result of the incoming call attempt. It also 1173 provides information to allow the PAC to regulate the transmission of 1174 data to the PNS for this session. 1176 This message is the second in the three-way handshake used by PPTP 1177 for establishing incoming calls. It indicates to the PAC whether the 1178 call should be answered or not. 1180 0 1 2 3 1181 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 1182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1183 | Length | PPTP Message Type | 1184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1185 | Magic Cookie | 1186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1187 | Control Message Type | Reserved0 | 1188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1189 | Call ID | Peer's Call ID | 1190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1191 | Result Code | Error Code | Packet Recv. Window Size | 1192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1193 | Packet Transmit Delay | Reserved1 | 1194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1196 Length Total length in octets of this PPTP 1197 message, including the entire PPTP 1198 header. 1200 PPTP Message Type 1 for Control Message. 1202 Magic Cookie 0x1A2B3C4D. 1204 Control Message Type 10 for Incoming-Call-Reply. 1206 Reserved0 This field MUST be 0. 1208 Call ID A unique identifier for this tunnel 1209 assigned by the PAC to this session. It 1210 is used to multiplex and demultiplex data 1211 sent over the tunnel between the PNS and 1212 PAC involved in this session. 1214 Peer's Call ID This field is set to the value received 1215 in the Call ID field of the corresponding 1216 Incoming-Call-Request message. It is used 1217 by the PAC to match the Incoming-Call- 1218 Reply with the Incoming-Call-Request it 1219 issued. This value is included in the GRE 1220 header of transmitted data packets for 1221 this session. 1223 Result Code This value indicates the result of the 1224 Incoming-Call-Request attempt. Current 1225 valid Result Code values are: 1227 1 (Connect) - The PAC should answer 1228 the incoming call 1230 2 (General Error) - The Incoming Call 1231 should not be established due to the 1232 reason indicated in Error Code 1234 3 (Do Not Accept) - The PAC should not 1235 accept the incoming call. It should 1236 hang up or issue a busy indication 1238 Error Code This field is set to 0 unless a "General 1239 Error" condition exists, in which case 1240 Result Code is set to 2 and this field is 1241 set to the value corresponding to the 1242 general error condition as specified in 1243 Section 2.16. 1245 Packet Recv. Window Size The number of received data packets the 1246 PAC will buffer for this session. 1248 Packet Transmit Delay A measure of the packet processing delay 1249 that might be imposed on data sent to the 1250 PAC from the PNS. This value is 1251 specified in units of 1/10 seconds. See 1252 Appendix A for a description of how this 1253 value is determined and used. 1255 Reserved1 This field MUST be 0. 1257 2.11 Incoming-Call-Connected 1259 The Incoming-Call-Connected message is a PPTP control message sent by 1260 the PAC to the PNS in response to a received Incoming-Call-Reply. It 1261 provides information to the PNS about particular parameters used for 1262 the call. It also provides information to allow the PNS to regulate 1263 the transmission of data to the PAC for this session. 1265 This message is the third in the three-way handshake used by PPTP for 1266 establishing incoming calls. It provides a mechanism for providing 1267 the PNS with additional information about the call that cannot, in 1268 general, be obtained at the time the Incoming-Call-Request is issued 1269 by the PAC. 1271 0 1 2 3 1272 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 1273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1274 | Length | PPTP Message Type | 1275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1276 | Magic Cookie | 1277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1278 | Control Message Type | Reserved0 | 1279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1280 | Peer's Call ID | Reserved1 | 1281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1282 | Connect Speed | 1283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1284 | Packet Recv. Window Size | Packet Transmit Delay | 1285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1286 | Framing Type | 1287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1289 Length Total length in octets of this PPTP 1290 message, including the entire PPTP 1291 header. 1293 PPTP Message Type 1 for Control Message. 1295 Magic Cookie 0x1A2B3C4D. 1297 Control Message Type 11 for Incoming-Call-Connected. 1299 Reserved0 This field MUST be 0. 1301 Peer's Call ID This field is set to the value received 1302 in the Call ID field of the corresponding 1303 Incoming-Call-Reply message. It is used 1304 by the PNS to match the Incoming-Call- 1305 Connected with the Incoming-Call-Reply it 1306 issued. 1308 Connect Speed The actual connection speed used, in 1309 bits/second. 1311 Packet Recv. Window Size The number of received data packets the 1312 PAC will buffer for this session. 1314 Packet Transmit Delay A measure of the packet processing delay 1315 that might be imposed on data sent to the 1316 PAC from the PNS. This value is 1317 specified in units of 1/10 seconds. See 1318 Appendix A for a description of how this 1319 value is determined and used. 1321 Framing Type A value indicating the type of PPP 1322 framing being used by this incoming call. 1324 1 - Call uses asynchronous framing 1326 2 - Call uses synchronous framing 1328 2.12 Call-Clear-Request 1330 The Call-Clear-Request is a PPTP control message sent by the PNS to 1331 the PAC indicating that a particular call is to be disconnected. The 1332 call being cleared can be either an incoming or outgoing call, in any 1333 state. The PAC responds to this message with a Call-Disconnect- 1334 Notify message. 1336 0 1 2 3 1337 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 1338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1339 | Length | PPTP Message Type | 1340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1341 | Magic Cookie | 1342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1343 | Control Message Type | Reserved0 | 1344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1345 | Call ID | Reserved1 | 1346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1348 Length Total length in octets of this PPTP 1349 message, including the entire PPTP 1350 header. 1352 PPTP Message Type 1 for Control Message. 1354 Magic Cookie 0x1A2B3C4D. 1356 Control Message Type 12 for Call-Clear-Request. 1358 Reserved0 This field MUST be 0. 1360 Call ID The Call ID assigned by the PNS to this 1361 call. This value is used instead of the 1362 Peer's Call ID because the latter may not 1363 be known to the PNS if the call must be 1364 aborted during call establishment. 1366 Reserved1 This field MUST be 0. 1368 2.13 Call-Disconnect-Notify 1370 The Call-Disconnect-Notify message is a PPTP control message sent by 1371 the PAC to the PNS. It is issued whenever a call is disconnected, 1372 due to the receipt by the PAC of a Call-Clear-Request or for any 1373 other reason. Its purpose is to inform the PNS of both the 1374 disconnection and the reason for it. 1376 0 1 2 3 1377 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 1378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1379 | Length | PPTP Message Type | 1380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1381 | Magic Cookie | 1382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1383 | Control Message Type | Reserved0 | 1384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1385 | Call ID | Result Code | Error Code | 1386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1387 | Cause Code | Reserved1 | 1388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1389 | | 1390 + Call Statistics (128 octets) + 1391 | | 1392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1394 Length Total length in octets of this PPTP 1395 message, including the entire PPTP 1396 header. 1398 PPTP Message Type 1 for Control Message. 1400 Magic Cookie 0x1A2B3C4D. 1402 Control Message Type 13 for Call-Disconnect-Notify. 1404 Reserved0 This field MUST be 0. 1406 Call ID The value of the Call ID assigned by the 1407 PAC to this call. This value is used 1408 instead of the Peer's Call ID because the 1409 latter may not be known to the PNS if the 1410 call must be aborted during call 1411 establishment. 1413 Result Code This value indicates the reason for the 1414 disconnect. Current valid Result Code 1415 values are: 1417 1 (Lost Carrier) - Call disconnected 1418 due to loss of carrier 1420 2 (General Error) - Call disconnected 1421 for the reason indicated in Error 1422 Code 1424 3 (Admin Shutdown) - Call disconnected 1425 for administrative reasons 1427 4 (Request) - Call disconnected due to 1428 received Call-Clear-Request 1430 Error Code This field is set to 0 unless a "General 1431 Error" condition exists, in which case 1432 the Result Code is set to 2 and this 1433 field is set to the value corresponding 1434 to the general error condition as 1435 specified in Section 2.16. 1437 Cause Code This field gives additional disconnect 1438 information. Its value varies depending 1439 on the type of call being disconnected. 1440 For ISDN calls it is the Q.931 cause 1441 code. 1443 Call Statistics This field is an ASCII string containing 1444 vendor-specific call statistics that can 1445 be logged for diagnostic purposes. If 1446 the length of the string is less than 1447 128, the remainder of the field is filled 1448 with octets of value 0. 1450 2.14 WAN-Error-Notify 1452 The WAN-Error-Notify message is a PPTP control message sent by the 1453 PAC to the PNS to indicate WAN error conditions (conditions that 1454 occur on the interface supporting PPP). The counters in this message 1455 are cumulative. This message should only be sent when an error 1456 occurs, and not more than once every 60 seconds. The counters are 1457 reset when a new call is established. 1459 0 1 2 3 1460 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 1461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1462 | Length | PPTP Message Type | 1463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1464 | Magic Cookie | 1465 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1466 | Control Message type | Reserved0 | 1467 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1468 | Peer's Call ID | Reserved1 | 1469 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1470 | CRC Errors | 1471 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1472 | Framing Errors | 1473 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1474 | Hardware Overruns | 1475 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1476 | Buffer Overruns | 1477 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1478 | Time-out Errors | 1479 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1480 | Alignment Errors | 1481 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1483 Length Total length in octets of this PPTP 1484 message, including the entire PPTP 1485 header. 1487 PPTP Message Type 1 for Control Message. 1489 Magic Cookie 0x1A2B3C4D. 1491 Control Message Type 14 for WAN-Error-Notify. 1493 Reserved0 This field MUST be 0. 1495 Peer's Call ID Th Call ID assigned by the PNS to this 1496 call. 1498 CRC Errors Number of PPP frames received with CRC 1499 errors since session was established. 1501 Framing Errors Number of improperly framed PPP packets 1502 received. 1504 Hardware Overruns Number of receive buffer over-runs since 1505 session was established. 1507 Buffer Overruns Number of buffer over-runs detected since 1508 session was established. 1510 Time-out Errors Number of time-outs since call was 1511 established. 1513 Alignment Errors Number of alignment errors since call was 1514 established. 1516 2.15 Set-Link-Info 1518 The Set-Link-Info message is a PPTP control message sent by the PNS 1519 to the PAC to set PPP-negotiated options. Because these options can 1520 change at any time during the life of the call, the PAC must be able 1521 to update its internal call information dynamically and perform PPP 1522 negotiation on an active PPP session. 1524 0 1 2 3 1525 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 1526 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1527 | Length | PPTP Message Type | 1528 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1529 | Magic Cookie | 1530 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1531 | Control Message type | Reserved0 | 1532 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1533 | Peer's Call ID | Reserved1 | 1534 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1535 | Send ACCM | 1536 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1537 | Receive ACCM | 1538 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1540 Length Total length in octets of this PPTP 1541 message, including the entire PPTP 1542 header. 1544 PPTP Message Type 1 for Control Message. 1546 Magic Cookie 0x1A2B3C4D. 1548 Control Message Type 15 for Set-Link-Info. 1550 Reserved0 This field MUST be 0. 1552 Peer's Call ID The value of the Call ID assigned by the 1553 PAC to this call. 1555 Reserved1 This field MUST be 0. 1557 Send ACCM The send ACCM value the client should use 1558 to process outgoing PPP packets. The 1559 default value used by the client until 1560 this message is received is 0XFFFFFFFF. 1561 See [7]. 1563 Receive ACCM The receive ACCM value the client should 1564 use to process incoming PPP packets. The 1565 default value used by the client until 1566 this message is received is 0XFFFFFFFF. 1567 See [7]. 1569 2.16 General Error Codes 1571 General error codes pertain to types of errors which are not specific 1572 to any particular PPTP request, but rather to protocol or message 1573 format errors. If a PPTP reply indicates in its Result Code that a 1574 general error occurred, the General Error value should be examined to 1575 determined what the error was. The currently defined General Error 1576 codes and their meanings are: 1578 0 (None) - No general error 1580 1 (Not-Connected) - No control connection exists yet for this 1581 PAC-PNS pair 1583 2 (Bad-Format) - Length is wrong or Magic Cookie value is 1584 incorrect 1586 3 (Bad-Value) - One of the field values was out of range or 1587 reserved field was non-zero 1589 4 (No-Resource) - Insufficient resources to handle this command 1590 now 1592 5 (Bad-Call ID) - The Call ID is invalid in this context 1594 6 (PAC-Error) - A generic vendor-specific error occurred in 1595 the PAC 1597 3.0 Control Connection Protocol Operation 1599 This section describes the operation of various PPTP control 1600 connection functions and the Control Connection messages which are 1601 used to support them. The protocol operation of the control 1602 connection is simplified because TCP is used to provide a reliable 1603 transport mechanism. 1604 Ordering and retransmission of messages is not a concern at this 1605 level. The TCP connection itself, however, can close at any time and 1606 an appropriate error recovery mechanism must be provided to handle 1607 this case. 1609 Some error recovery procedures are common to all states of the 1610 control connection. If an expected reply does not arrive within 60 1611 seconds, the control connection is closed, unless otherwise 1612 specified. Appropriate logging should be implemented for easy 1613 determination of the problems and the reasons for closing the control 1614 connection. 1616 Receipt of an invalid or malformed Control Connection message should 1617 be logged appropriately, and the control connection should be closed 1618 and restarted to ensure recovery into a known state. 1620 3.1 Control Connection States 1622 The control connection relies on a standard TCP connection for its 1623 service. The PPTP control connection protocol is not distinguishable 1624 between the PNS and PAC, but is distinguishable between the 1625 originator and receiver. The originating peer is the one which first 1626 attempts the TCP open. Since either PAC or PNS may originate a 1627 connection, it is possible for a TCP collision to occur. See Section 1628 3.1.3 for a description of this situation. 1630 3.1.1 Control Connection Originator (may be PAC or PNS) 1632 TCP Open Indication 1633 /Send Start Control 1634 Connection Request +-----------------+ 1635 +------------------------------------>| wait_ctl_reply | 1636 | +-----------------+ 1637 | Collision/See (3.1.3) Close TCP V V V Receive Start Ctl 1638 | +-------------------------------+ | | Connection Reply 1639 | | | | Version OK 1640 ^ V | V 1641 +-----------------+ Receive Start Ctl | +-----------------+ 1642 | idle | Connection Reply | | established | 1643 +-----------------+ Version Not OK | +-----------------+ 1644 ^ | V Local Terminate 1645 | Receive Stop Control | | /Send Stop 1646 | Connection Request | | Control Request 1647 | /Send Stop Control Reply V V 1648 | Close TCP +-----------------+ 1649 +-------------------------------------| wait_stop_reply | 1650 +-----------------+ 1652 idle 1654 The control connection originator attempts to open a TCP connection 1655 to the peer during idle state. When the TCP connection is open, the 1656 originator transmits a send Start-Control-Connection-Request and then 1657 enters the wait_ctl_reply state. 1659 wait_ctl_reply 1661 The originator checks to see if another TCP connection has been 1662 requested from the same peer, and if so, handles the collision 1663 situation described in Section 3.1.3. 1665 When a Start-Control-Connection-Reply is received, it is examined for 1666 a compatible version. If the version of the reply is lower than the 1667 version sent in the request, the older (lower) version should be used 1668 provided it is supported. If the version in the reply is earlier and 1669 supported, the originator moves to the established state. If the 1670 version is earlier and not supported, a Stop-Control-Connection- 1671 Request SHOULD be sent to the peer and the originator moves into the 1672 wait_stop_reply state. 1674 established 1676 An established connection may be terminated by either a local 1677 condition or the receipt of a Stop-Control-Connection-Request. In the 1678 event of a local termination, the originator MUST send a Stop- 1679 Control-Connection-Request and enter the wait_stop_reply state. 1681 If the originator receives a Stop-Control-Connection-Request it 1682 SHOULD send a Stop-Control-Connection-Reply and close the TCP 1683 connection making sure that the final TCP information has been 1684 "pushed" properly. 1686 wait_stop_reply 1688 If a Stop-Control-Connection-Reply is received, the TCP connection 1689 SHOULD be closed and the control connection becomes idle. 1691 3.1.2 Control connection Receiver (may be PAC or PNS) 1693 Receive Start Control Connection Request 1694 Version Not OK/Send Start Control Connection 1695 Reply with Error 1696 +--------+ 1697 | | Receive Control Connection Request Version OK 1698 | | /Send Start Control Connection Reply 1699 | | +----------------------------------------+ 1700 ^ V ^ V 1701 +-----------------+ Receive Start Ctl +-----------------+ 1702 | Idle | Connection Request | Established | 1703 +-----------------+ /Send Stop Reply +-----------------+ 1704 ^ ^ Close TCP V V Local Terminate 1705 | +-------------------------------------+ | /Send Stop 1706 | | Control Conn. 1707 | V Request 1708 | +-----------------+ 1709 +-------------------------------------| Wait-Stop-Reply | 1710 Receive Stop Control +-----------------+ 1711 Connection Reply 1712 /Close TCP 1714 idle 1716 The control connection receiver waits for a TCP open attempt on port 1717 1723. When notified of an open TCP connection, it should prepare to 1718 receive PPTP messages. When a Start-Control-Connection-Request is 1719 received its version field should be examined. If the version is 1720 earlier than the receiver's version and the earlier version can be 1721 supported by the receiver, the receiver SHOULD send a Start-Control- 1722 Connection-Reply. If the version is earlier than the receiver's 1723 version and the version cannot be supported, the receiver SHOULD send 1724 a Start- Connection-Reply message, close the TCP connection and 1725 remain in the idle state. If the receiver's version is the same as 1726 earlier than the peer's, the receiver SHOULD send a Start-Control- 1727 Connection-Reply with the receiver's version and enter the 1728 established state. 1730 established 1732 An established connection may be terminated by either a local 1733 condition or the reception of a Stop-Control-Connection-Request. In 1734 the event of a local termination, the originator MUST send a Stop- 1735 Control-Connection-Request and enter the wait_stop_reply state. 1737 If the originator receives a Stop-Control-Connection-Request it 1738 SHOULD send a Stop-Control-Connection-Reply and close the TCP 1739 connection, making sure that the final TCP information has been 1740 "pushed" properly. 1742 wait_stop_reply 1744 If a Stop-Control-Connection-Reply is received, the TCP connection 1745 SHOULD be closed and the control connection becomes idle. 1747 3.1.3 Start Control Connection Initiation Request Collision 1749 A PAC and PNS must have only one control connection between them. It 1750 is possible, however, for a PNS and a PAC to simultaneously attempt 1751 to establish a control connection to each other. When a Start- 1752 Control-Connection-Request is received on one TCP connection and 1753 another Start-Control-Connection-Request has already been sent on 1754 another TCP connection to the same peer, a collision has occurred. 1756 The "winner" of the initiation race is the peer with the higher IP 1757 address (compared as 32 bit unsigned values, network number more 1758 significant). For example, if the peers 192.33.45.17 and 192.33.45.89 1759 collide, the latter will be declared the winner. 1761 The loser will immediately close the TCP connection it initiated, 1762 without sending any further PPTP control messages on it and will 1763 respond to the winner's request with a Start-Control-Connection-Reply 1764 message. The winner will wait for the Start-Control-Connection-Reply 1765 on the connection it initiated and also wait for a TCP termination 1766 indication on the connection the loser opened. The winner MUST NOT 1767 send any messages on the connection the loser initiated. 1769 3.1.3 Keep Alives and Timers 1771 A control connection SHOULD be closed by closing the underlying TCP 1772 connection under the following circumstances: 1774 1. If a control connection is not in the established state (i.e., 1775 Start-Control-Connection-Request and Start-Control-Connection- 1776 Reply have not been exchanged), a control connection SHOULD be 1777 closed after 60 seconds by a peer waiting for a Start-Control- 1778 Connection-Request or Start-Control-Connection-Reply message. 1780 2. If a peer's control connection is in the established state and has 1781 not received a control message for 60 seconds, it SHOULD send a 1782 Echo-Request message. If an Echo-Reply is not received 60 seconds 1783 after the Echo-Request message transmission, the control 1784 connection SHOULD be closed. 1786 3.2 Call States 1788 3.2.1 Timing considerations 1790 Because of the real-time nature of telephone signaling, both the PNS 1791 and PAC should be implemented with multi-threaded architectures such 1792 that messages related to multiple calls are not serialized and 1793 blocked. The transit delay between the PAC and PNS should not exceed 1794 one second. The call and connection state figures do not specify 1795 exceptions caused by timers. The implicit assumption is that since 1796 the TCP-based control connection is being verified with keep-alives, 1797 there is less need to maintain strict timers for call control 1798 messages. 1800 Establishing outbound international calls, including the modem 1801 training and negotiation sequences, may take in excess of 1 minute so 1802 the use of short timers is discouraged. 1804 If a state transition does not occur within 1 minute (except for 1805 connections in the idle or established states), the integrity of the 1806 protocol processing between the peers is suspect and the ENTIRE 1807 CONTROL CONNECTION should be closed and restarted. All Call IDs are 1808 logically released whenever a control connection is started. This 1809 presumably also helps in preventing toll calls from being "lost" and 1810 never cleared. 1812 3.2.2 Call ID values 1814 Each peer assigns a Call ID value to each user session it requests or 1815 accepts. This Call ID value MUST be unique for the tunnel between the 1816 PNS and PAC to which it belongs. Tunnels to other peers can use the 1817 same Call ID number so the receiver of a packet on a tunnel needs to 1818 associate a user session with a particular tunnel and Call ID. It is 1819 suggested that the number of potential Call ID values for each tunnel 1820 be at least twice as large as the maximum number of calls expected on 1821 a given tunnel. 1823 A session is defined by the triple (PAC, PNS, Call ID). 1825 3.2.3 Incoming calls 1827 An Incoming-Call-Request message is generated by the PAC when an 1828 associated telephone line rings. The PAC selects a Call ID and serial 1829 number and indicates the call bearer type. Modems should always 1830 indicate analog call type. ISDN calls should indicate digital when 1831 unrestricted digital service or rate adaption is used and analog if 1832 digital modems are involved. Dialing number, dialed number, and 1833 subaddress may be included in the message if they are available from 1834 the telephone network. 1836 Once the PAC sends the Incoming-Call-Request, it waits for a response 1837 from the PNS but does not answer the call from the telephone network. 1838 The PNS may choose not to accept the call if: 1840 - No resources are available to handle more sessions 1842 - The dialed, dialing, or subaddress fields are not indicative of 1843 an authorized user 1845 - The bearer service is not authorized or supported 1847 If the PNS chooses to accept the call, it responds with an Outgoing- 1848 Call-Reply which also indicates window sizes (see Appendix B). When 1849 the PAC receives the Outgoing-Call-Reply, it attempts to connect the 1850 call, assuming the calling party has not hung up. A final call 1851 connected message from the PAC to the PNS indicates that the call 1852 states for both the PAC and the PNS should enter the established 1853 state. 1855 When the dialed-in client hangs up, the call is cleared normally and 1856 the PAC sends a Call-Disconnect-Notify message. If the PNS wishes to 1857 clear a call, it sends a Call-Clear-Request message and then waits 1858 for a Call-Disconnect-Notify. 1860 3.2.3.1 PAC Incoming Call States 1862 Ring/Send Incoming Call Request +-----------------+ 1863 +----------------------------------------->| wait_reply | 1864 | +-----------------+ 1865 | Receive Incoming Call Reply V V V 1866 | Not Accepting | | | Receive Incoming 1867 | +--------------------------------+ | | Call Reply Accepting 1868 | | +------------------------------+ | /Answer call; Send 1869 | | | Abort/Send Call | Call Connected 1870 ^ V V Disconnect Notify V 1871 +-----------------+ +-----------------+ 1872 | idle |<-----------------------------| established | 1873 +-----------------+ Receive Clear Call Request +-----------------+ 1874 or telco call dropped 1875 or local disconnect 1876 /Send Call Disconnect Notify 1878 The states associated with the PAC for incoming calls are: 1880 idle 1882 The PAC detects an incoming call on one of its telco interfaces. 1883 Typically this means an analog line is ringing or an ISDN TE has 1884 detected an incoming Q.931 SETUP message. The PAC sends an Incoming- 1885 Call-Request message and moves to the wait_reply state. 1887 wait_reply 1889 The PAC receives an Incoming-Call-Reply message indicating non- 1890 willingness to accept the call (general error or don't accept) and 1891 moves back into the idle state. If the reply message indicates that 1892 the call is accepted, the PAC sends an Incoming-Call-Connected 1893 message and enters the established state. 1895 established 1897 Data is exchanged over the tunnel. The call may be cleared following: 1899 An event on the telco connection. The PAC sends a Call- 1900 Disconnect-Notify message 1902 Receipt of a Call-Clear-Request. The PAC sends a Call-Disconnect- 1903 Notify message 1904 A local reason. The PAC sends a Call-Disconnect-Notify message. 1906 3.2.3.2 PNS Incoming Call States 1908 Receive Incoming Call Request 1909 /Send Incoming Call Reply +-----------------+ 1910 Not Accepting if Error | Wait-Connect | 1911 +-----+ +-----------------+ 1912 | | Receive Incoming Call Req. ^ V V 1913 | | /Send Incoming Call Reply OK | | | Receive Incoming 1914 | | +--------------------------------+ | | Call Connect 1915 ^ V ^ V------------------------------+ V 1916 +-----------------+ Receive Call Disconnect +-----------------+ 1917 | Idle | Notify +- | Established | 1918 +-----------------+ | +-----------------+ 1919 ^ ^ | V Local Terminate 1920 | +----------------------------+ | /Send Call Clear 1921 | Receive Call Disconnect | Request 1922 | Notify V 1923 | +-----------------+ 1924 +--------------------------------------| Wait-Disconnect | 1925 Receive Call Disconnect +-----------------+ 1926 Notify 1928 The states associated with the PNS for incoming calls are: 1930 idle 1932 An Incoming-Call-Request message is received. If the request is not 1933 acceptable, an Incoming-Call-Reply is sent back to the PAC and the 1934 PNS remains in the idle state. If the Incoming-Call-Request message 1935 is acceptable, an Incoming-Call-Reply is sent indicating accept in 1936 the result code. The session moves to the wait_connect state. 1938 wait_connect 1940 If the session is connected on the PAC, the PAC sends an incoming 1941 call connect message to the PNS which then moves into established 1942 state. The PAC may send a Call-Disconnect-Notify to indicate that the 1943 incoming caller could not be connected. This could happen, for 1944 example, if a telephone user accidently places a standard voice call 1945 to a PAC resulting in a handshake failure on the called modem. 1947 established 1949 The session is terminated either by receipt of a Call-Disconnect- 1950 Notify message from the PAC or by sending a Call-Clear-Request. Once 1951 a Call-Clear-Request has been sent, the session enters the 1952 wait_disconnect state. 1954 wait_disconnect 1956 Once a Call-Disconnect-Notify is received the session moves back to 1957 the idle state. 1959 3.2.4 Outgoing calls 1961 Outgoing messages are initiated by a PNS and instruct a PAC to place 1962 a call on a telco interface. There are only two messages for outgoing 1963 calls: Outgoing-Call-Request and Outgoing-Call-Reply. The PNS sends 1964 an Outgoing-Call-Request specifying the dialed party phone number and 1965 subaddress as well as speed and window parameters. The PAC MUST 1966 respond to the Outgoing-Call-Request message with an Outgoing-Call- 1967 Reply message once the PAC determines that: 1969 The call has been successfully connected 1971 A call failure has occurred for reasons such as: no interfaces are 1972 available for dial-out, the called party is busy or does not 1973 answer, or no dial tone is detected on the interface chosen for 1974 dialing 1976 3.2.4.1 PAC Outgoing Call States 1978 Receive Outgoing Call Request in Error 1979 /Send Outgoing Call Reply with Error 1980 |--------+ 1981 | | Receive Outgoing Call Request No Error 1982 | | /Off Hook; Dial 1983 | | +----------------------------------------- 1984 ^ V ^ V 1985 +-----------------+ Incomplete Call +-----------------+ 1986 | idle | /Send Outgoing Call | wait_cs_ans | 1987 +-----------------+ Reply with Error +-----------------+ 1988 ^ ^ or Recv. Call Clear Req. V V Telco Answer 1989 | | /Send Disconnect Notify| | /Send Outgoing 1990 | +-------------------------------------+ | Call Reply. 1991 | V 1992 | +-----------------+ 1993 +-------------------------------------| established | 1994 Receive Call Clear Request +-----------------+ 1995 or local terminate 1996 or telco disconnect 1997 /Hangup call and send 1998 Call Disconnect Notify 2000 The states associated with the PAC for outgoing calls are: 2002 idle 2004 Received Outgoing-Call-Request. If this is received in error, respond 2005 with an Outgoing-Call-Reply with error condition set. Otherwise, 2006 allocate physical channel to dial on. Place the outbound call, wait 2007 for a connection, and move to the wait_cs_ans state. 2009 wait_cs_ans 2011 If the call is incomplete, send an Outgoing-Call-Reply with a non- 2012 zero Error Code. If a timer expires on an outbound call, send back an 2013 Outgoing-Call-Reply with a non-zero Error Code. If a circuit switched 2014 connection is established, send an Outgoing-Call-Reply indicating 2015 success. 2017 established 2019 If a Call-Clear-Request is received, the telco call SHOULD be 2020 released via appropriate mechanisms and a Call-Disconnect-Notify 2021 message SHOULD BE sent to the PNS. If the call is disconnected by the 2022 client or by the telco interface, a Call-Disconnect-Notify message 2023 SHOULD be sent to the PNS. 2025 3.2.4.2 PNS Outgoing Call States 2027 Open Indication Abort/Send 2028 /Send Outgoing Call Call Clear 2029 Request +-----------------+ Request 2030 +-------------------------------->| Wait-Reply |------------+ 2031 | +-----------------+ | 2032 | Receive Outgoing Call Reply V V Receive Outgoing | 2033 | with Error | | Call Reply | 2034 | +-------------------------------+ | No Error | 2035 ^ V V | 2036 +-----------------+ +-----------------+ | 2037 | Idle |<-----------------------------| Established | | 2038 +-----------------+ Receive Call Disconnect +-----------------+ | 2039 ^ Notify V Local Terminate | 2040 | | /Send Call Clear | 2041 | | Request | 2042 | Receive Call Disconnect V | 2043 | Notify +-----------------+ | 2044 +---------------------------------| Wait-Disconnect |<-----------+ 2045 +-----------------+ 2047 The states associated with the PNS for outgoing calls are: 2049 idle 2051 An Outgoing-Call-Request message is sent to the PAC and the session 2052 moves into the wait_reply state. 2054 wait_reply 2056 An Outgoing-Call-Reply is received which indicates an error. The 2057 session returns to idle state. No telco call is active. If the 2058 Outgoing-Call-Reply does not indicate an error, the telco call is 2059 connected and the session moves to the established state. 2061 established 2063 If a Call-Disconnect-Notify is received, the telco call has been 2064 terminated for the reason indicated in the Result and Cause Codes. 2065 The session moves back to the idle state. If the PNS chooses to 2066 terminate the session, it sends a Call-Clear-Request to the PAC and 2067 then enters the wait_disconnect state. 2069 wait_disconnect 2071 A session disconnection is waiting to be confirmed by the PAC. Once 2072 the PNS receives the Call-Disconnect-Notify message, the session 2073 enters idle state. 2075 4.0 Tunnel Protocol Operation 2077 The user data carried by the PPTP protocol are PPP data packets. PPP 2078 packets are carried between the PAC and PNS, encapsulated in GRE 2079 packets which in turn are carried over IP. The encapsulated PPP 2080 packets are essentially PPP data packets less any media specific 2081 framing elements. No HDLC flags, bit insertion, control characters, 2082 or control character escapes are included. No CRCs are sent through 2083 the tunnel. The IP packets transmitted over the tunnels between a PAC 2084 and PNS has the following general structure: 2086 +--------------------------------+ 2087 | Media Header | 2088 +--------------------------------+ 2089 | IP Header | 2090 +--------------------------------+ 2091 | GRE Header | 2092 +--------------------------------+ 2093 | PPP Packet | 2094 +--------------------------------+ 2096 4.1 Enhanced GRE header 2098 The GRE header used in PPTP is enhanced slightly from that specified 2099 in the current GRE protocol specification [1,2]. The main difference 2100 involves the definition of a new Acknowledgment Number field, used to 2101 determine if a particular GRE packet or set of packets has arrived at 2102 the remote end of the tunnel. This Acknowledgment capability is not 2103 used in conjunction with any retransmission of user data packets. It 2104 is used instead to determine the rate at which user data packets are 2105 to be transmitted over the tunnel for a given user session. 2107 The format of the enhanced GRE header is as follows: 2109 0 1 2 3 2110 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 2111 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2112 |C|R|K|S|s|Recur|A| Flags | Ver | Protocol Type | 2113 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2114 | Key (HW) Payload Length | Key (LW) Call ID | 2115 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2116 | Sequence Number (Optional) | 2117 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2118 | Acknowledgment Number (Optional) | 2119 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2121 C (Bit 0) Checksum Present. Set to zero 2122 (0). 2124 R (Bit 1) Routing Present. Set to zero 2125 (0). 2127 K (Bit 2) Key Present. Set to one (1). 2129 S (Bit 3) Sequence Number Present. Set to 2130 one (1) if a payload (data) packet is 2131 present. Set to zero (0) if payload is 2132 not present (GRE packet is an 2133 Acknowledgment only). 2135 s (Bit 4) Strict source route present. Set 2136 to zero (0). 2138 Recur (Bits 5-7) Recursion control. Set to 2139 zero (0). 2141 A (Bit 8) Acknowledgment sequence number 2142 present. Set to one (1) if packet 2143 contains Acknowledgment Number to be used 2144 for acknowledging previously transmitted 2145 data. 2147 Flags (Bits 9-12) Must be set to zero (0). 2149 Ver (Bits 13-15) Must contain 1 (enhanced 2150 GRE). 2152 Protocol Type Set to hex 880B [8]. 2154 Key Use of the Key field is up to the 2155 implementation. 2156 PPTP uses it as follows: 2158 Payload Length 2159 (High 2 octets of Key) Size of the 2160 payload, not including the GRE header 2162 Call ID 2163 (Low 2 octets) Contains the Peer's 2164 Call ID for the session to which this 2165 packet belongs. 2167 Sequence Number Contains the sequence number of the 2168 payload. Present if S bit (Bit 3) is one 2169 (1). 2171 Acknowledgment Number Contains the sequence number of the 2172 highest numbered GRE packet received by 2173 the sending peer for this user session. 2174 Present if A bit (Bit 8) is one (1). 2176 The payload section contains a PPP data packet without any media 2177 specific framing elements. 2179 The sequence numbers involved are per packet sequence numbers. The 2180 sequence number for each user session is set to zero at session 2181 startup. Each packet sent for a given user session which contains a 2182 payload (and has the S bit (Bit 3) set to one) is assigned the next 2183 consecutive sequence number for that session. 2185 This protocol allows acknowledgments to be carried with the data and 2186 makes the overall protocol more efficient, which in turn requires 2187 less buffering of packets. 2189 4.2 Sliding Window Protocol 2191 The sliding window protocol used on the PPTP data path is used for 2192 flow control by each side of the data exchange. The enhanced GRE 2193 protocol allows packet acknowledgments to be piggybacked on data 2194 packets. Acknowledgments can also be sent separately from data 2195 packets. Again, the main purpose of the sliding window protocol is 2196 for flow control--retransmissions are not performed by the tunnel 2197 peers. 2199 4.3 Multi Packet Acknowledgment 2201 One feature of the PPTP sliding window protocol is that it allows the 2202 acknowledgment of multiple packets with a single acknowledgment. All 2203 outstanding packets with a sequence number lower or equal to the 2204 acknowledgment number are considered acknowledged. Time-out 2205 calculations are performed using the time the packet corresponding to 2206 the highest sequence number being acknowledged was transmitted. 2208 Adaptive time-out calculations are only performed when an 2209 Acknowledgment is received. When multi-packet acknowledgments are 2210 used, the overhead of the adaptive time-out algorithm is reduced. The 2211 PAC is not required to transmit multi-packet acknowledgments; it can 2212 instead acknowledge each packet individually as it is delivered to 2213 the PPP client. 2215 4.4 Out-of-Sequence Packets 2217 Occasionally packets lose their sequencing across a complicated 2218 internetwork. Say, for example that a PNS sends packets 0 to 5 to a 2219 PAC. Because of rerouting in the internetwork, packet 4 arrives at 2220 the PAC before packet 3. The PAC acknowledges packet 4, and may 2221 assume packet 3 is lost. This acknowledgment grants window credit 2222 beyond packet 4. 2224 When the PAC does receive packet 3, it MUST not attempt to transmit 2225 it to the corresponding PPP client. To do so could cause problems, 2226 as proper PPP protocol operation is premised upon receiving packets 2227 in sequence. PPP does properly deal with the loss of packets, but 2228 not with reordering so out of sequence packets between the PNS and 2229 PAC MUST be silently discarded, or they may be reordered by the 2230 receiver. When packet 5 comes in, it is acknowledged by the PAC 2231 since it has a higher sequence number than 4, which was the last 2232 highest packet acknowledged by the PAC. Packets with duplicate 2233 sequence numbers should never occur since the PAC and PNS never 2234 retransmit GRE packets. A robust implementation will silently 2235 discard duplicate GRE packets, should it receive any. 2237 5.0 Security Considerations 2239 Security issues are not addressed in this document. End to end 2240 security is addressed by PPP. Further security considerations will be 2241 addressed by the next version of PPTP. 2243 6.0 Authors' Addresses 2245 Kory Hamzeh 2246 Ascend Communications 2247 1275 Harbor Bay Parkway 2248 Alameda, CA 94502 2249 Email: kory@ascend.com 2251 Gurdeep Singh Pall 2252 Microsoft Corporation 2253 Redmond, WA 2254 Email: gurdeep@microsoft.com 2256 William Verthein 2257 U.S. Robotics/3Com 2259 Jeff Taarud 2260 Copper Mountain Networks 2262 W. Andrew Little 2263 ECI Telematics 2265 7.0 References 2267 [1] Hanks, S. Li, T., Farinacci, D. Traina, P., "Generic Routing 2268 Encapsulation (GRE)", RFC 1701, October 1994. 2270 [2] Hanks, S. Li, T., Farinacci, D. Traina, P., "Generic Routing 2271 Encapsulation (GRE) over IPv4 Networks", RFC 1702, October 1994. 2273 [3] Lloyd, B. Simpson, W., "PPP Authentication Protocols", RFC 1334, 2274 October 1992. 2276 [4] Postel, J. B., "Transmission Control Protocol", RFC 791, 2277 September 1981 2279 [5] Postel, J. B., "User Data Protocol", RFC 768, August 1980. 2281 [6] Reynolds, J., Postel, J., "Assigned Numbers", RFC 1700, October, 2282 1994. 2284 [7] Simpson, W., editor, "The Point-to-Point Protocol (PPP)", RFC 2285 1661, July 1994. 2287 [8] Ethertype for PPP, Reserved with Xerox Corporation. 2289 Appendix A. Acknowledgment Time-Outs 2291 PPTP uses sliding windows and time-outs to provide both user session 2292 flow-control across the internetwork and to perform efficient data 2293 buffering to keep the PAC-PNS data channels full without causing 2294 receive buffer overflow. PPTP requires that a time-out be used to 2295 recover from dropped data or acknowledgment packets. The exact 2296 implementation of the time-out is vendor-specific. It is suggested 2297 that an adaptive time-out be implemented with backoff for congestion 2298 control. The time-out mechanism proposed here has the following 2299 properties: 2301 Independent time-outs for each session. A device (PAC or PNS) will 2302 have to maintain and calculate time-outs for every active session. 2304 An administrator-adjustable maximum time-out, MaxTimeOut, unique 2305 to each device. 2307 An adaptive time-out mechanism that compensates for changing 2308 throughput. To reduce packet processing overhead, vendors may 2309 choose not to recompute the adaptive time-out for every received 2310 acknowledgment. The result of this overhead reduction is that the 2311 time-out will not respond as quickly to rapid network changes. 2313 Timer backoff on time-out to reduce congestion. The backed-off 2314 timer value is limited by the configurable maximum time-out value. 2315 Timer backoff is done every time an acknowledgment time-out 2316 occurs. 2318 In general, this mechanism has the desirable behavior of quickly 2319 backing off upon a time-out and of slowly decreasing the time-out 2320 value as packets are delivered without time-outs. 2322 Some definitions: 2324 Packet Processing Delay (PPD) is the amount of time required for 2325 each side to process the maximum amount of data buffered in their 2326 receive packet sliding window. The PPD is the value exchanged 2327 between the PAC and PNS when a call is established. For the PNS, 2328 this number should be small. For a PAC making modem connections, 2329 this number could be significant. 2331 Sample is the actual amount of time incurred receiving an 2332 acknowledgment for a packet. The Sample is measured, not 2333 calculated. 2335 Round-Trip Time (RTT) is the estimated round-trip time for an 2336 Acknowledgment to be received for a given transmitted packet. When 2337 the network link is a local network, this delay will be minimal 2338 (if not zero). When the network link is the Internet, this delay 2339 could be substantial and vary widely. RTT is adaptive: it will 2340 adjust to include the PPD and whatever shifting network delays 2341 contribute to the time between a packet being transmitted and 2342 receiving its acknowledgment. 2344 Adaptive Time-Out (ATO) is the time that must elapse before an 2345 acknowledgment is considered lost. After a time-out, the sliding 2346 window is partially closed and the ATO is backed off. 2348 Packet Processing Delay (PPD) 2350 The PPD parameter is a 16-bit word exchanged during the Call Control 2351 phase that represents tenths of a second (64 means 6.4 seconds). The 2352 protocol only specifies that the parameter is exchanged, it does not 2353 specify how it is calculated. The way values for PPD are calculated 2354 is implementation-dependent and need not be variable (static time- 2355 outs are allowed). The PPD must be exchanged in the call connect 2356 sequences, even if it remains constant in an implementation. One 2357 possible way to calculate the PPD is: 2359 PPD' = ((PPP_MAX_DATA_MTU - Header) * WindowSize * 8) / ConnectRate 2360 PPD = PPD' + PACFudge 2362 Header is the total size of the IP and GRE headers, which is 36. The 2363 MTU is the overall MTU for the internetwork link between the PAC and 2364 PNS. WindowSize represents the number of packets in the sliding 2365 window, and is implementation-dependent. The latency of the 2366 internetwork could be used to pick a window size sufficient to keep 2367 the current session's pipe full. The constant 8 converts octets to 2368 bits (assuming ConnectRate is in bits per second). If ConnectRate is 2369 in bytes per second, omit the 8. PACFudge is not required but can be 2370 used to take overall processing overhead of the PAC into account. 2372 The value of PPD is used to seed the adaptive algorithm with the 2373 initial RTT[n-1] value. 2375 Sample 2377 Sample is the actual measured time for a returned acknowledgment. 2379 Round-Trip Time (RTT) 2381 The RTT value represents an estimate of the average time it takes for 2382 an acknowledgment to be received after a packet is sent to the remote 2383 end of the tunnel. 2385 A.1 Calculating Adaptive Acknowledgment Time-Out 2387 We still must decide how much time to allow for acknowledgments to 2388 return. If the time-out is set too high, we may wait an unnecessarily 2389 long time for dropped packets. If the time-out is too short, we may 2390 time out just before the acknowledgment arrives. The acknowledgment 2391 time-out should also be reasonable and responsive to changing network 2392 conditions. 2394 The suggested adaptive algorithm detailed below is based on the TCP 2395 1989 implementation and is explained in Richard Steven's book TCP/IP 2396 Illustrated, Volume 1 (page 300). 'n' means this iteration of the 2397 calculation, and 'n-1' refers to values from the last calculation. 2399 DIFF[n] = SAMPLE[n] - RTT[n-1] 2400 DEV[n] = DEV[n-1] + (beta * (|DIFF[n]| - DEV[n-1])) 2401 RTT[n] = RTT[n-1] + (alpha * DIFF[n]) 2402 ATO[n] = MIN (RTT[n] + (chi * DEV[n]), MaxTimeOut) 2404 DIFF represents the error between the last estimated round-trip 2405 time and the measured time. DIFF is calculated on each iteration. 2407 DEV is the estimated mean deviation. This approximates the 2408 standard deviation. DEV is calculated on each iteration and 2409 stored for use in the next iteration. Initially, it is set to 0. 2411 RTT is the estimated round-trip time of an average packet. RTT is 2412 calculated on each iteration and stored for use in the next 2413 iteration. Initially, it is set to PPD. 2415 ATO is the adaptive time-out for the next transmitted packet. ATO 2416 is calculated on each iteration. Its value is limited, by the MIN 2417 function, to be a maximum of the configured MaxTimeOut value. 2419 Alpha is the gain for the average and is typically 1/8 (0.125). 2421 Beta is the gain for the deviation and is typically 1/4 (0.250). 2423 Chi is the gain for the time-out and is typically set to 4. 2425 To eliminate division operations for fractional gain elements, the 2426 entire set of equations can be scaled. With the suggested gain 2427 constants, they should be scaled by 8 to eliminate all division. To 2428 simplify calculations, all gain values are kept to powers of two so 2429 that shift operations can be used in place of multiplication or 2430 division. 2432 A.2 Congestion Control: Adjusting for Time-Out 2434 This section describes how the calculation of ATO is modified in the 2435 case where a time-out does occur. When a time-out occurs, the time- 2436 out value should be adjusted rapidly upward. Although the GRE 2437 packets are not retransmitted when a time-out occurs, the time-out 2438 should be adjusted up toward a maximum limit. To compensate for 2439 shifting internetwork time delays, a strategy must be employed to 2440 increase the time-out when it expires. A simple formula called 2441 Karn's Algorithm is used in TCP implementations and may be used in 2442 implementing the backoff timers for the PNS or the PAC. Notice that 2443 in addition to increasing the time-out, we are also shrinking the 2444 size of the window as described in the next section. 2446 Karn's timer backoff algorithm, as used in TCP, is: 2448 NewTIMEOUT = delta * TIMEOUT 2450 Adapted to our time-out calculations, for an interval in which a 2451 time-out occurs, the new ATO is calculated as: 2453 RTT[n] = delta * RTT[n-1] 2454 DEV[n] = DEV[n-1] 2455 ATO[n] = MIN (RTT[n] + (chi * DEV[n]), MaxTimeOut) 2457 In this modified calculation of ATO, only the two values that 2458 contribute to ATO and that are stored for the next iteration are 2459 calculated. RTT is scaled by chi, and DEV is unmodified. DIFF is not 2460 carried forward and is not used in this scenario. A value of 2 for 2461 Delta, the time-out gain factor for RTT, is suggested. 2463 Appendix B. Acknowledgment Time-Out and Window Adjustment 2465 B.1 Initial Window Size 2467 Although each side has indicated the maximum size of its receive 2468 window, it is recommended that a slow start method be used to begin 2469 transmitting data. The initial window size on the transmitter is set 2470 to half the maximum size the receiver requested, with a minimum size 2471 of one packet. The transmitter stops sending packets when the number 2472 of packets awaiting acknowledgment is equal to the current window 2473 size. As the receiver successfully digests each window, the window 2474 size on the transmitter is bumped up by one packet until the maximum 2475 is reached. This method prevents a system from flooding an already 2476 congested network because no history has been established. 2478 B.2 Closing the Window 2480 When a time-out does occur on a packet, the sender adjusts the size 2481 of the transmit window down to one half its value when it failed. 2482 Fractions are rounded up, and the minimum window size is one. 2484 B.3 Opening the Window 2486 With every successful transmission of a window's worth of packets 2487 without a time-out, the transmit window size is increased by one 2488 packet until it reaches the maximum window size that was sent by the 2489 other side when the call was connected. As stated earlier, no 2490 retransmission is done on a time-out. After a time-out, the 2491 transmission resumes with the window starting at one half the size of 2492 the transmit window when the time-out occurred and adjusting upward 2493 by one each time the transmit window is filled with packets that are 2494 all acknowledged without time-outs. 2496 B.4 Window Overflow 2498 When a receiver's window overflows with too many incoming packets, 2499 excess packets are thrown away. This situation should not arise if 2500 the sliding window procedures are being properly followed by the 2501 transmitter and receiver. It is assumed that, on the transmit side, 2502 packets are buffered for transmission and are no longer accepted from 2503 the packet source when the transmit buffer fills.