1. Einführung (Introduction)

PPTP ermöglicht es, bestehende Funktionen eines Network Access Servers (NAS) mithilfe einer Client-Server-Architektur zu trennen. Traditionell werden die folgenden Funktionen von einem NAS implementiert:

1. Physische native Schnittstelle zu PSTN oder ISDN und Steuerung externer Modems oder Terminaladapter

   Ein NAS kann direkt an einen analogen oder digitalen Telekommunikationskreis angeschlossen werden oder über ein externes Modem oder einen Terminaladapter verbunden sein. Die Steuerung einer leitungsvermittelten Verbindung erfolgt entweder durch Modemsteuerung oder DSS1-ISDN-Anrufsteuerungsprotokolle.

   Der NAS kann in Verbindung mit dem Modem oder den Terminaladaptern Ratenanpassung, Analog-Digital-Wandlung, Synchron-Asynchron-Wandlung oder eine Reihe anderer Änderungen an Datenströmen durchführen.

2. Logische Terminierung einer Point-to-Point Protocol (PPP) Link Control Protocol (LCP) Sitzung

3. Teilnahme an PPP-Authentifizierungsprotokollen [3,9,10]

4. Kanalaggregation und Bundle-Verwaltung für das PPP Multilink Protocol

5. Logische Terminierung verschiedener PPP Network Control Protocols (NCP)

6. Multiprotokoll-Routing und Bridging zwischen NAS-Schnittstellen

PPTP teilt diese Funktionen zwischen PAC und PNS auf. Der PAC ist für die Funktionen 1, 2 und möglicherweise 3 verantwortlich. Der PNS kann für Funktion 3 verantwortlich sein und ist für die Funktionen 4, 5 und 6 verantwortlich. Das Protokoll, das zum Transport von PPP-Protokolldateneinheiten (Protocol Data Units, PDUs) zwischen PAC und PNS sowie zur Anrufsteuerung und -verwaltung verwendet wird, wird durch PPTP adressiert.

Die Entkopplung der NAS-Funktionen bietet folgende Vorteile:

Flexible IP-Adressverwaltung. Einwahlbenutzer können eine einzige IP-Adresse beibehalten, wenn sie sich bei verschiedenen PACs einwählen, solange sie von einem gemeinsamen PNS bedient werden. Wenn ein Unternehmensnetzwerk nicht registrierte Adressen verwendet, weist ein mit dem Unternehmen verbundener PNS für das private Netzwerk sinnvolle Adressen zu.

Unterstützung von Nicht-IP-Protokollen für Einwahlnetzwerke hinter IP-Netzwerken. Dies ermöglicht es beispielsweise, AppleTalk und IPX durch einen reinen IP-Anbieter zu tunneln. Der PAC muss diese Protokolle nicht verarbeiten können.

Eine Lösung für das "Multilink-Hunt-Group-Splitting"-Problem. Multilink PPP, das typischerweise zur Aggregation von ISDN-B-Kanälen verwendet wird, erfordert, dass alle Kanäle, die ein Multilink-Bundle bilden, auf einem einzigen NAS gruppiert werden. Da ein Multilink-PPP-Bundle von einem einzigen PNS verarbeitet werden kann, können die das Bundle bildenden Kanäle über mehrere PACs verteilt werden.

1.1. Protokollziele und Annahmen (Protocol Goals and Assumptions)

Das PPTP-Protokoll wird nur vom PAC und PNS implementiert. Keine anderen Systeme müssen PPTP kennen. Einwahlnetzwerke können mit einem PAC verbunden werden, ohne PPTP zu kennen. Standard-PPP-Client-Software sollte (SHOULD) weiterhin auf getunnelten PPP-Verbindungen funktionieren.

PPTP kann auch verwendet werden, um eine PPP-Sitzung über ein IP-Netzwerk zu tunneln. In dieser Konfiguration laufen der PPTP-Tunnel und die PPP-Sitzung zwischen denselben beiden Maschinen, wobei der Anrufer als PNS fungiert.

