tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search

RFC 2637

 Errata 
Informational
Pages: 57
Top     in Index     Prev     Next
in Group Index     Prev in Group     Next in Group     Group: PPPEXT

Point-to-Point Tunneling Protocol (PPTP)

Part 1 of 2, p. 1 to 25
None       Next RFC Part

 


Top       ToC       Page 1 
Network Working Group                                          K. Hamzeh
Request for Comments: 2637                         Ascend Communications
Category: Informational                                          G. Pall
                                                   Microsoft Corporation
                                                             W. Verthein
                                                                    3Com
                                                               J. Taarud
                                                Copper Mountain Networks
                                                               W. Little
                                                          ECI Telematics
                                                                 G. Zorn
                                                   Microsoft Corporation
                                                               July 1999


                Point-to-Point Tunneling Protocol (PPTP)

Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (1999).  All Rights Reserved.

IESG Note

   The PPTP protocol was developed by a vendor consortium. The
   documentation of PPTP is provided as information to the Internet
   community. The PPP WG is currently defining a Standards Track
   protocol (L2TP) for tunneling PPP across packet-switched networks.

Abstract

   This document specifies a protocol which allows the Point to Point
   Protocol (PPP) to be tunneled through an IP network.  PPTP does not
   specify any changes to the PPP protocol but rather describes a new
   vehicle for carrying PPP.  A client-server architecture is defined in
   order to decouple functions which exist in current Network Access
   Servers (NAS) and support Virtual Private Networks (VPNs).  The PPTP
   Network Server (PNS) is envisioned to run on a general purpose
   operating system while the client, referred to as a PPTP Access
   Concentrator (PAC) operates on a dial access platform.  PPTP
   specifies a call-control and management protocol which allows the
   server to control access for dial-in circuit switched calls
   originating from a PSTN or ISDN or to initiate outbound circuit-

Page 2 
   switched connections.  PPTP uses an enhanced GRE (Generic Routing
   Encapsulation) mechanism to provide a flow- and congestion-controlled
   encapsulated datagram service for carrying PPP packets.

Specification of Requirements

   In this document, the key words "MAY", "MUST, "MUST NOT", "optional",
   "recommended", "SHOULD", and "SHOULD NOT" are to be interpreted as
   described in [12].

   The words "silently discard", when used in reference to the behavior
   of an implementation upon receipt of an incoming packet, are to be
   interpreted as follows: the implementation discards the datagram
   without further processing, and without indicating an error to the
   sender.  The implementation SHOULD provide the capability of logging
   the error, including the contents of the discarded datagram, and
   SHOULD record the event in a statistics counter.

Table of Contents

   1. Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   1.1.  Protocol Goals and Assumptions . . . . . . . . . . . . . .   4
   1.2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .   5
   1.3.  Protocol Overview  . . . . . . . . . . . . . . . . . . . .   6
   1.3.1.  Control Connection Overview  . . . . . . . . . . . . . .   7
   1.3.2.  Tunnel Protocol Overview . . . . . . . . . . . . . . . .   7
   1.4.  Message Format and Protocol Extensibility  . . . . . . . .   8
   2.  Control Connection Protocol Specification  . . . . . . . . .  10
   2.1.  Start-Control-Connection-Request . . . . . . . . . . . . .  10
   2.2.  Start-Control-Connection-Reply . . . . . . . . . . . . . .  12
   2.3.  Stop-Control-Connection-Request  . . . . . . . . . . . . .  15
   2.4.  Stop-Control-Connection-Reply  . . . . . . . . . . . . . .  16
   2.5.  Echo-Request . . . . . . . . . . . . . . . . . . . . . . .  17
   2.6.  Echo-Reply . . . . . . . . . . . . . . . . . . . . . . . .  18
   2.7.  Outgoing-Call-Request  . . . . . . . . . . . . . . . . . .  19
   2.8.  Outgoing-Call-Reply  . . . . . . . . . . . . . . . . . . .  22
   2.9.  Incoming-Call-Request  . . . . . . . . . . . . . . . . . .  25
   2.10.  Incoming-Call-Reply . . . . . . . . . . . . . . . . . . .  28
   2.11.  Incoming-Call-Connected . . . . . . . . . . . . . . . . .  29
   2.12.  Call-Clear-Request  . . . . . . . . . . . . . . . . . . .  31
   2.13.  Call-Disconnect-Notify  . . . . . . . . . . . . . . . . .  32
   2.14.  WAN-Error-Notify  . . . . . . . . . . . . . . . . . . . .  33
   2.15.  Set-Link-Info . . . . . . . . . . . . . . . . . . . . . .  35
   2.16.  General Error Codes . . . . . . . . . . . . . . . . . . .  36
   3.  Control Connection Protocol Operation  . . . . . . . . . . .  36
   3.1.  Control Connection States  . . . . . . . . . . . . . . . .  37
   3.1.1.  Control Connection Originator (may be PAC or PNS)  . . .  37
   3.1.2.  Control connection Receiver (may be PAC or PNS)  . . . .  39

