As per Relevance of the word indicate, we have this rfc below:
Network Working Group K.
Request for Comments: 2637 Ascend
Category: Informational G.
Microsoft
W.
3
J.
Copper Mountain
W.
ECI
G.
Microsoft
July 1999
Point-to-Point Tunneling Protocol (PPTP
Status of this
This memo provides information for the Internet community. It
not specify an Internet standard of any kind. Distribution of
memo is unlimited
Copyright
Copyright (C) The Internet Society (1999). All Rights Reserved
IESG
The PPTP protocol was developed by a vendor consortium.
documentation of PPTP is provided as information to the
community. The PPP WG is currently defining a Standards
protocol (L2TP) for tunneling PPP across packet-switched networks
This document specifies a protocol which allows the Point to
Protocol (PPP) to be tunneled through an IP network. PPTP does
specify any changes to the PPP protocol but rather describes a
vehicle for carrying PPP. A client-server architecture is defined
order to decouple functions which exist in current Network
Servers (NAS) and support Virtual Private Networks (VPNs). The
Network Server (PNS) is envisioned to run on a general
operating system while the client, referred to as a PPTP
Concentrator (PAC) operates on a dial access platform.
specifies a call-control and management protocol which allows
server to control access for dial-in circuit switched
originating from a PSTN or ISDN or to initiate outbound circuit
Hamzeh, et al. Informational [Page 1]
RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
switched connections. PPTP uses an enhanced GRE (Generic
Encapsulation) mechanism to provide a flow- and congestion-
encapsulated datagram service for carrying PPP packets
Specification of
In this document, the key words "MAY", "MUST, "MUST NOT", "optional",
"recommended", "SHOULD", and "SHOULD NOT" are to be interpreted
described in [12].
The words "silently discard", when used in reference to the
of an implementation upon receipt of an incoming packet, are to
interpreted as follows: the implementation discards the
without further processing, and without indicating an error to
sender. The implementation SHOULD provide the capability of
the error, including the contents of the discarded datagram,
SHOULD record the event in a statistics counter
Table of
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
Hamzeh, et al. Informational [Page 2]
RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
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.
PPTP allows existing Network Access Server (NAS) functions to
separated using a client-server architecture. Traditionally,
following functions are implemented by a NAS
1) Physical native interfacing to PSTN or ISDN and control
external modems or terminal adapters
A NAS may interface directly to a telco analog or
circuit or attach via an external modem or terminal adapter
Control of a circuit-switched connection is accomplished
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,
to async conversion or a number of other alterations of
streams
Hamzeh, et al. Informational [Page 3]
RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
2) Logical termination of a Point-to-Point-Protocol (PPP)
Control Protocol (LCP) session
3) Participation in PPP authentication protocols [3,9,10].
4) Channel aggregation and bundle management for PPP
Protocol
5) Logical termination of various PPP network control
(NCP).
6) Multiprotocol routing and bridging between NAS interfaces
PPTP divides these functions between the PAC and PNS. The PAC
responsible for functions 1, 2, and possibly 3. The PNS may
responsible for function 3 and is responsible for functions 4, 5,
6. The protocol used to carry PPP protocol data units (PDUs)
the PAC and PNS, as well as call control and management is
by PPTP
The decoupling of NAS functions offers these benefits
Flexible IP address management. Dial-in users may maintain
single IP address as they dial into different PACs as long as
are served from a common PNS. If an enterprise network
unregistered addresses, a PNS associated with the
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
an IP-only provider. The PAC need not be capable of
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
grouped at a single NAS. Since a multilink PPP bundle can
handled by a single PNS, the channels comprising the bundle may
spread across multiple PACs
1.1. Protocol Goals and
The PPTP protocol is implemented only by the PAC and PNS. No
systems need to be aware of PPTP. Dial networks may be connected to
PAC without being aware of PPTP. Standard PPP client software
continue to operate on tunneled PPP links
Hamzeh, et al. Informational [Page 4]
RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
PPTP can also be used to tunnel a PPP session over an IP network.
this configuration the PPTP tunnel and the PPP session runs
the same two machines with the caller acting as a PNS
It is envisioned that there will be a many-to-many
between PACs and PNSs. A PAC may provide service to many PNSs.
example, an Internet service provider may choose to support PPTP
a number of private network clients and create VPNs for them.
private network may operate one or more PNSs. A single PNS
associate with many PACs to concentrate traffic from a large
of geographically diverse sites
PPTP uses an extended version of GRE to carry user PPP packets.
enhancements allow for low-level congestion and flow control to
provided on the tunnels used to carry user data between PAC and PNS
This mechanism allows for efficient use of the bandwidth
for the tunnels and avoids unnecessary retransmisions and
overruns. PPTP does not dictate the particular algorithms to be
for this low level control but it does define the parameters
must be communicated in order to allow such algorithms to work
Suggested algorithms are included in section 4.
1.2.
Analog
A circuit-switched communication path which is intended to
3.1 Khz audio in each direction
Digital
A circuit-switched communication path which is intended to
digital information in each direction
A connection or attempted connection between two
endpoints on a PSTN or ISDN -- for example, a telephone
between two modems
Control
A control connection is created for each PAC, PNS pair
operates over TCP [4]. The control connection governs aspects
the tunnel and of sessions assigned to the tunnel
Hamzeh, et al. Informational [Page 5]
RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
Dial
An end-system or router attached to an on-demand PSTN or
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
operation and of handling the PPTP protocol. The PAC need
implement TCP/IP to pass traffic to one or more PNSs. It may
tunnel non-IP protocols
PPTP Network Server (PNS
A PNS is envisioned to operate on general-purpose computing/
platforms. The PNS handles the server side of the PPTP protocol
Since PPTP relies completely on TCP/IP and is independent of
interface hardware, the PNS may use any combination of
interface hardware including LAN and WAN devices
PPTP is connection-oriented. The PNS and PAC maintain state
each user that is attached to a PAC. A session is created
end-to-end PPP connection is attempted between a dial user and
PNS. The datagrams related to a session are sent over the
between the PAC and PNS
A tunnel is defined by a PNS-PAC pair. The tunnel protocol
defined by a modified version of GRE [1,2]. The tunnel
PPP datagrams between the PAC and the PNS. Many sessions
multiplexed on a single tunnel. A control connection
over TCP controls the establishment, release, and maintenance
sessions and of the tunnel itself
1.3. Protocol
There are two parallel components of PPTP: 1) a Control
between each PAC-PNS pair operating over TCP and 2) an IP
operating between the same PAC-PNS pair which is used to
GRE encapsulated PPP packets for user sessions between the pair
Hamzeh, et al. Informational [Page 6]
RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
1.3.1. Control Connection
Before PPP tunneling can occur between a PAC and PNS, a
connection must be established between them. The control
is a standard TCP session over which PPTP call control and
information is passed. The control session is logically
with, but separate from, the sessions being tunneled through a
tunnel. For each PAC-PNS pair both a tunnel and a control
exist. The control connection is responsible for establishment
management, and release of sessions carried through the tunnel. It
the means by which a PNS is notified of an incoming call at
associated PAC, as well as the means by which a PAC is instructed
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
and PAC establish the control connection using the Start-Control
Connection-Request and -Reply messages. These messages are also
to exchange information about basic operating capabilities of the
and PNS. Once the control connection is established, the PAC or
may initiate sessions by requesting outbound calls or responding
inbound requests. The control connection may communicate changes
operating characteristics of an individual user session with a Set
Link-Info message. Individual sessions may be released by either
PAC or PNS, also through Control Connection messages
The control connection itself is maintained by keep-alive
messages. This ensures that a connectivity failure between the
and the PAC can be detected in a timely manner. Other failures can
reported via
Wan-Error-Notify message, also on the control connection
It is intended that the control connection will also carry
related messages in the future, such as a message allowing the PNS
request the status of a given PAC; these message types have not
been defined
1.3.2. Tunnel Protocol
PPTP requires the establishment of a tunnel for each
PNS-PAC pair. This tunnel is used to carry all user session
packets for sessions involving a given PNS-PAC pair. A key which
present in the GRE header indicates which session a particular
packet belongs to
Hamzeh, et al. Informational [Page 7]
RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
In this manner, PPP packets are multiplexed and demultiplexed over
single tunnel between a given PNS-PAC pair. The value to use in
key field is established by the call establishment procedure
takes place on the control connection
The GRE header also contains acknowledgment and
information that is used to perform some level of congestion-
and error detection over the tunnel. Again the control connection
used to determine rate and buffering parameters that are used
regulate the flow of PPP packets for a particular session over
tunnel. PPTP does not specify the particular algorithms to use
congestion-control and flow-control. Suggested algorithms for
determination of adaptive time-outs to recover from dropped data
acknowledgments on the tunnel are included in section 4.4 of
document
1.4. Message Format and Protocol
PPTP defines a set of messages sent as TCP data on the
connection between a PNS and a given PAC. The TCP session for
control connection is established by initiating a TCP connection
port 1723 [6]. The source port is assigned to any unused port number
Each PPTP Control Connection message begins with an 8 octet
header portion. This fixed header contains the following: the
length of the message, the PPTP Message Type indicator, and a "
Cookie".
Two Control Connection message types are indicated by the
Message Type field
1 - Control
2 - Management
Management messages are currently not defined
The Magic Cookie is always sent as the constant 0x1A2B3C4D.
basic purpose is to allow the receiver to ensure that it is
synchronized with the TCP data stream. It should not be used as
means for resynchronizing the TCP data stream in the event that
transmitter issues an improperly formatted message. Loss
synchronization must result in immediate closing of the
connection's TCP session
For clarity, all Control Connection message templates in the
section include the entire PPTP Control Connection message header
Numbers preceded by 0x are hexadecimal values
Hamzeh, et al. Informational [Page 8]
RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
The currently defined Control Messages, grouped by function, are
Control Message Message
(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
which version of the Control Connection protocol will be used.
version number field carried in these messages consists of a
number in the high octet and a revision number in the low octet
Version handling is described in section 2. The current value of
version number field is 0x0100 for version 1, revision 0.
The use of the GRE-like header for the encapsulation of PPP
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
Hamzeh, et al. Informational [Page 9]
RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
2. Control Connection Protocol
Control Connection messages are used to establish and clear
sessions. The first set of Control Connection messages are used
maintain the control connection itself. The control connection
initiated by either the PNS or PAC after they establish
underlying TCP connection. The procedure and
information required to determine which TCP connections
established is not covered by this protocol
The following Control Connection messages are all sent as user
on the established TCP connection between a given PNS-PAC pair.
that care has been taken to ensure that all word (2 octet)
longword (4 octet) values begin on appropriate boundaries. All
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-
The Start-Control-Connection-Request is a PPTP control message
to establish the control connection between a PNS and a PAC.
PNS-PAC pair requires a dedicated control connection to
established. A control connection must be established before
other PPTP messages can be issued. The establishment of the
connection can be initiated by either the PNS or PAC. A
which handles the occurrence of a collision between PNS and
Start-Control-Connection-Requests is described in section 3.1.3.
Hamzeh, et al. Informational [Page 10]
RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
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
message, including the entire
header
PPTP Message Type 1 for Control Message
Magic Cookie 0x1A2B3C4D. This constant value is
as a sanity check on received
(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
sender wishes to use
Reserved1 This field MUST be 0.
Hamzeh, et al. Informational [Page 11]
RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
Framing Capabilities A set of bits indicating the type of
that the sender of this message can provide
The currently defined bit settings are
1 - Asynchronous Framing
2 - Synchronous Framing
Bearer Capabilities A set of bits indicating the
capabilities that the sender of this
can provide. The currently defined
settings are
1 - Analog access
2 - Digital access
Maximum Channels The total number of individual PPP
this PAC can support. In Start-Control
Connection-Requests issued by the PNS,
value SHOULD be set to 0. It MUST
ignored by the PAC
Firmware Revision This field contains the firmware
number of the issuing PAC, when issued
the PAC, or the version of the PNS
driver if issued by the PNS
Host Name A 64 octet field containing the DNS name
the issuing PAC or PNS. If less than 64
octets in length, the remainder of
field SHOULD be filled with octets of
0.
Vendor Name A 64 octet field containing a
specific string describing the type of
being used, or the type of PNS
being used if this request is issued by
PNS. If less than 64 octets in length,
remainder of this field SHOULD be
with octets of value 0.
2.2. Start-Control-Connection-
The Start-Control-Connection-Reply is a PPTP control message sent
reply to a received Start-Control-Connection-Request message.
message contains a result code indicating the result of the
connection establishment attempt
Hamzeh, et al. Informational [Page 12]
RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
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
sender wishes to use
Result Code Indicates the result of the command
establishment attempt. Current valid
Code values are
1 - Successful channel
2 - General error -- Error
indicates the
Hamzeh, et al. Informational [Page 13]
RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
3 - Command channel already exists
4 - Requester is not authorized
establish a command
5 - The protocol version of
requester is not
Error Code This field is set to 0 unless a "
Error" exists, in which case Result Code
set to 2 and this field is set to the
corresponding to the general error
as specified in section 2.2.
Framing Capabilities A set of bits indicating the type of
that the sender of this message can provide
The currently defined bit settings are
1 - Asynchronous Framing
2 - Synchronous Framing supported
Bearer Capabilities A set of bits indicating the
capabilities that the sender of this
can provide. The currently defined
settings are
1 - Analog access
2 - Digital access
Maximum Channels The total number of individual PPP
this PAC can support. In a Start-Control
Connection-Reply issued by the PNS,
value SHOULD be set to 0 and it must
ignored by the PAC. The PNS MUST NOT
this value to try to track the
number of PPP sessions that the PAC
allow
Firmware Revision This field contains the firmware
number of the issuing PAC, or the version
the PNS PPTP driver if issued by the PNS
Hamzeh, et al. Informational [Page 14]
RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
Host Name A 64 octet field containing the DNS name
the issuing PAC or PNS. If less than 64
octets in length, the remainder of
field SHOULD be filled with octets of
0.
Vendor Name A 64 octet field containing a
specific string describing the type of
being used, or the type of PNS
being used if this request is issued by
PNS. If less than 64 octets in length,
remainder of this field SHOULD be
with octets of value 0.
2.3. Stop-Control-Connection-
The Stop-Control-Connection-Request is a PPTP control message sent
one peer of a PAC-PNS control connection to inform the other
that the control connection should be closed. In addition to
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
connection being closed. Current
Reason values are
Hamzeh, et al. Informational [Page 15]
RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
1 (None) - General request to
control
2 (Stop-Protocol) - Can't
peer's version of the
3 (Stop-Local-Shutdown) - Requester
being shut
Reserved1, Reserved2 These fields MUST be 0.
2.4. Stop-Control-Connection-
The Stop-Control-Connection-Reply is a PPTP control message sent
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
the control connection. Current valid
Code values are
Hamzeh, et al. Informational [Page 16]
RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
1 (OK) - Control connection
2 (General Error) - Control
not closed for reason indicated
Error
Error Code This field is set to 0 unless a "
Error" exists, in which case Result Code
set to 2 and this field is set to the
corresponding to the general error
as specified in section 2.2.
Reserved1 This field MUST be 0.
2.5. Echo-
The Echo-Request is a PPTP control message sent by either peer of
PAC-PNS control connection. This control message is used as a "keep
alive" for the control connection. The receiving peer issues
Echo-Reply to each Echo-Request received. As specified in
3.1.4, if the sender does not receive an Echo-Reply in response to
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.
Hamzeh, et al. Informational [Page 17]
RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
Identifier A value set by the sender of the Echo
Request that is used to match the reply
the corresponding request
2.6. Echo-
The Echo-Reply is a PPTP control message sent by either peer of
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
received Echo-Request is copied to
field
Result Code Indicates the result of the receipt of
Echo-Request. Current valid Result
values are
1 (OK) - The Echo-Reply is
2 (General Error) - Echo-Request
accepted for the reason indicated
Error
Hamzeh, et al. Informational [Page 18]
RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
Error Code This field is set to 0 unless a "
Error" condition exists, in which
Result Code is set to 2 and this field
set to the value corresponding to
general error condition as specified
section 2.2.
Reserved1 This field MUST be 0.
2.7. Outgoing-Call-
The Outgoing-Call-Request is a PPTP control message sent by the
to the PAC to indicate that an outbound call from the PAC is to
established. This request provides the PAC with information
to make the call. It also provides information to the PAC that
used to regulate the transmission of data to the PNS for this
once it is established
Hamzeh, et al. Informational [Page 19]
RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
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.
Hamzeh, et al. Informational [Page 20]
RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
Call ID A unique identifier, unique to a
PAC-PNS pair assigned by the PNS to
session. It is used to multiplex
demultiplex data sent over the
between the PNS and PAC involved in
session
Call Serial Number An identifier assigned by the PNS to
session for the purpose of identifying
particular session in logged
information. Unlike the Call ID, both
PNS and PAC associate the same Call
Number with a given session. The
of IP address and call serial number
be unique
Minimum BPS The lowest acceptable line speed (
bits/second) for this session
Maximum BPS The highest acceptable line speed (
bits/second) for this session
Bearer Type A value indicating the bearer
required for this outgoing call.
currently defined values are
1 - Call to be placed on an
2 - Call to be placed on a
3 - Call can be placed on any type
Framing Type A value indicating the type of PPP
to be used for this outgoing call
1 - Call to use Asynchronous
2 - Call to use Synchronous
3 - Call can use either type
Packet Recv. Window Size The number of received data packets the
will buffer for this session
Hamzeh, et al. Informational [Page 21]
RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
Packet Processing Delay A measure of the packet processing
that might be imposed on data sent to
PNS from the PAC. This value is
in units of 1/10 seconds. For the PNS
number should be very small. See
4.4 for a description of how this value
determined and used
Phone Number Length The actual number of valid digits in
Phone Number field
Reserved1 This field MUST be 0.
Phone Number The number to be dialed to establish
outgoing session. For ISDN and analog
this field is an ASCII string. If the
Number is less than 64 octets in length,
remainder of this field is filled
octets of value 0.
Subaddress A 64 octet field used to specify
dialing information. If the subaddress
less than 64 octets long, the remainder
this field is filled with octets of value 0.
2.8. Outgoing-Call-
The Outgoing-Call-Reply is a PPTP control message sent by the PAC
the PNS in response to a received Outgoing-Call-Request message.
reply indicates the result of the outgoing call attempt. It
provides information to the PNS about particular parameters used
the call. It provides information to allow the PNS to regulate
transmission of data to the PAC for this session
Hamzeh, et al. Informational [Page 22]
RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
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,
by the PAC to this session. It is used
multiplex and demultiplex data sent over
tunnel between the PNS and PAC involved
this session
Peer's Call ID This field is set to the value received
the Call ID field of the
Outgoing-Call-Request message. It is
by the PNS to match the Outgoing-Call-
with the Outgoing-Call-Request it issued.
also is used as the value sent in the
header for mux/demuxing
Hamzeh, et al. Informational [Page 23]
RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
Result Code This value indicates the result of
Outgoing-Call-Request attempt.
valid values are
1 (Connected) - Call established
no
2 (General Error) - Outgoing Call
established for the reason
in Error
3 (No Carrier) - Outgoing Call
due to no carrier
4 (Busy) - Outgoing Call failed due
detection of a busy
5 (No Dial Tone) - Outgoing
failed due to lack of a dial
6 (Time-out) - Outgoing Call was
established within time allotted
7 (Do Not Accept) - Outgoing
administratively
Error Code This field is set to 0 unless a "
Error" condition exists, in which
Result Code is set to 2 and this field
set to the value corresponding to
general error condition as specified
section 2.2.
Cause Code This field gives additional
information. Its value can vary
upon the type of call attempted. For
call attempts it is the Q.931 cause code
Connect Speed The actual connection speed used,
bits/second
Packet Recv. Window Size The number of received data packets the
will buffer for this session
Hamzeh, et al. Informational [Page 24]
RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
Packet Processing Delay A measure of the packet processing
that might be imposed on data sent to
PAC from the PNS. This value is
in units of 1/10 seconds. For the PAC,
number is related to the size of the
used to hold packets to be sent to
client and to the speed of the link to
client. This value should be set to
maximum delay that can normally
between the time a packet arrives at the
and is delivered to the client. See
4.4 for an example of how this value
determined and used
Physical Channel ID This field is set by the PAC in a vendor
specific manner to the physical
number used to place this call. It is
for logging purposes only
2.9. Incoming-Call-
The Incoming-Call-Request is a PPTP control message sent by the
to the PNS to indicate that an inbound call is to be established
the PAC. This request provides the PNS with parameter
for the incoming call
This message is the first in the "three-way handshake" used by
for establishing incoming calls. The PAC may defer answering
call until it has received an Incoming-Call-Reply from the
indicating that the call should be established. This mechanism
the PNS to obtain sufficient information about the call before it
answered to determine whether the call should be answered or not
Hamzeh, et al. Informational [Page 25]
RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Call Bearer Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Physical Channel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Dialed Number Length | Dialing Number Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Dialed Number (64 octets) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Dialing 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 9 for Incoming-Call-Request
Reserved0 This field MUST be 0.
Call ID A unique identifier for this tunnel
assigned by the PAC to this session. It
used to multiplex and demultiplex data
over the tunnel between the PNS and
involved in this session
Hamzeh, et al. Informational [Page 26]
RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
Call Serial Number An identifier assigned by the PAC to
session for the purpose of identifying
particular session in logged
information. Unlike the Call ID, both
PNS and PAC associate the same Call
Number to a given session. The
of IP address and call serial number
be unique
Bearer Type A value indicating the bearer
used for this incoming call.
defined values are
1 - Call is on an analog
2 - Call is on a digital
Physical Channel ID This field is set by the PAC in a vendor
specific manner to the number of
physical channel this call arrived on
Dialed Number Length The actual number of valid digits in
Dialed Number field
Dialing Number Length The actual number of valid digits in
Dialing Number field
Dialed Number The number that was dialed by the caller
For ISDN and analog calls this field is
ASCII string. If the Dialed Number is
than 64 octets in length, the remainder
this field is filled with octets of value 0.
Dialing Number The number from which the call was placed
For ISDN and analog calls this field is
ASCII string. If the Dialing Number is
than 64 octets in length, the remainder
this field is filled with octets of value 0.
Subaddress A 64 octet field used to specify
dialing information. If the subaddress
less than 64 octets long, the remainder
this field is filled with octets of value 0.
Hamzeh, et al. Informational [Page 27]
RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
2.10. Incoming-Call-
The Incoming-Call-Reply is a PPTP control message sent by the PNS
the PAC in response to a received Incoming-Call-Request message.
reply indicates the result of the incoming call attempt. It
provides information to allow the PAC to regulate the transmission
data to the PNS for this session
This message is the second in the three-way handshake used by
for establishing incoming calls. It indicates to the PAC whether
call should be answered or not
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 | Packet Recv. Window Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Packet Transmit Delay | 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 10 for Incoming-Call-Reply
Reserved0 This field MUST be 0.
Call ID A unique identifier for this tunnel
by the PNS to this session. It is used
multiplex and demultiplex data sent over
tunnel between the PNS and PAC involved
this session
Peer's Call ID This field is set to the value received
the Call ID field of the
Incoming-Call-Request message. It is used
Hamzeh, et al. Informational [Page 28]
RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
the PAC to match the Incoming-Call-
with the Incoming-Call-Request it issued
This value is included in the GRE header
transmitted data packets for this session
Result Code This value indicates the result of
Incoming-Call-Request attempt.
valid Result Code values are
1 (Connect) - The PAC should
the incoming
2 (General Error) - The Incoming
should not be established due to
reason indicated in Error
3 (Do Not Accept) - The PAC should
accept the incoming call. It
hang up or issue a busy
Error Code This field is set to 0 unless a "
Error" condition exists, in which
Result Code is set to 2 and this field
set to the value corresponding to
general error condition as specified
section 2.2.
Packet Recv. Window Size The number of received data packets the
will buffer for this session
Packet Transmit Delay A measure of the packet processing
that might be imposed on data sent to
PAC from the PNS. This value is
in units of 1/10 seconds
Reserved1 This field MUST be 0.
2.11. Incoming-Call-
The Incoming-Call-Connected message is a PPTP control message sent
the PAC to the PNS in response to a received Incoming-Call-Reply.
provides information to the PNS about particular parameters used
the call. It also provides information to allow the PNS to
the transmission of data to the PAC for this session
This message is the third in the three-way handshake used by PPTP
establishing incoming calls. It provides a mechanism for
the PNS with additional information about the call that cannot,
Hamzeh, et al. Informational [Page 29]
RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
general, be obtained at the time the Incoming-Call-Request is
by the PAC
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer's Call ID | Reserved1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Connect Speed |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Packet Recv. Window Size | Packet Transmit Delay |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Framing Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 11 for Incoming-Call-Connected
Reserved0 This field MUST be 0.
Peer's Call ID This field is set to the value received
the Call ID field of the
Incoming-Call-Reply message. It is used
the PNS to match the Incoming-Call-
with the Incoming-Call-Reply it issued
Connect Speed The actual connection speed used,
bits/second
Packet Recv. Window Size The number of received data packets the
will buffer for this session
Packet Transmit Delay A measure of the packet processing
that might be imposed on data sent to
PAC from the PNS. This value is
in units of 1/10 seconds
Hamzeh, et al. Informational [Page 30]
RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
Framing Type A value indicating the type of PPP
being used by this incoming call
1 - Call uses asynchronous
2 - Call uses synchronous
2.12. Call-Clear-
The Call-Clear-Request is a PPTP control message sent by the PNS
the PAC indicating that a particular call is to be disconnected.
call being cleared can be either an incoming or outgoing call, in
state. The PAC responds to this message with a Call-Disconnect
Notify message
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 | 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 12 for Call-Clear-Request
Reserved0 This field MUST be 0.
Call ID The Call ID assigned by the PNS to
call. This value is used instead of
Peer's Call ID because the latter may not
known to the PNS if the call must be
during call establishment
Reserved1 This field MUST be 0.
Hamzeh, et al. Informational [Page 31]
RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
2.13. Call-Disconnect-
The Call-Disconnect-Notify message is a PPTP control message sent
the PAC to the PNS. It is issued whenever a call is disconnected
due to the receipt by the PAC of a Call-Clear-Request or for
other reason. Its purpose is to inform the PNS of both
disconnection and the reason for it
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 | Result Code | Error Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cause Code | Reserved1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Call Statistics (128 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 13 for Call-Disconnect-Notify
Reserved0 This field MUST be 0.
Call ID The value of the Call ID assigned by the
to this call. This value is used instead
the Peer's Call ID because the latter
not be known to the PNS if the call must
aborted during call establishment
Hamzeh, et al. Informational [Page 32]
RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
Result Code This value indicates the reason for
disconnect. Current valid Result Code
are
1 (Lost Carrier) - Call
due to loss of
2 (General Error) - Call
for the reason indicated in
3 (Admin Shutdown) - Call
for administrative
4 (Request) - Call disconnected due
received Call-Clear-
Error Code This field is set to 0 unless a "
Error" condition exists, in which case
Result Code is set to 2 and this field
set to the value corresponding to
general error condition as specified
section 2.2.
Cause Code This field gives additional
information. Its value varies depending
the type of call being disconnected.
ISDN calls it is the Q.931 cause code
Call Statistics This field is an ASCII string
vendor-specific call statistics that can
logged for diagnostic purposes. If
length of the string is less than 128,
remainder of the field is filled with
of value 0.
2.14. WAN-Error-
The WAN-Error-Notify message is a PPTP control message sent by
PAC to the PNS to indicate WAN error conditions (conditions
occur on the interface supporting PPP). The counters in this
are cumulative. This message should only be sent when an
occurs, and not more than once every 60 seconds. The counters
reset when a new call is established
Hamzeh, et al. Informational [Page 33]
RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer's Call 