Es wird erwartet, dass es eine Viele-zu-Viele-Beziehung zwischen PACs und PNSs geben wird. Ein PAC kann mehreren PNSs Dienste bereitstellen. Beispielsweise kann ein Internetdienstanbieter wählen, PPTP für mehrere private Netzwerkkunden zu unterstützen und VPNs für sie zu erstellen. Jedes private Netzwerk kann einen oder mehrere PNSs betreiben. Ein einzelner PNS kann mit vielen PACs verbunden sein, um Datenverkehr von einer großen Anzahl geografisch verteilter Standorte zu konzentrieren.

PPTP verwendet eine erweiterte Version von GRE, um Benutzer-PPP-Pakete zu transportieren. Diese Verbesserungen ermöglichen die Bereitstellung einer Low-Level-Stau- und Flusssteuerung für die Tunnel, die zum Transport von Benutzerdaten zwischen PAC und PNS verwendet werden. Dieser Mechanismus ermöglicht eine effiziente Nutzung der für die Tunnel verfügbaren Bandbreite und vermeidet unnötige Wiederholungen und Pufferüberläufe. PPTP schreibt keine bestimmten Algorithmen für diese Low-Level-Steuerung vor, definiert jedoch die Parameter, die kommuniziert werden müssen, damit diese Algorithmen funktionieren können. Vorgeschlagene Algorithmen sind in Abschnitt 4 enthalten.

---

1.2. Terminologie (Terminology)

Analoger Kanal (Analog Channel)
Ein leitungsvermittelter Kommunikationspfad, der für die Übertragung von 3,1 kHz Audio in jede Richtung vorgesehen ist.

Digitaler Kanal (Digital Channel)
Ein leitungsvermittelter Kommunikationspfad, der für die Übertragung digitaler Informationen in jede Richtung vorgesehen ist.

Anruf (Call)
Eine Verbindung oder ein Verbindungsversuch zwischen zwei Endpunkten in einem PSTN oder ISDN, beispielsweise ein Telefonanruf zwischen zwei Modems.

Steuerverbindung (Control Connection)
Für jedes PAC-PNS-Paar wird eine Steuerverbindung erstellt, die über TCP läuft. Die Steuerverbindung regelt Aspekte des Tunnels und der dem Tunnel zugewiesenen Sitzungen.

Einwahlbenutzer (Dial User)
Ein Endsystem oder Router, das an ein bedarfsgesteuertes PSTN oder ISDN angeschlossen ist und entweder Initiator oder Empfänger eines Anrufs ist.

Network Access Server (NAS)
Ein Gerät, das Benutzern temporären, bedarfsgesteuerten Netzwerkzugang bietet. Dieser Zugang erfolgt punkt-zu-punkt über PSTN- oder ISDN-Leitungen.

PPTP Access Concentrator (PAC)
Ein Gerät, das an eine oder mehrere PSTN- oder ISDN-Leitungen angeschlossen ist, PPP-Operationen durchführen kann und das PPTP-Protokoll verarbeitet. Der PAC muss nur TCP/IP implementieren, um Datenverkehr an einen oder mehrere PNS weiterzuleiten. Er kann auch Nicht-IP-Protokolle tunneln.

PPTP Network Server (PNS)
Ein PNS ist für den Betrieb auf universellen Computing/Server-Plattformen vorgesehen. Der PNS behandelt die Serverseite des PPTP-Protokolls. Da PPTP vollständig auf TCP/IP basiert und unabhängig von der Schnittstellenhardware ist, kann der PNS jede Kombination von IP-Schnittstellenhardware verwenden, einschließlich LAN- und WAN-Geräten.

Sitzung (Session)
PPTP ist verbindungsorientiert. Der PNS und der PAC pflegen den Zustand für jeden Benutzer, der an einen PAC angeschlossen ist. Eine Sitzung wird erstellt, wenn eine Ende-zu-Ende-PPP-Verbindung zwischen einem Einwahlbenutzer und dem PNS versucht wird. Die zu einer Sitzung gehörenden Datagramme werden über den Tunnel zwischen PAC und PNS gesendet.