Top      ToC       Page 3 
   3.1.3.  Start Control Connection Initiation Request Collision  .  40
   3.1.4.  Keep Alives and Timers . . . . . . . . . . . . . . . . .  40
   3.2.  Call States  . . . . . . . . . . . . . . . . . . . . . . .  41
   3.2.1.  Timing considerations  . . . . . . . . . . . . . . . . .  41
   3.2.2.  Call ID Values . . . . . . . . . . . . . . . . . . . . .  41
   3.2.3.  Incoming Calls . . . . . . . . . . . . . . . . . . . . .  41
   3.2.3.1.  PAC Incoming Call States . . . . . . . . . . . . . . .  42
   3.2.3.2.  PNS Incoming Call States . . . . . . . . . . . . . . .  43
   3.2.4.  Outgoing Calls . . . . . . . . . . . . . . . . . . . . .  44
   3.2.4.1.  PAC Outgoing Call States . . . . . . . . . . . . . . .  45
   3.2.4.2.  PNS Outgoing Call States . . . . . . . . . . . . . . .  46
   4.  Tunnel Protocol Operation  . . . . . . . . . . . . . . . . .  47
   4.1.  Enhanced GRE header  . . . . . . . . . . . . . . . . . . .  47
   4.2.  Sliding Window Protocol  . . . . . . . . . . . . . . . . .  49
   4.2.1.  Initial Window Size  . . . . . . . . . . . . . . . . . .  49
   4.2.2.  Closing the Window . . . . . . . . . . . . . . . . . . .  49
   4.2.3.  Opening the Window . . . . . . . . . . . . . . . . . . .  50
   4.2.4.  Window Overflow  . . . . . . . . . . . . . . . . . . . .  50
   4.2.5.  Multi-packet Acknowledgment  . . . . . . . . . . . . . .  50
   4.3.  Out-of-sequence Packets  . . . . . . . . . . . . . . . . .  50
   4.4.  Acknowledgment Time-Outs . . . . . . . . . . . . . . . . .  51
   4.4.1.  Calculating Adaptive Acknowledgment Time-Out . . . . . .  53
   4.4.2.  Congestion Control: Adjusting for Time-Out . . . . . . .  54
   5.  Security Considerations  . . . . . . . . . . . . . . . . . .  54
   6.  Authors' Addresses . . . . . . . . . . . . . . . . . . . . .  55
   7.  References . . . . . . . . . . . . . . . . . . . . . . . . .  56
   8.  Full Copyright Statement . . . . . . . . . . . . . . . . . .  57

1.  Introduction

   PPTP allows existing Network Access Server (NAS) functions to be
   separated using a client-server architecture. Traditionally, the
   following functions are implemented by a NAS:

      1) Physical native interfacing to PSTN or ISDN and control of
         external modems or terminal adapters.

         A NAS may interface directly to a telco analog or digital
         circuit or attach via an external modem or terminal adapter.
         Control of a circuit-switched connection is accomplished with
         either modem control or DSS1 ISDN call control protocols.

         The NAS, in conjunction with the modem or terminal adapters,
         may perform rate adaption, analog to digital conversion, sync
         to async conversion or a number of other alterations of data
         streams.

Top      ToC       Page 4 
      2) Logical termination of a Point-to-Point-Protocol (PPP) Link
         Control Protocol (LCP) session.

      3) Participation in PPP authentication protocols [3,9,10].

      4) Channel aggregation and bundle management for PPP Multilink
         Protocol.

      5) Logical termination of various PPP network control protocols
         (NCP).

      6) Multiprotocol routing and bridging between NAS interfaces.

   PPTP divides these functions between the PAC and PNS. The PAC is
   responsible for functions 1, 2, and possibly 3. The PNS may be
   responsible for function 3 and is responsible for functions 4, 5, and
   6.  The protocol used to carry PPP protocol data units (PDUs) between
   the PAC and PNS, as well as call control and management is addressed
   by PPTP.

   The decoupling of NAS functions offers these benefits:

      Flexible IP address management. Dial-in users may maintain a
      single IP address as they dial into different PACs as long as they
      are served from a common PNS. If an enterprise network uses
      unregistered addresses, a PNS associated with the enterprise
      assigns addresses meaningful to the private network.

      Support of non-IP protocols for dial networks behind IP networks.
      This allows Appletalk and IPX, for example to be tunneled through
      an IP-only provider. The PAC need not be capable of processing
      these protocols.

      A solution to the "multilink hunt-group splitting" problem.
      Multilink PPP, typically used to aggregate ISDN B channels,
      requires that all of the channels composing a multilink bundle be
      grouped at a single NAS.  Since a multilink PPP bundle can be
      handled by a single PNS, the channels comprising the bundle may be
      spread across multiple PACs.

