[RFCs/IDs] [Plain Text] [From draft-ietf-pppext-pptp]
INFORMATIONAL
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-
Hamzeh, et al. Informational [Page 1]
RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
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
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. 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.
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) 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.
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. 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.
Hamzeh, et al. Informational [Page 5]
RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
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.
Hamzeh, et al. Informational [Page 6]
RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
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.
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 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.
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 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.
Hamzeh, et al. Informational [Page 9]
RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
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.
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 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.
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 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.
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 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
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 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.
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 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:
Hamzeh, et al. Informational [Page 15]
RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
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:
Hamzeh, et al. Informational [Page 16]
RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999
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.
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 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
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 "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.
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 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.
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 delay
that might be imposed on data sent to the
PNS from the PAC. This value is specified