Tunnel
Ein Tunnel wird durch ein PNS-PAC-Paar definiert. Das Tunnelprotokoll wird durch eine modifizierte Version von GRE definiert. Der Tunnel überträgt PPP-Datagramme zwischen dem PAC und dem PNS. Mehrere Sitzungen werden auf einem einzigen Tunnel gemultiplext. Eine über TCP laufende Steuerverbindung steuert die Einrichtung, Freigabe und Wartung von Sitzungen und des Tunnels selbst.

1.3. Protokollübersicht (Protocol Overview)

PPTP besteht aus zwei parallelen Komponenten: 1) einer Steuerverbindung zwischen jedem PAC-PNS-Paar, die über TCP läuft, und 2) einem IP-Tunnel, der zwischen demselben PAC-PNS-Paar läuft und zum Transport von GRE-gekapselten PPP-Paketen für Benutzersitzungen zwischen dem Paar verwendet wird.

1.3.1. Übersicht über die Steuerverbindung (Control Connection Overview)

Bevor PPP-Tunneling zwischen einem PAC und PNS stattfinden kann, muss eine Steuerverbindung zwischen ihnen eingerichtet werden. Die Steuerverbindung ist eine Standard-TCP-Sitzung, über die PPTP-Anrufsteuerungs- und Verwaltungsinformationen übertragen werden. Die Steuerungssitzung ist logisch mit den Sitzungen verbunden, die durch einen PPTP-Tunnel getunnelt werden, aber davon getrennt. Für jedes PAC-PNS-Paar existieren sowohl ein Tunnel als auch eine Steuerverbindung. Die Steuerverbindung ist verantwortlich für die Einrichtung, Verwaltung und Freigabe von Sitzungen, die durch den Tunnel transportiert werden. Sie ist das Mittel, durch das ein PNS über einen eingehenden Anruf an einem zugehörigen PAC benachrichtigt wird, sowie das Mittel, durch das ein PAC angewiesen wird, einen ausgehenden Wählanruf zu tätigen.

Eine Steuerverbindung kann entweder vom PNS oder vom PAC eingerichtet werden. Nach der Einrichtung der erforderlichen TCP-Verbindung richten PNS und PAC die Steuerverbindung unter Verwendung der Start-Control-Connection-Request- und -Reply-Nachrichten ein. Diese Nachrichten werden auch verwendet, um Informationen über grundlegende Betriebsfähigkeiten des PAC und PNS auszutauschen. Sobald die Steuerverbindung eingerichtet ist, kann der PAC oder PNS Sitzungen initiieren, indem er ausgehende Anrufe anfordert oder auf eingehende Anfragen antwortet. Die Steuerverbindung kann Änderungen in den Betriebsmerkmalen einer einzelnen Benutzersitzung mit einer Set-Link-Info-Nachricht kommunizieren. Einzelne Sitzungen können entweder vom PAC oder PNS, ebenfalls über Steuerverbindungsnachrichten, freigegeben werden.

Die Steuerverbindung selbst wird durch Keep-Alive-Echo-Nachrichten aufrechterhalten. Dies stellt sicher, dass ein Konnektivitätsfehler zwischen dem PNS und dem PAC rechtzeitig erkannt werden kann. Andere Fehler können über die Wan-Error-Notify-Nachricht, ebenfalls auf der Steuerverbindung, gemeldet werden.

Es ist beabsichtigt, dass die Steuerverbindung in Zukunft auch verwaltungsbezogene Nachrichten trägt, wie z. B. eine Nachricht, die es dem PNS ermöglicht, den Status eines bestimmten PAC anzufordern; diese Nachrichtentypen wurden noch nicht definiert.

1.3.2. Übersicht über das Tunnelprotokoll (Tunnel Protocol Overview)

PPTP erfordert die Einrichtung eines Tunnels für jedes kommunizierende PNS-PAC-Paar. Dieser Tunnel wird verwendet, um alle Benutzersitzungs-PPP-Pakete für Sitzungen mit einem bestimmten PNS-PAC-Paar zu transportieren. Ein Schlüssel, der im GRE-Header vorhanden ist, gibt an, zu welcher Sitzung ein bestimmtes PPP-Paket gehört.