1.1.  Protocol Goals and Assumptions

   The PPTP protocol is implemented only by the PAC and PNS. No other
   systems need to be aware of PPTP. Dial networks may be connected to a
   PAC without being aware of PPTP. Standard PPP client software should
   continue to operate on tunneled PPP links.

Top      ToC       Page 5 
   PPTP can also be used to tunnel a PPP session over an IP network. In
   this configuration the PPTP tunnel and the PPP session runs between
   the same two machines with the caller acting as a PNS.

   It is envisioned that there will be a many-to-many relationship
   between PACs and PNSs.  A PAC may provide service to many PNSs. For
   example, an Internet service provider may choose to support PPTP for
   a number of private network clients and create VPNs for them. Each
   private network may operate one or more PNSs. A single PNS may
   associate with many PACs to concentrate traffic from a large number
   of geographically diverse sites.

   PPTP uses an extended version of GRE to carry user PPP packets. These
   enhancements allow for low-level congestion and flow control to be
   provided on the tunnels used to carry user data between PAC and PNS.
   This mechanism allows for efficient use of the bandwidth available
   for the tunnels and avoids unnecessary retransmisions and buffer
   overruns.  PPTP does not dictate the particular algorithms to be used
   for this low level control but it does define the parameters that
   must be communicated in order to allow such algorithms to work.
   Suggested algorithms are included in section 4.

1.2.  Terminology

   Analog Channel

      A circuit-switched communication path which is intended to carry
      3.1 Khz audio in each direction.

   Digital Channel

      A circuit-switched communication path which is intended to carry
      digital information in each direction.

   Call

      A connection or attempted connection between two terminal
      endpoints on a PSTN or ISDN -- for example, a telephone call
      between two modems.

   Control Connection

      A control connection is created for each PAC, PNS pair and
      operates over TCP [4]. The control connection governs aspects of
      the tunnel and of sessions assigned to the tunnel.

Top      ToC       Page 6 
   Dial User

      An end-system or router attached to an on-demand PSTN or ISDN
      which is either the initiator or recipient of a call.

   Network Access Server (NAS)

      A device providing temporary, on-demand network access to users.
      This access is point-to-point using PSTN or ISDN lines.

   PPTP Access Concentrator (PAC)

      A device attached to one or more PSTN or ISDN lines capable of PPP
      operation and of handling the PPTP protocol. The PAC need only
      implement TCP/IP to pass traffic to one or more PNSs. It may also
      tunnel non-IP protocols.

   PPTP Network Server (PNS)

      A PNS is envisioned to operate on general-purpose computing/server
      platforms. The PNS handles the server side of the PPTP protocol.
      Since PPTP relies completely on TCP/IP and is independent of the
      interface hardware, the PNS may use any combination of IP
      interface hardware including LAN and WAN devices.

   Session

      PPTP is connection-oriented.  The PNS and PAC maintain state for
      each user that is attached to a PAC.  A session is created when
      end-to-end PPP connection is attempted between a dial user and the
      PNS.  The datagrams related to a session are sent over the tunnel
      between the PAC and PNS.

   Tunnel

      A tunnel is defined by a PNS-PAC pair.  The tunnel protocol is
      defined by a modified version of GRE [1,2].  The tunnel carries
      PPP datagrams between the PAC and the PNS.  Many sessions are
      multiplexed on a single tunnel.  A control connection operating
      over TCP controls the establishment, release, and maintenance of
      sessions and of the tunnel itself.

1.3.  Protocol Overview

   There are two parallel components of PPTP: 1) a Control Connection
   between each PAC-PNS pair operating over TCP and 2) an IP tunnel
   operating between the same PAC-PNS pair which is used to transport
   GRE encapsulated PPP packets for user sessions between the pair.

