RFC 2637
Point-to-Point Tunneling Protocol (PPTP)
Part 1 of 12 🎀
Point-to-Point Tunneling Protocol (PPTP) 🦋
Okay bestie, here's the title block tea ☕ This is RFC 2637, from the Network Working Group, and it's Informational (so it's giving "here's some info," not "here's a standard" 💅). It's dated July 1999 and the authors are:
- K. Hamzeh, Ascend Communications 🌸
- G. Pall, Microsoft Corporation 💜
- W. Verthein, 3Com 🦋
- J. Taarud, Copper Mountain Networks ✨
- W. Little, ECI Telematics 🍓
- G. Zorn, Microsoft Corporation 🧚
No obsoletes or updates are listed in this title block. 🙈
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 📝
Okay so the PPTP protocol was built by a vendor consortium (a group of companies that teamed up 🤝). Its documentation is shared with the Internet community as information only. Meanwhile, the PPP WG is working on a Standards Track protocol called L2TP, which is for tunneling PPP across packet-switched networks. Two protocols, same vibe, different lanes 🛣️✨
Abstract 🌸
This document is about a protocol that lets the Point to Point Protocol (PPP) get tunneled through an IP network. PPTP doesn't change PPP at all. Instead, it gives PPP a brand new ride to travel in 🚗💨 It uses a client-server setup to split up the jobs that current Network Access Servers (NAS) do, so Virtual Private Networks (VPNs) can be supported.
The PPTP Network Server (PNS) is meant to run on a general purpose operating system. The client, called a PPTP Access Concentrator (PAC), runs on a dial access platform. PPTP also has a call-control and management protocol, so the server can control access for dial-in circuit switched calls coming from a PSTN or ISDN, or start outbound circuit-switched connections. 📞
Finally, PPTP uses an enhanced GRE (Generic Routing Encapsulation) mechanism. This gives you a flow- and congestion-controlled encapsulated datagram service for carrying PPP packets. Main character energy 👑
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]. Bestie, these are the rules-of-the-road words 🚦
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
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 . . . . . . . . . . . . . . . . . . 571. Introduction ✨
PPTP lets the existing Network Access Server (NAS) functions get split up using a client-server architecture. Traditionally, a NAS handles the following functions:
- 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.
- Logical termination of a Point-to-Point-Protocol (PPP) Link Control Protocol (LCP) session. 🤝
- Participation in PPP authentication protocols [3,9,10]. 🔐
- Channel aggregation and bundle management for PPP Multilink Protocol. 🧩
- Logical termination of various PPP network control protocols (NCP). 🌐
- Multiprotocol routing and bridging between NAS interfaces. 🗺️
PPTP splits 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 it 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 keep 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 that make sense 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 run 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 low-level congestion and flow control to be provided on the tunnels used to carry user data between PAC and PNS. This mechanism allows efficient use of the bandwidth available for the tunnels, and avoids unnecessary retransmissions 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 meant to carry 3.1 Khz audio in each direction. Think of it as the classic voice-call lane 📞
Digital Channel 💾 A circuit-switched communication path meant to carry digital information in each direction. Same vibe, different cargo ✨
Call 📱 A connection, or an attempted connection, between two terminal endpoints on a PSTN or ISDN -- for example, a telephone call between two modems. It's giving dial-up nostalgia 🥹
Control Connection 🎛️ A control connection is created for each PAC, PNS pair and runs over TCP [4]. It's the boss of the tunnel and of all the sessions assigned to that tunnel 👑
Dial User 🧑💻 An end-system or router attached to an on-demand PSTN or ISDN, and it's either the one starting a call or the one receiving it 📲
Network Access Server (NAS) 🌐 A device that gives users temporary, on-demand network access. The access is point-to-point over PSTN or ISDN lines, so it's like a little private hallway for each person 🚪
PPTP Access Concentrator (PAC) 📡 A device attached to one or more PSTN or ISDN lines that's capable of PPP operation and of handling the PPTP protocol. The PAC only needs to implement TCP/IP to pass traffic to one or more PNSs. It may also tunnel non-IP protocols, which is a whole bonus flex 💪
PPTP Network Server (PNS) 🖥️ A PNS is envisioned to run on general-purpose computing or server platforms. It handles the server side of the PPTP protocol 🫶 Since PPTP relies completely on TCP/IP and doesn't care about the interface hardware, the PNS may use any combination of IP interface hardware, including LAN and WAN devices. Mix and match, bestie 🧩
Session 🌸 PPTP is connection-oriented, so the PNS and PAC keep track of state for each user attached to a PAC. A session is created when an end-to-end PPP connection is attempted between a dial user and the PNS. The datagrams for a session get 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, and 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. Iconic multitasking 🙌
1.3. Protocol Overview 🦋
There are two parallel components of PPTP ✨ First, a Control Connection between each PAC-PNS pair, running over TCP. Second, an IP tunnel between that same PAC-PNS pair, which carries GRE encapsulated PPP packets for user sessions. Two lanes, one destination 🛣️
1.3.1. Control Connection Overview 🎀
Before PPP tunneling can happen between a PAC and a PNS, they need a control connection set up between them 🤝 The control connection is a standard TCP session that carries PPTP call control and management information. It's logically tied to the sessions being tunneled, but it's still its own separate thing 💜 For each PAC-PNS pair, both a tunnel and a control connection exist. The control connection handles the establishment, management, and release of sessions carried through the tunnel. It's how a PNS finds out about an incoming call at an associated PAC, and it's also how a PAC gets told to place an outgoing dial call 📞
Either the PNS or the PAC can establish a control connection 🙌 Once the required TCP connection is up, the PNS and PAC set up the control connection using the Start-Control-Connection-Request and Start-Control-Connection-Reply messages. These messages also swap info about the basic operating capabilities of the PAC and PNS 🔧 After that, the PAC or PNS can start sessions by requesting outbound calls or by responding to inbound requests 💅 The control connection can also communicate changes in the operating characteristics of an individual user session using a Set-Link-Info message. Individual sessions can be released by either the PAC or the PNS, again through control connection messages 🧹
The control connection itself is kept alive with keep-alive echo messages 💓 This means 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's intended that the control connection will also carry management-related messages in the future, like a message that lets the PNS request the status of a given PAC. Those message types haven't been defined yet, so stay tuned 👀✨
1.3.2. Tunnel Protocol Overview 🌊
PPTP requires a tunnel to be established for each communicating PNS-PAC pair 🚇 That tunnel carries all the user session PPP packets for sessions involving that PNS-PAC pair. A key present in the GRE header tells you which session a particular PPP packet belongs to 🔑
That's how PPP packets get multiplexed and demultiplexed over a single tunnel between a given PNS-PAC pair 🧠 The value used in the key field is set by the call establishment procedure, which happens on the control connection 💫
The GRE header also contains acknowledgment and sequencing information, which is used to do some level of congestion control and error detection over the tunnel 📊 The control connection is again used to determine the rate and buffering parameters that 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, so that part is up to you 🤷♀️ Suggested algorithms for determining 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 set up by initiating a TCP connection to port 1723 [6]. The source port is assigned to any unused port number 🎯
Each PPTP Control Connection message starts with an 8 octet fixed header portion 🧱 This fixed header holds 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 MessageManagement messages are currently not defined 🙈
The Magic Cookie is always sent as the constant 0x1A2B3C4D 🪄 Its basic purpose is to let the receiver make sure it's properly synchronized with the TCP data stream. It should not be used as a means of resynchronizing the TCP data stream if a transmitter sends 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 15The Start-Control-Connection-Request and Start-Control-Connection-Reply messages decide which version of the Control Connection protocol gets used 🗳️ The version number field carried in these messages has 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 encapsulating 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 📏
2. Control Connection Protocol Specification 👑
Control Connection messages are used to establish and clear user sessions 🧹 The first set of Control Connection messages is used to maintain the control connection itself 🔧 The control connection is initiated by either the PNS or the PAC after they set up the underlying TCP connection. The procedure and configuration information needed to determine which TCP connections get 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 💬 Care has been taken to make sure all word (2 octet) and longword (4 octet) values begin on appropriate boundaries, which is so iconic of them 🙌 All data is sent in network order, meaning high order octets first 🔢 Any "reserved" fields MUST be sent as 0 values to allow for protocol extensibility 🫶
2.1. Start-Control-Connection-Request ✨
okay bestie, so the Start-Control-Connection-Request is a PPTP control message used to set up the control connection between a PNS and a PAC 🎀. Every PNS-PAC pair needs its own dedicated control connection, no sharing 💅. A control connection has to be established before any other PPTP messages can be issued, periodt 👑. Either the PNS or the PAC can start the process 🦋. If the PNS and PAC both send a Start-Control-Connection-Request at the same time (a collision!), there's a whole procedure for that in section 3.1.3 🙈.
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) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Here's the field breakdown, bestie 🌸:
- Length — Total length in octets of this PPTP message, including the entire PPTP header.
- PPTP Message Type —
1for Control Message. - Magic Cookie —
0x1A2B3C4D. This constant value is used as a sanity check on received messages (see section 1.4). 🧚 - Control Message Type —
1for 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.
- 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 the PPTP control message that gets sent back in reply to a received Start-Control-Connection-Request 💌. It carries a result code telling you how the control connection establishment attempt went, so you know if it's giving success or giving drama 😭.
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) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+And here's the breakdown, bestie 🎀:
- Length — Total length in octets of this PPTP message, including the entire PPTP header.
- PPTP Message Type —
1for Control Message. - Magic Cookie —
0x1A2B3C4D. - Control Message Type —
2for 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
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.
- 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 🛑
okay so the Stop-Control-Connection-Request is the message one peer of a PAC-PNS control connection sends to tell the other peer, "bye, we're closing this connection" 💅 and it's not just the connection that gets wiped, all the active user calls get implicitly cleared too 😭 the Reason field tells you why it's happening 🫶
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Here's the field breakdown 🎀
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:
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 what a peer sends back after it gets a Stop-Control-Connection-Request from the other side 🫶 it's the "ack, we're closing 🧚" moment
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+And the fields 💖
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:
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 basically the "still alive?" check 🌈 either peer of a PAC-PNS control connection can send it, and it keeps the control connection alive. The receiving peer answers every Echo-Request it gets with an Echo-Reply ✨ and as section 3.1.4 spells out, if the sender never gets an Echo-Reply back, it will eventually clear the control connection 💀 so yeah, don't ghost the 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+The fields, bestie 🍓
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.
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 the answer 🧚 either peer of a PAC-PNS control connection sends it back whenever it receives 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Field by field 👑
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
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 ✨
Okay so the Outgoing-Call-Request is the PPTP control message the PNS sends to the PAC to say "hey, please start an outbound call." It hands the PAC everything it needs to place the call, and it also includes info the PAC uses to control how much data gets sent to the PNS once the session is up 💖
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) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Here's the field breakdown, bestie 🎀
- Length: the total length in octets of this PPTP message, including the entire PPTP header.
- PPTP Message Type:
1for Control Message. - Magic Cookie:
0x1A2B3C4D. - Control Message Type:
7for Outgoing-Call-Request. - Reserved0: This field MUST be 0.
- Call ID: a unique identifier, unique to a particular PAC-PNS pair, assigned by the PNS to this session. It's what gets used to multiplex and demultiplex data sent over the tunnel between the PNS and PAC involved in this session. Main character energy 👑
- Call Serial Number: an identifier assigned by the PNS to this session so this particular session can be identified 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 showing 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 showing the type of PPP framing to be used for this outgoing call. The currently defined values are:
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. 🧚
- Packet Processing Delay: a measure of the packet processing delay that might be imposed on data sent to the PNS from the PAC. This value is specified in units of 1/10 seconds. For the PNS this number should be very small. See section 4.4 for a description of how this value is determined and used. 🌸
- Phone Number Length: the actual number of valid digits in the Phone Number field.
- Reserved1: This field MUST be 0.
- Phone Number: the number to be dialed to establish the outgoing session. For ISDN and analog calls this field is an ASCII string. If the Phone Number is less than 64 octets in length, the remainder of this field is filled with octets of value 0. 📞
- Subaddress: a 64 octet field used to specify additional dialing information. If the subaddress is less than 64 octets long, the remainder of this field is filled with octets of value 0. 💅
2.8. Outgoing-Call-Reply 💌
okay so the Outgoing-Call-Reply is the PPTP control message the PAC sends back to the PNS after it gets an Outgoing-Call-Request 💅 it tells the PNS how the call attempt went ✨ and it also drops the details about the parameters used for that call. it helps the PNS manage how much data gets sent to the PAC for this session 🦋
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: the total length in octets of this PPTP message, including the entire PPTP header. 📏PPTP Message Type: 1 for Control Message. 💖Magic Cookie: 0x1A2B3C4D. 🪄Control Message Type: 8 for Outgoing-Call-Reply. 🎀Reserved0: This field MUST be 0. 🔒Call ID: a unique identifier for the tunnel, assigned by the PAC to this session. It's what multiplexes and demultiplexes the data sent over the tunnel between the PNS and PAC for this session, so it's giving main character energy 👑Peer's Call ID: this is set to whatever was in the Call ID field of the matching Outgoing-Call-Request. The PNS uses it to match this reply with the request it sent out 🫶 it's also the value that goes in the GRE header for mux/demuxing, iykyk 🧚Result Code: tells you how the Outgoing-Call-Request attempt went. The currently valid values are:1(Connected): call established with no errors ✨2(General Error): the outgoing call wasn't established for the reason given in Error Code 😭3(No Carrier): the outgoing call failed because no carrier was detected 📡4(Busy): the outgoing call failed because a busy signal was detected 📞5(No Dial Tone): the outgoing call failed because there was no dial tone 🔇6(Time-out): the outgoing call wasn't established within the time the PAC allotted for it ⏰7(Do Not Accept): the outgoing call was administratively prohibited 🚫
Error Code: this is set to 0 unless a "General Error" situation is happening. In that case, Result Code is set to 2 and this field gets the value for that general error, as specified in section 2.2. 💀Cause Code: extra failure info. What it looks like depends on the type of call that was attempted. For ISDN call attempts, it's the Q.931 cause code 🧠Connect Speed: the actual connection speed used, in bits/second. ⚡Packet Recv. Window Size: the number of received data packets the PAC will buffer for this session 🧺Packet Processing Delay: a measure of the packet processing delay that might be imposed on data sent to the PAC from the PNS. It's specified in units of 1/10 seconds. For the PAC, this number relates to the size of the buffer used to hold packets going to the client, plus the speed of the link to the client. This value should be set to the maximum delay that can normally happen between a packet arriving at the PAC and being delivered to the client. Check out section 4.4 for an example of how it's determined and used 🌸Physical Channel ID: set by the PAC in a vendor-specific manner to the physical channel number used to place this call. It's only for logging purposes, so it's not doing anything else, bestie 📝
2.9. Incoming-Call-Request 📞
so the Incoming-Call-Request is a PPTP control message the PAC sends to the PNS to say an inbound call is about to be set up from the PAC 🦋 it gives the PNS all the parameter info for that incoming call.
this one is the first step in the "three-way handshake" PPTP uses for setting up incoming calls 🤝 the PAC is allowed to hold off on answering until it gets an Incoming-Call-Reply from the PNS saying the call should be set up. this gives the PNS a chance to gather enough info about the call before it's answered, so it can decide whether to pick up 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 | 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: the 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's used to multiplex and demultiplex the data sent over the tunnel between the PNS and PAC involved in this session 👑Call Serial Number: an identifier the PAC assigns to this session so it can be picked out in logged session info. Unlike the Call ID, both the PNS and PAC attach the same Call Serial Number to a given session. The combo of IP address and call serial number should be unique 🔍Bearer Type: a value showing the bearer capability used for this incoming call. The currently defined values are:1: the call is on an analog channel 📻2: the call is on a digital channel 💻
Physical Channel ID: set by the PAC in a vendor-specific manner to the number of the physical channel this call came in on 🌈Dialed Number Length: the actual number of valid digits in the Dialed Number field 🔢Dialing Number Length: the actual number of valid digits in the Dialing Number field 🔢Dialed Number: the number the caller dialed. For ISDN and analog calls, this field is an ASCII string. If the Dialed Number is less than 64 octets long, the rest of the field gets filled with octets of value 0 🧵Dialing Number: the number the call was placed from. For ISDN and analog calls, this field is an ASCII string. If the Dialing Number is less than 64 octets long, the rest of the field gets filled with octets of value 0 📲Subaddress: a 64 octet field used to specify additional dialing info. If the subaddress is less than 64 octets long, the rest of this field gets filled with octets of value 0 🫧
2.10. Incoming-Call-Reply 🎀
okay so the Incoming-Call-Reply is the PPTP control message the PNS sends to the PAC in response to an Incoming-Call-Request ✨. It tells the PAC how the incoming call attempt went, and it also gives the PAC what it needs to control how much data the PNS sends for this session 💅.
this one is the second message in the three-way handshake PPTP uses for incoming calls 🤝. It's how the PAC finds out whether it should answer the call 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Here's the field breakdown 🧠:
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 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.
Peer's Call ID This field is set to the value received in
the Call ID field of the corresponding
Incoming-Call-Request message. It is used by
the PAC to match the Incoming-Call-Reply
with the Incoming-Call-Request it issued.
This value is included in the GRE header of
transmitted data packets for this session.
Result Code This value indicates the result of the
Incoming-Call-Request attempt. Current
valid Result Code values are:
1 (Connect) - The PAC should answer
the incoming call
2 (General Error) - The Incoming Call
should not be established due to the
reason indicated in Error Code
3 (Do Not Accept) - The PAC should not
accept the incoming call. It should
hang up or issue a busy indication
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.
Packet Recv. Window Size The number of received data packets the PAC
will buffer for this session.
Packet Transmit Delay A measure of the packet processing delay
that might be imposed on data sent to the
PAC from the PNS. This value is specified
in units of 1/10 seconds.
Reserved1 This field MUST be 0.2.11. Incoming-Call-Connected 🌸
the Incoming-Call-Connected is the PPTP control message the PAC sends back to the PNS after getting an Incoming-Call-Reply 🦋. It tells the PNS about some specific parameters used for the call, and it also helps the PNS control how much data it sends to the PAC for this session 💜.
this is the third and final step in the three-way handshake for incoming calls 🫶. It gives the PNS extra info about the call that usually can't be known yet when the PAC sends the Incoming-Call-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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer's Call ID | Reserved1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Connect Speed |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Packet Recv. Window Size | Packet Transmit Delay |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Framing Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Here's the field breakdown 🧠:
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 in
the Call ID field of the corresponding
Incoming-Call-Reply message. It is used by
the PNS to match the Incoming-Call-Connected
with the Incoming-Call-Reply it issued.
Connect Speed The actual connection speed used, in
bits/second.
Packet Recv. Window Size The number of received data packets the PAC
will buffer for this session.
Packet Transmit Delay A measure of the packet processing delay
that might be imposed on data sent to the
PAC from the PNS. This value is specified
in units of 1/10 seconds.
Framing Type A value indicating the type of PPP framing
being used by this incoming call.
1 - Call uses asynchronous framing
2 - Call uses synchronous framing2.12. Call-Clear-Request 💀
the Call-Clear-Request is the PPTP control message the PNS sends to the PAC to say a particular call needs to be disconnected 📵. It works for incoming or outgoing calls, no matter what state the call is in 🌈. When the PAC gets it, the PAC replies 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Here's the field breakdown 🧠:
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 this
call. This value is used instead of the
Peer's Call ID because the latter may not be
known to the PNS if the call must be aborted
during call establishment.
Reserved1 This field MUST be 0.2.13. Call-Disconnect-Notify 📞
okay so the Call-Disconnect-Notify message is a PPTP control message that the PAC sends to the PNS 💅 It gets sent every time a call gets disconnected, whether that's because the PAC got a Call-Clear-Request or for literally any other reason 🙈 Its whole job is to tell the PNS two things: that the call dropped, and why ✨
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 PAC to this call. This value is used instead of the Peer's Call ID, because the latter may not be known to the PNS if the call has to be aborted during call establishment 🦋Result Code: this value indicates the reason for the disconnect. The current valid Result Code values are:- 1 (Lost Carrier): call disconnected due to loss of carrier 📡
- 2 (General Error): call disconnected for the reason indicated in Error Code ⚠️
- 3 (Admin Shutdown): call disconnected for administrative reasons 🧑💼
- 4 (Request): call disconnected due to a received Call-Clear-Request 🙋
Error Code: this field is set to 0 unless a "General Error" condition exists. In that case the Result Code is set to 2, and this field is set to the value matching the general error condition, as specified in section 2.2 🔍Cause Code: this field gives additional disconnect info. Its value varies depending on the type of call being disconnected. For ISDN calls, it's the Q.931 cause code 🧩Call Statistics: this field is an ASCII string with vendor-specific call statistics that can be logged for diagnostic purposes 📊 If the string is shorter than 128, the rest of the field is filled with octets of value 0.
2.14. WAN-Error-Notify 🚨
the WAN-Error-Notify message is a PPTP control message that the PAC sends to the PNS to report WAN error conditions, meaning conditions that happen on the interface supporting PPP 🔌 The counters in this message are cumulative. This message should only be sent when an error occurs, and not more than once every 60 seconds ⏱️ The counters get reset when a new call is established 🔄
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CRC Errors |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Framing Errors |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hardware Overruns |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Buffer Overruns |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time-out Errors |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Alignment Errors |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+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: 14 for WAN-Error-Notify 📣Reserved0: this field MUST be 0 🎀Peer's Call ID: the Call ID assigned by the PNS to this call 🆔CRC Errors: number of PPP frames received with CRC errors since the session was established 💥Framing Errors: number of improperly framed PPP packets received 🖼️Hardware Overruns: number of receive buffer over-runs since the session was established 🌊Buffer Overruns: number of buffer over-runs detected since the session was established 🫧Time-out Errors: number of time-outs since the call was established ⌛Alignment Errors: number of alignment errors since the call was established 📐
2.15. Set-Link-Info 🔧
the Set-Link-Info message is a PPTP control message that the PNS sends to the PAC to set PPP-negotiated options 🛠️ These options can change at any point during the life of the call, so the PAC must be able to update its internal call info on the fly and do PPP negotiation on an active PPP session. Main character energy, honestly 👑
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Send ACCM |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receive ACCM |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+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: 15 for Set-Link-Info ⭐Reserved0: this field MUST be 0 🎀Peer's Call ID: the value of the Call ID assigned by the PAC to this call 🦋Reserved1: this field MUST be 0 🎀Send ACCM: the send ACCM value the client should use to process outgoing PPP packets. The default value the client uses until this message is received is 0XFFFFFFFF. See [7]. 📤Receive ACCM: the receive ACCM value the client should use to process incoming PPP packets. The default value the client uses until this message is received is 0XFFFFFFFF. See [7]. 📥
2.16. General Error Codes 🆘
general error codes cover types of errors that aren't tied to any one specific PPTP request, and are more about protocol or message format problems 🧐 If a PPTP reply says in its Result Code that a general error happened, you should check the General Error value to figure out what went wrong 🕵️♀️ The General Error codes defined so far, and what they mean, are:
0 (None): no general error ✅1 (Not-Connected): no control connection exists yet for this PAC-PNS pair 🔌2 (Bad-Format): length is wrong, or the Magic Cookie value is incorrect 🙅♀️3 (Bad-Value): one of the field values was out of range, or a reserved field was non-zero 🚫4 (No-Resource): not enough resources to handle this command right now 🪫5 (Bad-Call ID): the Call ID is invalid in this context 🆔6 (PAC-Error): a generic vendor-specific error occurred in the PAC 🧯
3. Control Connection Protocol Operation 🧠
okay bestie, this section is all about how the control connection functions actually work, plus the Control Connection messages that power them 💖 The control connection's protocol operation is kind of simplified, because TCP handles the reliable transport 🫶 That means ordering and retransmission aren't a concern at this level. The TCP connection itself can still close at any time, though, so an appropriate error recovery mechanism has to be in place for that case 😭
Some error recovery procedures are shared by every state of the control connection. If an expected reply doesn't arrive within 60 seconds, the control connection gets closed, unless otherwise specified ⏰ Good logging should be implemented so it's easy to figure out what went wrong and why the control connection was closed 🕵️
Receiving an invalid or malformed Control Connection message should be logged appropriately. The control connection should then be closed and restarted, so it recovers into a known state. Don't skip this one, it's giving "reset and try again" 🔄💅
3.1. Control Connection States ✨
okay so the control connection just rides on a regular TCP connection 🎀 PNS and PAC look identical from the protocol's side, but the two ends are still different in one way: the originator is whoever tries the TCP open first. Either PAC or PNS can be the originator, so a TCP collision can happen, and section 3.1.3 covers that drama 💅
3.1.1. Control Connection Originator (may be PAC or PNS) 🦋
TCP Open Indication
/Send Start Control
Connection Request +-----------------+
+------------------------------------>| wait_ctl_reply |
| +-----------------+
| Collision/See (4.1.3) Close TCP V V V Receive Start Ctl
| +-------------------------------+ | | Connection Reply
| | | | Version OK
^ V | V
+-----------------+ Receive Start Ctl | +-----------------+
| idle | Connection Reply | | established |
+-----------------+ Version Not OK | +-----------------+
^ | V Local Terminate
| Receive Stop Control | | /Send Stop
| Connection Request | | Control Request
| /Send Stop Control Reply V V
| Close TCP +-----------------+
+-------------------------------------| wait_stop_reply |
+-----------------+idle The originator starts out in idle and tries to open a TCP connection to the peer 🌸 Once that TCP connection is open, it sends a Start-Control-Connection-Request and moves into wait_ctl_reply.
wait_ctl_reply The originator checks whether another TCP connection has already been requested from the same peer. If one has, it deals with the collision as described in section 3.1.3 🙈
When a Start-Control-Connection-Reply comes in, the originator checks its version. If the reply's version is lower than the version sent in the request, the older (lower) version should be used, as long as it's supported. If the version in the reply is earlier and supported, the originator moves to the established state. If the version is earlier and not supported, a Stop-Control-Connection-Request SHOULD be sent to the peer, and the originator moves into the wait_stop_reply state.
established An established connection can end because of a local condition or because the originator gets a Stop-Control-Connection-Request. If the end is local, the originator MUST send a Stop-Control-Connection-Request and enter the wait_stop_reply state.
If the originator receives a Stop-Control-Connection-Request, it SHOULD send a Stop-Control-Connection-Reply and close the TCP connection, making sure the final TCP information has been "pushed" properly 🧚
wait_stop_reply If a Stop-Control-Connection-Reply is received, the TCP connection SHOULD be closed and the control connection becomes idle 💜
3.1.2. Control connection Receiver (may be PAC or PNS) 🌈
Receive Start Control Connection Request
Version Not OK/Send Start Control Connection
Reply with Error
+--------+
| | Receive Control Connection Request Version OK
| | /Send Start Control Connection Reply
| | +----------------------------------------+
^ V ^ V
+-----------------+ Receive Start Ctl +-----------------+
| Idle | Connection Request | Established |
+-----------------+ /Send Stop Reply +-----------------+
^ ^ Close TCP V V Local Terminate
| +-------------------------------------+ | /Send Stop
| | Control Conn.
| V Request
| +-----------------+
+-------------------------------------| Wait-Stop-Reply |
Receive Stop Control +-----------------+
Connection Reply
/Close TCPidle The receiver waits for a TCP open attempt on port 1723. When it's told a TCP connection is open, it should get ready to receive PPTP messages. When a Start-Control-Connection-Request arrives, its version field should be checked. If the version is earlier than the receiver's version and the receiver can support that earlier version, the receiver SHOULD send a Start-Control-Connection-Reply. If the version is earlier than the receiver's version and can't be supported, the receiver SHOULD send a Start-Connection-Reply message, close the TCP connection, and stay in the idle state. If the receiver's version is the same as the peer's, or earlier than it, the receiver SHOULD send a Start-Control-Connection-Reply with the receiver's version and enter the established state 🎀
established An established connection can end because of a local condition or because the reception of a Stop-Control-Connection-Request. If the end is local, the originator MUST send a Stop-Control-Connection-Request and enter the wait_stop_reply state.
If the originator receives a Stop-Control-Connection-Request, it SHOULD send a Stop-Control-Connection-Reply and close the TCP connection, making sure the final TCP information has been "pushed" properly 💅
wait_stop_reply If a Stop-Control-Connection-Reply is received, the TCP connection SHOULD be closed and the control connection becomes idle 🫶
3.1.3. Start Control Connection Initiation Request Collision 💥
A PAC and PNS must have only one control connection between them. But a PNS and a PAC can try to set up a control connection to each other at the same time 😭 When a Start-Control-Connection-Request arrives on one TCP connection and another Start-Control-Connection-Request has already been sent on a different TCP connection to the same peer, that's a collision.
The "winner" of the initiation race is the peer with the higher IP address (compared as 32-bit unsigned values, with the network number mattering most). For example, if the peers 192.33.45.17 and 192.33.45.89 collide, the latter wins 👑 The loser immediately closes the TCP connection it started, without sending any more PPTP control messages on it, and it responds to the winner's request with a Start-Control-Connection-Reply message. The winner waits for the Start-Control-Connection-Reply on the connection it started, and it also waits for a TCP termination indication on the connection the loser opened. The winner MUST NOT send any messages on the connection the loser initiated 🙈
3.1.4. Keep Alives and Timers ⏰
A control connection SHOULD be closed by closing the underlying TCP connection in the following situations:
- If a control connection is not in the established state (meaning a Start-Control-Connection-Request and Start-Control-Connection-Reply have not been exchanged), a control connection SHOULD be closed after 60 seconds by a peer that is waiting for a Start-Control-Connection-Request or Start-Control-Connection-Reply message.
- If a peer's control connection is in the established state and has not received a control message for 60 seconds, it SHOULD send an Echo-Request message. If an Echo-Reply is not received 60 seconds after the Echo-Request message was transmitted, the control connection SHOULD be closed 🌸
3.2. Call States 📞
3.2.1. Timing considerations ⏱️
Telephone signaling is real-time, so both the PNS and PAC should be implemented with multi-threaded architectures. That way, messages for multiple calls aren't serialized and blocked 🧵 The transit delay between the PAC and PNS should not exceed one second. The call and connection state figures don't spell out exceptions caused by timers. The implicit assumption is that since the TCP-based control connection is being verified with keep-alives, there's less need to keep strict timers for call control messages.
Establishing outbound international calls, including the modem training and negotiation sequences, may take more than 1 minute, so using short timers is discouraged 🌍
If a state transition does not occur within 1 minute (except for connections in the idle or established states), the integrity of the protocol processing between the peers is suspect, and the ENTIRE CONTROL CONNECTION should be closed and restarted 🚨 All Call IDs are logically released whenever a control connection is started. This presumably also helps prevent toll calls from being "lost" and never cleared 💸
3.2.2. Call ID Values 🆔
Each peer assigns a Call ID value to each user session it requests or accepts. This Call ID value MUST be unique for the tunnel between the PNS and PAC it belongs to. Tunnels to other peers can use the same Call ID number, so the receiver of a packet on a tunnel needs to link a user session to a particular tunnel and Call ID 🔑 It is suggested that the number of potential Call ID values for each tunnel be at least twice as large as the maximum number of calls expected on a given tunnel.
A session is defined by the triple (PAC, PNS, Call ID) ✨
3.2.3. Incoming Calls 📱
An Incoming-Call-Request message is generated by the PAC when an associated telephone line rings. The PAC picks a Call ID and serial number and indicates the call bearer type. Modems should always indicate analog call type. ISDN calls should indicate digital when unrestricted digital service or rate adaption is used, and analog if digital modems are involved. The dialing number, dialed number, and subaddress may be included in the message if they're available from the telephone network 📲
Once the PAC sends the Incoming-Call-Request, it waits for a response from the PNS but does not answer the call from the telephone network. The PNS may choose not to accept the call if:
- No resources are available to handle more sessions
- The dialed, dialing, or subaddress fields are not indicative of an authorized user
- The bearer service is not authorized or supported
If the PNS chooses to accept the call, it responds with an Incoming-Call-Reply, which also indicates window sizes (see section 4.2) 🪟 When the PAC receives the Outgoing-Call-Reply, it tries to connect the call, as long as the calling party hasn't hung up. A final call connected message from the PAC to the PNS tells both the PAC and the PNS call states to enter the established state 🎉
When the dialed-in client hangs up, the call is cleared normally and the PAC sends a Call-Disconnect-Notify message. If the PNS wants to clear a call, it sends a Call-Clear-Request message and then waits for a Call-Disconnect-Notify 📴
3.2.3.1. PAC Incoming Call States
Ring/Send Incoming Call Request +-----------------+
+----------------------------------------->| wait_reply |
| +-----------------+
| Receive Incoming Call Reply V V V
| Not Accepting | | | Receive Incoming
| +--------------------------------+ | | Call Reply Accept-
| | +------------------------------+ | ing/Answer call;
| | | Abort/Send Call | Send Call
^ V V Disconnect Notify V Connected
+-----------------+ +-----------------+
| idle |<-----------------------------| established |
+-----------------+ Receive Clear Call Request +-----------------+
or telco call dropped
or local disconnect
/Send Call Disconnect NotifyOkay so this is the PAC's incoming-call life cycle, and it's giving very clean state machine vibes 💅✨
The states associated with the PAC for incoming calls are:
idle: The PAC spots an incoming call on one of its telco interfaces. Usually that means an analog line is ringing, or an ISDN TE has picked up a Q.931 SETUP message 📞 The PAC sends an Incoming-Call-Request message and moves to thewait_replystate.wait_reply: The PAC gets an Incoming-Call-Reply message saying it isn't willing to take the call (a general error or a flat-out "don't accept") and it goes right back toidle🙈 If the reply says the call is accepted, the PAC sends an Incoming-Call-Connected message and enters theestablishedstate.established: Data is flowing over the tunnel 🦋 The call can get cleared in any of these situations:- An event on the telco connection. The PAC sends a Call-Disconnect-Notify message.
- Receipt of a Call-Clear-Request. The PAC sends a Call-Disconnect-Notify message.
- A local reason. The PAC sends a Call-Disconnect-Notify message.
3.2.3.2. PNS Incoming Call States
Receive Incoming Call Request
/Send Incoming Call Reply +-----------------+
Not Accepting if Error | Wait-Connect |
+-----+ +-----------------+
| | Receive Incoming Call Req. ^ V V
| | /Send Incoming Call Reply OK | | | Receive Incoming
| | +--------------------------------+ | | Call Connect
^ V ^ V------------------------------+ V
+-----------------+ Receive Call Disconnect +-----------------+
| Idle | Notify +- | Established |
+-----------------+ | +-----------------+
^ ^ | V Local Terminate
| +----------------------------+ | /Send Call Clear
| Receive Call Disconnect | Request
| Notify V
| +-----------------+
+--------------------------------------| Wait-Disconnect |
Receive Call Disconnect +-----------------+
NotifyNow flip over to the PNS side, the one doing the receiving on the tunnel end 🌸 Its states are:
idle: An Incoming-Call-Request message shows up. If the request isn't acceptable, the PNS sends an Incoming-Call-Reply back to the PAC and stays inidle. If the Incoming-Call-Request message is acceptable, the PNS sends an Incoming-Call-Reply that indicates accept in the result code, and the session moves to thewait_connectstate.wait_connect: If the session gets connected on the PAC, the PAC sends an incoming call connect message to the PNS, which then moves into theestablishedstate 🎉 The PAC may send a Call-Disconnect-Notify to say the incoming caller couldn't be connected. This could happen, for example, if a telephone user accidentally places a standard voice call to a PAC, which leads to a handshake failure on the called modem 📠💀established: The session gets terminated either when the PNS receives a Call-Disconnect-Notify message from the PAC, or when the PNS sends a Call-Clear-Request. Once a Call-Clear-Request has been sent, the session enters thewait_disconnectstate.wait_disconnect: Once a Call-Disconnect-Notify is received, the session moves back to theidlestate.
3.2.4. Outgoing Calls
Outgoing messages are initiated by a PNS and instruct a PAC to place a call on a telco interface 📤 There are only two messages for outgoing calls: Outgoing-Call-Request and Outgoing-Call-Reply. The PNS sends an Outgoing-Call-Request specifying the dialed party phone number and subaddress, as well as speed and window parameters. The PAC MUST respond to the Outgoing-Call-Request message with an Outgoing-Call-Reply message once the PAC determines that:
- The call has been successfully connected ✅
- A call failure has occurred for reasons such as: no interfaces are available for dial-out, the called party is busy or does not answer, or no dial tone is detected on the interface chosen for dialing 😭
3.2.4.1. PAC Outgoing Call States
Receive Outgoing Call Request in Error
/Send Outgoing Call Reply with Error
|--------+
| | Receive Outgoing Call Request No Error
| | /Off Hook; Dial
| | +-----------------------------------------
^ V ^ V
+-----------------+ Incomplete Call +-----------------+
| idle | /Send Outgoing Call | wait_cs_ans |
+-----------------+ Reply with Error +-----------------+
^ ^ or Recv. Call Clear Req. V V Telco Answer
| | /Send Disconnect Notify| | /Send Outgoing
| +-------------------------------------+ | Call Reply.
| V
| +-----------------+
+-------------------------------------| established |
Receive Call Clear Request +-----------------+
or local terminate
or telco disconnect
/Hangup call and send
Call Disconnect NotifyThe states associated with the PAC for outgoing calls are:
idle: The PAC has received an Outgoing-Call-Request. If that request arrives in error, the PAC responds with an Outgoing-Call-Reply with the error condition set. Otherwise, it allocates a physical channel to dial on, places the outbound call, waits for a connection, and moves to thewait_cs_ansstate 📞wait_cs_ans: If the call is incomplete, the PAC sends an Outgoing-Call-Reply with a non-zero Error Code. If a timer expires on an outbound call, the PAC sends back an Outgoing-Call-Reply with a non-zero Error Code. If a circuit switched connection is established, the PAC sends an Outgoing-Call-Reply indicating success 🎀established: If a Call-Clear-Request is received, the telco call SHOULD be released via appropriate mechanisms, and a Call-Disconnect-Notify message SHOULD BE sent to the PNS. If the call is disconnected by the client or by the telco interface, a Call-Disconnect-Notify message SHOULD be sent to the PNS 💜
3.2.4.2. PNS Outgoing Call States
Open Indication Abort/Send
/Send Outgoing Call Call Clear
Request +-----------------+Request
+-------------------------------->| Wait-Reply |----------+
| +-----------------+ |
| Receive Outgoing Call Reply V V Receive Outgoing |
| with Error | | Call Reply |
| +-------------------------------+ | No Error |
^ V V |
+-----------------+ +-----------------+ |
| Idle |<-----------------------------| Established | |
+-----------------+ Receive Call Disconnect +-----------------+ |
^ Notify V Local Terminate |
| | /Send Call Clear |
| | Request |
| Receive Call Disconnect V |
| Notify +-----------------+ |
+---------------------------------| Wait-Disconnect |<---------+
+-----------------+And here's the PNS's outgoing-call story, where it's the one kicking things off 🚀
The states associated with the PNS for outgoing calls are:
idle: An Outgoing-Call-Request message is sent to the PAC, and the session moves into thewait_replystate.wait_reply: An Outgoing-Call-Reply comes back indicating an error. The session returns toidle, and no telco call is active 💀 If the Outgoing-Call-Reply doesn't indicate an error, the telco call is connected and the session moves to theestablishedstate ✨established: If a Call-Disconnect-Notify is received, the telco call has been terminated for the reason indicated in the Result and Cause Codes, and the session moves back toidle. If the PNS chooses to terminate the session, it sends a Call-Clear-Request to the PAC and then enters thewait_disconnectstate.wait_disconnect: The session disconnection is waiting to be confirmed by the PAC. Once the PNS receives the Call-Disconnect-Notify message, the session entersidlestate 🌈
4.1. Enhanced GRE header ✨
okay so the GRE header PPTP uses is a glow-up of the regular GRE header from the current GRE spec [1,2] 💅 The big change is a brand new Acknowledgment Number field. It helps peers figure out whether a particular GRE packet (or a set of them) actually reached the far end of the tunnel 🦋 Here's the tea, though: nothing gets retransmitted because of it. It's used to decide how fast user data packets get sent over the tunnel for a given user session 🫶 The enhanced GRE header looks like this:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|C|R|K|S|s|Recur|A| Flags | Ver | Protocol Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key (HW) Payload Length | Key (LW) Call ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number (Optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Acknowledgment Number (Optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Let's break down those bits, bestie 🧚
- C (Bit 0) Checksum Present. Set to
0. 🙈 - R (Bit 1) Routing Present. Set to
0. - K (Bit 2) Key Present. Set to
1. 🔑 - S (Bit 3) Sequence Number Present. Set to
1if a payload (data) packet is present. Set to0if the payload isn't present, which means the GRE packet is an Acknowledgment only. 💌 - s (Bit 4) Strict source route present. Set to
0. - Recur (Bits 5-7) Recursion control. Set to
0. - A (Bit 8) Acknowledgment sequence number present. Set to
1if the packet contains an Acknowledgment Number to be used for acknowledging previously transmitted data. ✅ - Flags (Bits 9-12) must be set to zero (0). 🧹
- Ver (Bits 13-15) must contain
1(enhanced GRE). 💜 - Protocol Type: set to hex
880B[8]. 🎀
The Key field is up to the implementation, and PPTP uses it like this:
- Payload Length (High 2 octets of Key): the size of the payload, not including the GRE header.
- Call ID (Low 2 octets): the Peer's Call ID for the session this packet belongs to. 🌸
- Sequence Number: the sequence number of the payload. It's present if the S bit (Bit 3) is
1. - Acknowledgment Number: the sequence number of the highest numbered GRE packet received by the sending peer for this user session. It's present if the A bit (Bit 8) is
1. 🫶
The payload section contains a PPP data packet with no media specific framing elements. 🎧
Sequence numbers are per packet, and it's giving very organized energy 📋 The sequence number for each user session is set to zero at session startup. Every packet sent for a given user session that has a payload (and has the S bit set to 1) gets the next consecutive sequence number for that session. 🔢
Acknowledgments can ride along with the data, which makes the whole protocol more efficient, and that in turn means less buffering of packets. Iconic 👑
4.2. Sliding Window Protocol 🪟
the sliding window protocol on the PPTP data path is used for flow control by each side of the data exchange 💅 The enhanced GRE protocol lets packet acknowledgments hitch a ride on data packets, but they can also be sent separately from data packets. Again, the main purpose of the sliding window protocol is flow control. Retransmissions are not performed by the tunnel peers, so no, they're not resending anything 🙅♀️
4.2.1. Initial Window Size 🌱
Each side has told the other its maximum receive window size, but it is recommended that a conservative approach be taken when beginning to transmit data. Main character energy is not the move here 😌 The initial window size on the transmitter is set to half the maximum size the receiver requested, with a minimum size of one packet. The transmitter stops sending packets when the number of packets awaiting acknowledgment equals the current window size. As the receiver successfully digests each window, the transmitter's window size goes up by one packet until it hits the maximum. This method keeps a system from flooding an already congested network, since no history has been established yet. Slow and steady, bestie 🐢
4.2.2. Closing the Window 🚪
When a time-out happens on a packet, the sender cuts the transmit window down to one half of its value when the packet failed. Fractions are rounded up, and the minimum window size is one. Ouch, but it's for the best 😭
4.2.3. Opening the Window 🪟✨
Every time a whole window's worth of packets goes out without a time-out, the transmit window size goes up by one packet. It keeps climbing until it reaches the maximum window size the other side sent when the call was connected. Like we said earlier, no retransmission happens on a time-out. After a time-out, transmission picks back up with the window starting at one half the size of the transmit window when the time-out occurred, and it adjusts upward by one each time the transmit window is filled with packets that all get acknowledged without time-outs. It's the comeback arc, and I'm obsessed 🦋
4.2.4. Window Overflow 🌊
When a receiver's window overflows with too many incoming packets, the excess packets get thrown away. This situation should not arise if the transmitter and receiver are properly following the sliding window procedures. On the transmit side, packets are buffered for transmission and are no longer accepted from the packet source once the transmit buffer fills up. 🪣
4.2.5. Multi-packet Acknowledgment 📦
One feature of the PPTP sliding window protocol is that it lets multiple packets be acknowledged with a single acknowledgment. All outstanding packets with a sequence number lower than or equal to the acknowledgment number count as acknowledged. Time-out calculations use the time the packet with the highest sequence number being acknowledged was transmitted. 🕰️
Adaptive time-out calculations only happen when an Acknowledgment is received. When multi-packet acknowledgments are used, the overhead of the adaptive time-out algorithm goes down, which is so efficient 🤌 The PAC is not required to transmit multi-packet acknowledgments. It can acknowledge each packet individually as it's delivered to the PPP client instead. Options are good 💖
4.3. Out-of-sequence Packets 🌀
Sometimes packets lose their sequencing across a complicated internetwork, and it's chaotic 😵💫 Picture this: a PNS sends packets 0 to 5 to a PAC. Because of rerouting in the internetwork, packet 4 shows up at the PAC before packet 3. The PAC acknowledges packet 4 and may assume packet 3 is lost. That acknowledgment grants window credit beyond packet 4.
When the PAC does receive packet 3, it MUST not attempt to transmit it to the corresponding PPP client. Doing so could cause problems, because proper PPP operation depends on packets arriving in sequence. PPP handles packet loss just fine, but not reordering, so out-of-sequence packets between the PNS and PAC MUST be silently discarded, or they may be reordered by the receiver. 🚫 When packet 5 comes in, the PAC acknowledges it, since it has a higher sequence number than 4, which was the last highest packet acknowledged by the PAC.
Packets with duplicate sequence numbers should never occur, since the PAC and PNS never retransmit GRE packets. 🙃 A robust implementation will silently discard duplicate GRE packets if it ever receives any. Stay robust, bestie 🫶💅
4.4. Acknowledgment Time-Outs ⏰
okay so PPTP uses sliding windows AND time-outs to keep user sessions flowing across the internetwork 🌊 It's how it keeps the PAC-PNS data channels full without overflowing anyone's receive buffer, which is honestly so smart. PPTP requires that a time-out be used to recover from dropped data or acknowledgment packets, because obviously packets get lost, bestie. How the time-out actually gets implemented is up to each vendor 💅 It's suggested that the time-out be adaptive, with backoff for congestion control, which is giving calm under pressure ✨
The time-out mechanism here has a few main vibes:
- Each session gets its own independent time-out. Every device (PAC or PNS) has to keep track of and calculate time-outs for every active session 🎀
- There's an administrator-adjustable maximum time-out, called MaxTimeOut, and it's unique to each device.
- The time-out is adaptive, so it keeps up with changing throughput. To cut down on packet processing overhead, vendors may choose not to recompute the adaptive time-out for every received acknowledgment. The tradeoff is that the time-out won't react as fast to rapid network changes 🙈
- The timer backs off every time a time-out happens to reduce congestion. The backed-off value is capped by the configurable maximum time-out.
Overall this is giving "quickly back off when things go wrong, then slowly ease back down as packets get delivered without time-outs." Iconic behavior honestly 👑
Some definitions, because we need to be on the same page:
- Packet Processing Delay (PPD) is how long each side needs to process the maximum amount of data sitting in its receive packet sliding window. PPD is exchanged between the PAC and PNS when a call gets set up. For the PNS this number should be small 🧚 For a PAC making modem connections, it could be really significant.
- Sample is the actual time it took to receive an acknowledgment for a packet. Sample is measured, not calculated 📏
- Round-Trip Time (RTT) is the estimated time for an Acknowledgment to come back for a given transmitted packet. On a local network it's basically zero, but over the Internet it can be substantial and wildly variable 🌪️ RTT is adaptive: it adjusts to include PPD and whatever shifting network delays affect the time between sending a packet and getting its acknowledgment.
- Adaptive Time-Out (ATO) is how long has to pass before an acknowledgment counts as lost. After a time-out, the sliding window gets partially closed and the ATO is backed off 🦋
The Packet Processing Delay (PPD) parameter is a 16-bit word that gets exchanged during the Call Control phase, and it's measured in tenths of a second (so 64 means 6.4 seconds) ⏱️ The protocol only says the parameter gets exchanged. It doesn't say how it's calculated. Calculating PPD is implementation-dependent, and the value doesn't need to change (static time-outs are allowed). The PPD must be exchanged in the call connect sequences, even if it stays constant in an implementation. One possible way to calculate it looks like this:
PPD' = ((PPP_MAX_DATA_MTU - Header) * WindowSize * 8) / ConnectRate
PPD = PPD' + PACFudgeHeader is the total size of the IP and GRE headers, which is 36 🧁 The MTU is the overall MTU for the internetwork link between the PAC and PNS. WindowSize is the number of packets in the sliding window, and it's implementation-dependent. You could use the internetwork's latency to pick a window size that's big enough to keep the current session's pipe full 🌈 The constant 8 converts octets to bits (assuming ConnectRate is in bits per second). If ConnectRate is in bytes per second, omit the 8. PACFudge is not required, but it can be used to account for the PAC's overall processing overhead 💜
The value of PPD is used to seed the adaptive algorithm with the initial RTT[n-1] value. So it's basically the starting point 🌸
4.4.1. Calculating Adaptive Acknowledgment Time-Out 🧮
okay now we have to decide how long to wait for acknowledgments to come back, and this part is kind of a balancing act 🤹♀️ If the time-out is set too high, we might wait forever for dropped packets. If it's too short, we might time out right before the acknowledgment shows up, which is so rude 😭 The acknowledgment time-out also has to be reasonable and responsive to changing network conditions.
The adaptive algorithm below is based on the TCP 1989 implementation and is explained in [11]. 'n' means this iteration of the calculation, and 'n-1' refers to values from the last calculation.
DIFF[n] = SAMPLE[n] - RTT[n-1]
DEV[n] = DEV[n-1] + (beta * (|DIFF[n]| - DEV[n-1]))
RTT[n] = RTT[n-1] + (alpha * DIFF[n])
ATO[n] = MAX (MinTimeOut, MIN (RTT[n] +
(chi * DEV[n]), MaxTimeOut))Here's the breakdown, bestie:
- DIFF is the error between the last estimated round-trip time and the measured time. It gets calculated on every iteration 🔍
- DEV is the estimated mean deviation, which approximates the standard deviation. It gets calculated on each iteration and stored for the next one. At the start, it's set to 0.
- RTT is the estimated round-trip time of an average packet. It gets calculated on each iteration and stored for the next one. At the start, it's set to PPD.
- ATO is the adaptive time-out for the next transmitted packet. It's calculated on each iteration. The MIN function caps its value at the configured MaxTimeOut value, so it can't go past that 🚧
- Alpha is the gain for the average and is typically 1/8 (0.125).
- Beta is the gain for the deviation and is typically 1/4 (0.250).
- Chi is the gain for the time-out and is typically set to 4.
To get rid of division for the fractional gain elements, the whole set of equations can be scaled. With the suggested gain constants, they should be scaled by 8 to eliminate all division. To keep things simple, all gain values are kept to powers of two, so shift operations can replace multiplication or division. Big brain move 🧠✨
4.4.2. Congestion Control: Adjusting for Time-Out 🚨
this section is about how the ATO calculation changes when a time-out actually happens 😬 When one does, the time-out value should be adjusted rapidly upward. The GRE packets aren't retransmitted when a time-out occurs, but the time-out should still go up toward a maximum limit. To compensate for shifting internetwork delays, a strategy must be employed to increase the time-out when it expires. (Notice that in addition to increasing the time-out, we're also shrinking the size of the window, as described in the next section 🪟) For an interval in which a time-out occurs, the new ATO is calculated as:
RTT[n] = delta * RTT[n-1]
DEV[n] = DEV[n-1]
ATO[n] = MAX (MinTimeOut, MIN (RTT[n] +
(chi * DEV[n]), MaxTimeOut))In this version of the ATO calculation, only the two values that contribute to ATO and get stored for the next iteration are calculated. RTT is scaled by delta, and DEV stays unmodified. DIFF isn't carried forward and isn't used in this scenario. A value of 2 for Delta, the time-out gain factor for RTT, is suggested 🍓
5. Security Considerations 🔐😱
Okay bestie, this part is SERIOUS, so read it carefully 🥺 The security of user data passed over the tunneled PPP connection is handled by PPP, and so is authentication of the PPP peers.
Because the PPTP control channel messages are neither authenticated nor integrity protected, it might be possible for an attacker to hijack the underlying TCP connection. It's also possible to manufacture false control channel messages and to alter genuine messages in transit without anyone noticing. Scary, I know 💀
The GRE packets that form the tunnel itself are not cryptographically protected. And since the PPP negotiations happen over the tunnel, it may be possible for an attacker to eavesdrop on and modify those negotiations 🕵️♀️
Unless the PPP payload data is cryptographically protected, it can be captured and read or modified. Please protect your payload data, periodt 🚨
6. Authors' Addresses 🎀
Here are the people who made this happen, the actual legends 👑
Kory Hamzeh Ascend Communications 1275 Harbor Bay Parkway Alameda, CA 94502
EMail: kory@ascend.com
Gurdeep Singh Pall Microsoft Corporation Redmond, WA
EMail: gurdeep@microsoft.com
William Verthein U.S. Robotics/3Com
Jeff Taarud Copper Mountain Networks
W. Andrew Little ECI Telematics
Glen Zorn Microsoft Corporation Redmond, WA
EMail: glennz@microsoft.com
7. References 📚
[1] Hanks, S., Li, T., Farinacci, D. and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 1701, October 1994.
[2] Hanks, S., Li, T., Farinacci, D. and P. Traina, "Generic Routing Encapsulation (GRE) over IPv4 Networks", RFC 1702, October 1994.
[3] Lloyd, B. and W. Simpson, "PPP Authentication Protocols", RFC 1334, October 1992.
[4] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[5] Postel, J., "User Data Protocol", STD 6, RFC 768, August 1980.
[6] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700, October 1994. See also: http://www.iana.org/numbers.html
[7] Simpson, W., editor, "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.
[8] Ethertype for PPP, Reserved with Xerox Corporation.
[9] Simpson, W., "PPP Challenge Handshake Authentication Protocol (CHAP)", RFC 1994, August 1996.
[10] Blunk, L. and J Vollbrecht, "PPP Extensible Authentication Protocol (EAP)", RFC 2284, March 1998.
[11] Stevens, R., "TCP/IP Illustrated, Volume 1", p. 300, Addison-Wesley, 1994.
[12] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
8. Full Copyright Statement ⚖️
Copyright (C) The Internet Society (1999). All Rights Reserved. 🌸
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement 💖
Funding for the RFC Editor function is currently provided by the Internet Society. Thank you to them, periodt ✨
📦 where this page comes from
- ietf: rfc2637 1999-07
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms