Section 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.
      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.
   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.
   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.
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.
   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.
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.