Top      ToC       Page 7 
1.3.1.  Control Connection Overview

   Before PPP tunneling can occur between a PAC and PNS, a control
   connection must be established between them. The control connection
   is a standard TCP session over which PPTP call control and management
   information is passed. The control session is logically associated
   with, but separate from, the sessions being tunneled through a PPTP
   tunnel.  For each PAC-PNS pair both a tunnel and a control connection
   exist. The control connection is responsible for establishment,
   management, and release of sessions carried through the tunnel. It is
   the means by which a PNS is notified of an incoming call at an
   associated PAC, as well as the means by which a PAC is instructed to
   place an outgoing dial call.

   A control connection can be established by either the PNS or the PAC.
   Following the establishment of the required TCP connection, the PNS
   and PAC establish the control connection using the Start-Control-
   Connection-Request and -Reply messages.  These messages are also used
   to exchange information about basic operating capabilities of the PAC
   and PNS.  Once the control connection is established, the PAC or PNS
   may initiate sessions by requesting outbound calls or responding to
   inbound requests. The control connection may communicate changes in
   operating characteristics of an individual user session with a Set-
   Link-Info message.  Individual sessions may be released by either the
   PAC or PNS, also through Control Connection messages.

   The control connection itself is maintained by keep-alive echo
   messages.  This ensures that a connectivity failure between the PNS
   and the PAC can be detected in a timely manner. Other failures can be
   reported via the

   Wan-Error-Notify message, also on the control connection.

   It is intended that the control connection will also carry management
   related messages in the future, such as a message allowing the PNS to
   request the status of a given PAC; these message types have not yet
   been defined.

1.3.2.  Tunnel Protocol Overview

   PPTP requires the establishment of a tunnel for each communicating
   PNS-PAC pair.  This tunnel is used to carry all user session PPP
   packets for sessions involving a given PNS-PAC pair.  A key which is
   present in the GRE header indicates which session a particular PPP
   packet belongs to.

Top      ToC       Page 8 
   In this manner, PPP packets are multiplexed and demultiplexed over a
   single tunnel between a given PNS-PAC pair.  The value to use in the
   key field is established by the call establishment procedure which
   takes place on the control connection.

   The GRE header also contains acknowledgment and sequencing
   information that is used to perform some level of congestion-control
   and error detection over the tunnel.  Again the control connection is
   used to determine rate and buffering parameters that are used to
   regulate the flow of PPP packets for a particular session over the
   tunnel.  PPTP does not specify the particular algorithms to use for
   congestion-control and flow-control.  Suggested algorithms for the
   determination of adaptive time-outs to recover from dropped data or
   acknowledgments on the tunnel are included in section 4.4 of this
   document.

1.4.  Message Format and Protocol Extensibility

   PPTP defines a set of messages sent as TCP data on the control
   connection between a PNS and a given PAC.  The TCP session for the
   control connection is established by initiating a TCP connection to
   port 1723 [6]. The source port is assigned to any unused port number.

   Each PPTP Control Connection message begins with an 8 octet fixed
   header portion.  This fixed header contains the following: the total
   length of the message, the PPTP Message Type indicator, and a "Magic
   Cookie".

   Two Control Connection message types are indicated by the PPTP
   Message Type field:

         1 - Control Message
         2 - Management Message

   Management messages are currently not defined.

   The Magic Cookie is always sent as the constant 0x1A2B3C4D.  Its
   basic purpose is to allow the receiver to ensure that it is properly
   synchronized with the TCP data stream.  It should not be used as a
   means for resynchronizing the TCP data stream in the event that a
   transmitter issues an improperly formatted message.  Loss of
   synchronization must result in immediate closing of the control
   connection's TCP session.

   For clarity, all Control Connection message templates in the next
   section include the entire PPTP Control Connection message header.
   Numbers preceded by 0x are hexadecimal values.

Top      ToC       Page 9 
The currently defined Control Messages, grouped by function, are:

         Control Message                        Message Code

         (Control Connection Management)

         Start-Control-Connection-Request            1
         Start-Control-Connection-Reply              2
         Stop-Control-Connection-Request             3
         Stop-Control-Connection-Reply               4
         Echo-Request                                5
         Echo-Reply                                  6

         (Call Management)

         Outgoing-Call-Request                       7
         Outgoing-Call-Reply                         8
         Incoming-Call-Request                       9
         Incoming-Call-Reply                        10
         Incoming-Call-Connected                    11
         Call-Clear-Request                         12
         Call-Disconnect-Notify                     13

         (Error Reporting)

         WAN-Error-Notify                           14

         (PPP Session Control)

         Set-Link-Info                              15

   The Start-Control-Connection-Request and -Reply messages determine
   which version of the Control Connection protocol will be used.  The
   version number field carried in these messages consists of a version
   number in the high octet and a revision number in the low octet.
   Version handling is described in section 2. The current value of the
   version number field is 0x0100 for version 1, revision 0.

   The use of the GRE-like header for the encapsulation of PPP user
   packets is specified in section 4.1.

   The MTU for the user data packets encapsulated in GRE is 1532 octets,
   not including the IP and GRE headers.