Auf diese Weise werden PPP-Pakete über einen einzigen Tunnel zwischen einem gegebenen PNS-PAC-Paar gemultiplext und demultiplext. Der im Schlüsselfeld zu verwendende Wert wird durch das Anrufeinrichtungsverfahren festgelegt, das auf der Steuerverbindung stattfindet.

Der GRE-Header enthält auch Bestätigungs- und Sequenzierungsinformationen, die verwendet werden, um ein gewisses Maß an Staukontrolle und Fehlererkennung über den Tunnel durchzuführen. Wiederum wird die Steuerverbindung verwendet, um Raten- und Pufferparameter zu bestimmen, die zur Regulierung des Flusses von PPP-Paketen für eine bestimmte Sitzung über den Tunnel verwendet werden. PPTP spezifiziert nicht die bestimmten Algorithmen, die für Staukontrolle und Flusskontrolle zu verwenden sind. Vorgeschlagene Algorithmen zur Bestimmung adaptiver Zeitüberschreitungen zur Wiederherstellung von verlorenen Daten oder Bestätigungen auf dem Tunnel sind in Abschnitt 4.4 dieses Dokuments enthalten.

1.4. Nachrichtenformat und Protokollerweiterbarkeit (Message Format and Protocol Extensibility)

PPTP definiert einen Satz von Nachrichten, die als TCP-Daten auf der Steuerverbindung zwischen einem PNS und einem gegebenen PAC gesendet werden. Die TCP-Sitzung für die Steuerverbindung wird durch Initiierung einer TCP-Verbindung zu Port 1723 eingerichtet. Der Quellport wird einem beliebigen ungenutzten Portnummer zugewiesen.

Jede PPTP-Steuerverbindungsnachricht beginnt mit einem 8-Oktett-Fixheader-Teil. Dieser Fixheader enthält folgendes: die Gesamtlänge der Nachricht, den PPTP-Nachrichtentypindikator und ein „Magic Cookie".

Zwei Steuerverbindungs-Nachrichtentypen werden durch das PPTP-Nachrichtentypfeld angegeben:

• 1 - Steuernachricht (Control Message)
• 2 - Verwaltungsnachricht (Management Message)

Verwaltungsnachrichten sind derzeit nicht definiert.

Das Magic Cookie wird immer als Konstante 0x1A2B3C4D gesendet. Sein grundlegender Zweck besteht darin, dem Empfänger zu ermöglichen, sicherzustellen, dass er ordnungsgemäß mit dem TCP-Datenstrom synchronisiert ist. Es sollte nicht (SHOULD NOT) als Mittel zur Resynchronisierung des TCP-Datenstroms verwendet werden, wenn ein Sender eine falsch formatierte Nachricht ausgibt. Der Verlust der Synchronisation muss (MUST) zur sofortigen Schließung der TCP-Sitzung der Steuerverbindung führen.

Zur Klarstellung enthalten alle Steuerverbindungs-Nachrichtenvorlagen im nächsten Abschnitt den vollständigen PPTP-Steuerverbindungs-Nachrichtenheader. Zahlen mit vorangestelltem 0x sind Hexadezimalwerte.

Die derzeit definierten Steuernachrichten, nach Funktion gruppiert, sind:

Steuerverbindungsverwaltung (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)

Anrufverwaltung (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)

Fehlerberichterstattung (Error Reporting)

• WAN-Error-Notify (14)

PPP-Sitzungssteuerung (PPP Session Control)

• Set-Link-Info (15)

Die Start-Control-Connection-Request- und -Reply-Nachrichten bestimmen, welche Version des Steuerverbindungsprotokolls verwendet wird. Das in diesen Nachrichten übertragene Versionsnummernfeld besteht aus einer Versionsnummer im höherwertigen Oktett und einer Revisionsnummer im niederwertigen Oktett. Die Versionsbehandlung wird in Abschnitt 2 beschrieben. Der aktuelle Wert des Versionsnummernfeldes ist 0x0100 für Version 1, Revision 0.

Die Verwendung des GRE-ähnlichen Headers für die Kapselung von PPP-Benutzerpaketen ist in Abschnitt 4.1 spezifiziert.

Die MTU für die in GRE gekapselten Benutzerdatenpakete beträgt 1532 Oktetts, ohne die IP- und GRE-Header.

---