Top      ToC       Page 10 
2.  Control Connection Protocol Specification

   Control Connection messages are used to establish and clear user
   sessions.  The first set of Control Connection messages are used to
   maintain the control connection itself.  The control connection is
   initiated by either the PNS or PAC after they establish the
   underlying TCP connection.  The procedure and configuration
   information required to determine which TCP connections are
   established is not covered by this protocol.

   The following Control Connection messages are all sent as user data
   on the established TCP connection between a given PNS-PAC pair.  Note
   that care has been taken to ensure that all word (2 octet) and
   longword (4 octet) values begin on appropriate boundaries.  All data
   is sent in network order (high order octets first).  Any "reserved"
   fields MUST be sent as 0 values to allow for protocol extensibility.

2.1.  Start-Control-Connection-Request

   The Start-Control-Connection-Request is a PPTP control message used
   to establish the control connection between a PNS and a PAC.  Each
   PNS-PAC pair requires a dedicated control connection to be
   established.  A control connection must be established before any
   other PPTP messages can be issued.  The establishment of the control
   connection can be initiated by either the PNS or PAC.  A procedure
   which handles the occurrence of a collision between PNS and PAC
   Start-Control-Connection-Requests is described in section 3.1.3.

Top      ToC       Page 11 
       0                   1                   2                   3
       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |             Length            |       PPTP Message Type       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Magic Cookie                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Control Message Type      |           Reserved0           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |       Protocol Version        |           Reserved1           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                     Framing Capabilities                      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      Bearer Capabilities                      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |       Maximum Channels        |       Firmware Revision       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                     Host Name (64 octets)                     +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                   Vendor String (64 octets)                   +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Length                   Total length in octets of this PPTP
                               message, including the entire PPTP
                               header.

      PPTP Message Type        1 for Control Message.

      Magic Cookie             0x1A2B3C4D. This constant value is used
                               as a sanity check on received messages
                               (see section 1.4).

      Control Message Type     1 for Start-Control-Connection-Request.

      Reserved0                This field MUST be 0.

      Protocol Version         The version of the PPTP protocol that the
                               sender wishes to use.

      Reserved1                This field MUST be 0.

Top      ToC       Page 12 
   Framing Capabilities     A set of bits indicating the type of framing
                            that the sender of this message can provide.
                            The currently defined bit settings are:

                               1 - Asynchronous Framing supported

                               2 - Synchronous Framing supported

   Bearer Capabilities      A set of bits indicating the bearer
                            capabilities that the sender of this message
                            can provide.  The currently defined bit
                            settings are:

                               1 - Analog access supported

                               2 - Digital access supported

   Maximum Channels         The total number of individual PPP sessions
                            this PAC can support.  In Start-Control-
                            Connection-Requests issued by the PNS, this
                            value SHOULD be set to 0.  It MUST be
                            ignored by the PAC.

   Firmware Revision        This field contains the firmware revision
                            number of the issuing PAC, when issued by
                            the PAC, or the version of the PNS PPTP
                            driver if issued by the PNS.

   Host Name                A 64 octet field containing the DNS name of
                            the issuing PAC or PNS.  If less than 64
                            octets in length, the remainder of this
                            field SHOULD be filled with octets of value
                            0.

   Vendor Name              A 64 octet field containing a vendor
                            specific string describing the type of PAC
                            being used, or the type of PNS software
                            being used if this request is issued by the
                            PNS.  If less than 64 octets in length, the
                            remainder of this field SHOULD be filled
                            with octets of value 0.

2.2.  Start-Control-Connection-Reply

   The Start-Control-Connection-Reply is a PPTP control message sent in
   reply to a received Start-Control-Connection-Request message.  This
   message contains a result code indicating the result of the control
   connection establishment attempt.

Top      ToC       Page 13 
       0                   1                   2                   3
       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |             Length            |       PPTP Message Type       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Magic Cookie                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Control Message Type      |           Reserved0           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |       Protocol Version        |  Result Code  |  Error Code   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      Framing Capability                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       Bearer Capability                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |       Maximum Channels        |       Firmware Revision       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                     Host Name (64 octets)                     +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                   Vendor String (64 octets)                   +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Length                   Total length in octets of this PPTP message,
                            including the entire PPTP header.

   PPTP Message Type        1 for Control Message.

   Magic Cookie             0x1A2B3C4D.

   Control Message Type     2 for Start-Control-Connection-Reply.

   Reserved0                This field MUST be 0.

   Protocol Version         The version of the PPTP protocol that the
                            sender wishes to use.

   Result Code              Indicates the result of the command channel
                            establishment attempt.  Current valid Result
                            Code values are:

                                  1 - Successful channel establishment

                                  2 - General error -- Error Code
                                      indicates the problem

Top      ToC       Page 14 
                                  3 - Command channel already exists;

                                  4 - Requester is not authorized to
                                      establish a command channel

                                  5 - The protocol version of the
                                      requester is not supported

   Error Code               This field is set to 0 unless a "General
                            Error" exists, in which case Result Code is
                            set to 2 and this field is set to the value
                            corresponding to the general error condition
                            as specified in section 2.2.

   Framing Capabilities     A set of bits indicating the type of framing
                            that the sender of this message can provide.
                            The currently defined bit settings are:

                                  1 - Asynchronous Framing supported

                                  2 - Synchronous Framing supported.

   Bearer Capabilities      A set of bits indicating the bearer
                            capabilities that the sender of this message
                            can provide.  The currently defined bit
                            settings are:

                                  1 - Analog access supported

                                  2 - Digital access supported

   Maximum Channels         The total number of individual PPP sessions
                            this PAC can support.  In a Start-Control-
                            Connection-Reply issued by the PNS, this
                            value SHOULD be set to 0 and it must be
                            ignored by the PAC. The PNS MUST NOT use
                            this value to try to track the remaining
                            number of PPP sessions that the PAC will
                            allow.

   Firmware Revision        This field contains the firmware revision
                            number of the issuing PAC, or the version of
                            the PNS PPTP driver if issued by the PNS.

Top      ToC       Page 15 
   Host Name                A 64 octet field containing the DNS name of
                            the issuing PAC or PNS.  If less than 64
                            octets in length, the remainder of this
                            field SHOULD be filled with octets of value
                            0.

   Vendor Name              A 64 octet field containing a vendor
                            specific string describing the type of PAC
                            being used, or the type of PNS software
                            being used if this request is issued by the
                            PNS.  If less than 64 octets in length, the
                            remainder of this field SHOULD be filled
                            with octets of value 0.

2.3.  Stop-Control-Connection-Request

   The Stop-Control-Connection-Request is a PPTP control message sent by
   one peer of a PAC-PNS control connection to inform the other peer
   that the control connection should be closed.  In addition to closing
   the control connection, all active user calls are implicitly cleared.
   The reason for issuing this request is indicated in the Reason field.

       0                   1                   2                   3
       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |             Length            |       PPTP Message Type       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Magic Cookie                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Control Message Type      |           Reserved0           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Reason     |   Reserved1   |           Reserved2           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Length                   Total length in octets of this PPTP message,
                            including the entire PPTP header.

   PPTP Message Type        1 for Control Message.

   Magic Cookie             0x1A2B3C4D.

   Control Message Type     3 for Stop-Control-Connection-Request.

   Reserved0                This field MUST be 0.

   Reason                   Indicates the reason for the control
                            connection being closed. Current valid
                            Reason values are:

Top      ToC       Page 16 
                                  1 (None) - General request to clear
                                    control connection

                                  2 (Stop-Protocol) - Can't support
                                    peer's version of the protocol

                                  3 (Stop-Local-Shutdown) - Requester is
                                    being shut down

      Reserved1, Reserved2     These fields MUST be 0.

2.4.  Stop-Control-Connection-Reply

   The Stop-Control-Connection-Reply is a PPTP control message sent by
   one peer of a PAC-PNS control connection upon receipt of a Stop-
   Control-Connection-Request from the other peer.

       0                   1                   2                   3
       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |            Length             |       PPTP Message Type       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Magic Cookie                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Control Message Type      |           Reserved0           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Result Code  |   Error Code  |           Reserved1           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Length                   Total length in octets of this PPTP message,
                            including the entire PPTP header.

   PPTP Message Type        1 for Control Message.

   Magic Cookie             0x1A2B3C4D.

   Control Message Type     4 for Stop-Control-Connection-Reply.

   Reserved0                This field MUST be 0.

   Result Code              Indicates the result of the attempt to close
                            the control connection. Current valid Result
                            Code values are:

Top      ToC       Page 17 
                                  1 (OK) - Control connection closed

                                  2 (General Error) - Control connection
                                    not closed for reason indicated in
                                    Error Code

   Error Code               This field is set to 0 unless a "General
                            Error" exists, in which case Result Code is
                            set to 2 and this field is set to the value
                            corresponding to the general error condition
                            as specified in section 2.2.

   Reserved1                This field MUST be 0.

2.5.  Echo-Request

   The Echo-Request is a PPTP control message sent by either peer of a
   PAC-PNS control connection. This control message is used as a "keep-
   alive" for the control connection.  The receiving peer issues an
   Echo-Reply to each Echo-Request received. As specified in section
   3.1.4, if the sender does not receive an Echo-Reply in response to an
   Echo-Request, it will eventually clear the control connection.

       0                   1                   2                   3
       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |            Length             |       PPTP Message Type       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Magic Cookie                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Control Message Type      |           Reserved0           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          Identifier                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Length                   Total length in octets of this PPTP message,
                            including the entire PPTP header.

   PPTP Message Type        1 for Control Message.

   Magic Cookie             0x1A2B3C4D.

   Control Message Type     5 for Echo-Request.

   Reserved0                This field MUST be 0.

Top      ToC       Page 18 
   Identifier               A value set by the sender of the Echo-
                            Request that is used to match the reply with
                            the corresponding request.

2.6.  Echo-Reply

   The Echo-Reply is a PPTP control message sent by either peer of a
   PAC-PNS control connection in response to the receipt of an Echo-
   Request.

       0                   1                   2                   3
       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |            Length             |      PPTP Message Type        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Magic Cookie                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Control Message Type      |           Reserved0           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          Identifier                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Result Code  |   Error Code  |           Reserved1           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Length                   Total length in octets of this PPTP message,
                            including the entire PPTP header.

   PPTP Message Type        1 for Control Message.

   Magic Cookie             0x1A2B3C4D.

   Control Message Type     6 for Echo-Reply.

   Reserved0                This field MUST be 0.

   Identifier               The contents of the identify field from the
                            received Echo-Request is copied to this
                            field.

   Result Code              Indicates the result of the receipt of the
                            Echo-Request. Current valid Result Code
                            values are:

                                  1 (OK) - The Echo-Reply is valid

                                  2 (General Error) - Echo-Request not
                                    accepted for the reason indicated in
                                    Error Code

Top      ToC       Page 19 
   Error Code               This field is set to 0 unless a "General
                            Error" condition exists, in which case
                            Result Code is set to 2 and this field is
                            set to the value corresponding to the
                            general error condition as specified in
                            section 2.2.

   Reserved1                This field MUST be 0.

2.7.  Outgoing-Call-Request

   The Outgoing-Call-Request is a PPTP control message sent by the PNS
   to the PAC to indicate that an outbound call from the PAC is to be
   established.  This request provides the PAC with information required
   to make the call. It also provides information to the PAC that is
   used to regulate the transmission of data to the PNS for this session
   once it is established.

Top      ToC       Page 20 
       0                   1                   2                   3
       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |            Length             |       PPTP Message Type       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Magic Cookie                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Control Message Type      |           Reserved0           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |            Call ID            |      Call Serial Number       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          Minimum BPS                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          Maximum BPS                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          Bearer Type                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Framing Type                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Packet Recv. Window Size    |    Packet Processing Delay    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |      Phone Number Length      |           Reserved1           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                   Phone Number (64 octets)                    +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                    Subaddress (64 octets)                     +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Length                   Total length in octets of this PPTP message,
                            including the entire PPTP header.

   PPTP Message Type        1 for Control Message.

   Magic Cookie             0x1A2B3C4D.

   Control Message Type     7 for Outgoing-Call-Request.

   Reserved0                This field MUST be 0.

Top      ToC       Page 21 
   Call ID                  A unique identifier, unique to a particular
                            PAC-PNS pair assigned by the PNS to this
                            session.  It is used to multiplex and
                            demultiplex data sent over the tunnel
                            between the PNS and PAC involved in this
                            session.

   Call Serial Number       An identifier assigned by the PNS to this
                            session for the purpose of identifying this
                            particular session in logged session
                            information.  Unlike the Call ID, both the
                            PNS and PAC associate the same Call Serial
                            Number with a given session. The combination
                            of IP address and call serial number SHOULD
                            be unique.

   Minimum BPS              The lowest acceptable line speed (in
                            bits/second) for this session.

   Maximum BPS              The highest acceptable line speed (in
                            bits/second) for this session.

   Bearer Type              A value indicating the bearer capability
                            required for this outgoing call.  The
                            currently defined values are:

                                  1 - Call to be placed on an analog
                                      channel

                                  2 - Call to be placed on a digital
                                      channel

                                  3 - Call can be placed on any type of
                                      channel

   Framing Type             A value indicating the type of PPP framing
                            to be used for this outgoing call.

                                  1 - Call to use Asynchronous framing

                                  2 - Call to use Synchronous framing

                                  3 - Call can use either type of
                                      framing

   Packet Recv. Window Size The number of received data packets the PNS
                            will buffer for this session.

Top      ToC       Page 22 
   Packet Processing Delay  A measure of the packet processing delay
                            that might be imposed on data sent to the
                            PNS from the PAC.  This value is specified
                            in units of 1/10 seconds.  For the PNS this
                            number should be very small.  See section
                            4.4 for a description of how this value is
                            determined and used.

   Phone Number Length      The actual number of valid digits in the
                            Phone Number field.

   Reserved1                This field MUST be 0.

   Phone Number             The number to be dialed to establish the
                            outgoing session.  For ISDN and analog calls
                            this field is an ASCII string.  If the Phone
                            Number is less than 64 octets in length, the
                            remainder of this field is filled with
                            octets of value 0.

   Subaddress               A 64 octet field used to specify additional
                            dialing information.  If the subaddress is
                            less than 64 octets long, the remainder of
                            this field is filled with octets of value 0.

2.8.  Outgoing-Call-Reply

   The Outgoing-Call-Reply is a PPTP control message sent by the PAC to
   the PNS in response to a received Outgoing-Call-Request message.  The
   reply indicates the result of the outgoing call attempt.  It also
   provides information to the PNS about particular parameters used for
   the call.  It provides information to allow the PNS to regulate the
   transmission of data to the PAC for this session.

Top      ToC       Page 23 
       0                   1                   2                   3
       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |            Length             |      PPTP Message Type        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Magic Cookie                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Control Message Type      |           Reserved0           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |            Call ID            |       Peer's Call ID          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Result Code  |  Error Code   |          Cause Code           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Connect Speed                         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Packet Recv. Window Size    |    Packet Processing Delay    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      Physical Channel ID                      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Length                   Total length in octets of this PPTP message,
                            including the entire PPTP header.

   PPTP Message Type        1 for Control Message.

   Magic Cookie             0x1A2B3C4D.

   Control Message Type     8 for Outgoing-Call-Reply.

   Reserved0                This field MUST be 0.

   Call ID                  A unique identifier for the tunnel, assigned
                            by the PAC to this session.  It is used to
                            multiplex and demultiplex data sent over the
                            tunnel between the PNS and PAC involved in
                            this session.

   Peer's Call ID           This field is set to the value received in
                            the Call ID field of the corresponding
                            Outgoing-Call-Request message.  It is used
                            by the PNS to match the Outgoing-Call-Reply
                            with the Outgoing-Call-Request it issued. It
                            also is used as the value sent in the GRE
                            header for mux/demuxing.

Top      ToC       Page 24 
   Result Code              This value indicates the result of the
                            Outgoing-Call-Request attempt.  Currently
                            valid values are:

                                  1 (Connected) - Call established with
                                    no errors

                                  2 (General Error) - Outgoing Call not
                                    established for the reason indicated
                                    in Error Code

                                  3 (No Carrier) - Outgoing Call failed
                                    due to no carrier detected

                                  4 (Busy) - Outgoing Call failed due to
                                    detection of a busy signal

                                  5 (No Dial Tone) - Outgoing Call
                                    failed due to lack of a dial tone

                                  6 (Time-out) - Outgoing Call was not
                                    established within time allotted by
                                    PAC

                                  7 (Do Not Accept) - Outgoing Call
                                    administratively prohibited

   Error Code               This field is set to 0 unless a "General
                            Error" condition exists, in which case
                            Result Code is set to 2 and this field is
                            set to the value corresponding to the
                            general error condition as specified in
                            section 2.2.

   Cause Code               This field gives additional failure
                            information.  Its value can vary depending
                            upon the type of call attempted.  For ISDN
                            call attempts it is the Q.931 cause code.

   Connect Speed            The actual connection speed used, in
                            bits/second.

   Packet Recv. Window Size The number of received data packets the PAC
                            will buffer for this session.

Top      ToC       Page 25 
   Packet Processing Delay  A measure of the packet processing delay
                            that might be imposed on data sent to the
                            PAC from the PNS.  This value is specified
                            in units of 1/10 seconds.  For the PAC, this
                            number is related to the size of the buffer
                            used to hold packets to be sent to the
                            client and to the speed of the link to the
                            client.  This value should be set to the
                            maximum delay that can normally occur
                            between the time a packet arrives at the PAC
                            and is delivered to the client.  See section
                            4.4 for an example of how this value is
                            determined and used.

   Physical Channel ID      This field is set by the PAC in a vendor-
                            specific manner to the physical channel
                            number used to place this call.  It is used
                            for logging purposes only.



(page 25 continued on part 2)

Next RFC Part