Point-to-Point Protocol

Das Point-to-Point Protocol (PPP; engl. für Punkt-zu-Punkt-Protokoll) ist in der Informationstechnologie ein Netzwerkprotokoll zum Verbindungsaufbau über Wählleitungen. Das Protokoll basiert auf High-Level Data Link Control (HDLC) und ist der Nachfolger von Serial Line Internet Protocol (SLIP) sowie einer Reihe proprietärer Protokolle dieser Art.

Heute ist PPP das Standardprotokoll, das Internetprovider für die Einwahl der Kunden verwenden. Mit Hilfe von PPP teilt der Provider dem Kunden-Computer oder -Router, welcher bei der Einwahl mit dem Internet verbunden werden soll, wichtige Daten mit, z. B. dessen IP-Adresse oder den zu verwendenden DNS-Server. Früher wurde PPP zumeist über Modem- oder ISDN-Verbindungen verwendet; heutzutage kommt es jedoch auch bei neueren Verbindungsarten wie z. B. GPRS-/UMTS-Mobilfunkdatenverbindungen oder (typischerweise als PPPoE) bei DSL-Verbindungen zum Einsatz.

Die Spezifikation von PPP ist nicht auf IP-Verbindungen beschränkt, sondern ermöglicht verschiedene Netzwerkprotokolle (z. B. IPX oder AppleTalk); es wird in RFC 1661 standardisiert. Seltener wird PPP für statische Verbindungen (Standleitungen) verwendet, beispielsweise um die Authentifizierungs-Mechanismen (PAP, CHAP) zu nutzen. Hierfür kommen meist modifizierte Protokolle wie PPPoE oder PPTP zum Einsatz.

In diesem Absatz wird PPP über HDLC gezeigt, wie im RFC 1662 beschrieben. Andere übliche PPP Benutzungen sind: PPP über Ethernet (PPPoE (o = over)) oder PPP über ATM (PPPoA).

Kennzeichnet die Frame-Begrenzung und entspricht dem HDLC-Standard. Es besitzt immer den Wert 01111110b (0x7e).

Dieses Feld hat den Standardwert 11111111b (0xff). Dieser zeigt an, dass alle Stationen den PPP-Frame akzeptieren sollen. Dadurch wird die Zuweisung von Verbindungsadressen vermieden.

Der Standardwert 00000011b (0x03) steht für einen unnummerierten Frame. Dadurch ist bei besonders schlechten Verbindungen allerdings keine sichere Übertragung gewährleistet. Bei besonders schlechten Verbindungen, wie sie bei drahtlosen Netzen vorkommen können, sollten nummerierte Frames zum Einsatz kommen.

Da zumeist die Standardwerte für die Felder Adresse und Steuerung verwendet werden, stellt das Link Control Protocol (LCP) Funktionen zur Verfügung, die es möglich machen, diese Felder wegzulassen.

Gibt den Code für die Paketart im Feld Nutzdaten an. Über LCP kann auch vereinbart werden, dass das Feld Protokoll nur 1 Byte groß sein soll.

Hier eine Auswahl der Codes in hexadezimal:^[1]

• 0x0021 – Internet Protocol Version 4 IPv4
• 0x0057 – Internet Protocol Version 6 IPv6
• 0x80fd – Compression Control Protocol CCP
• 0x8021 – Internet Protocol Control Protocol IPCP
• 0x8057 – IPv6 Control Protocol IPV6CP
• 0xc021 – Link Control Protocol LCP
• 0xc023 – Password Authentication Protocol PAP
• 0xc223 – Challenge Handshake Authentication Protocol CHAP

Das Feld Nutzdaten hat eine variable Länge, die durch LCP vereinbart wird. Dieses Feld kann bei Bedarf aufgefüllt werden (Padding).

Die Frame Check Sequence ist eine Prüfsumme (CRC) der Felder Address, Control, Protocol und Payload.

PPP stellt die Kommunikation über eine Punkt-zu-Punkt-Verbindung in vier Phasen her:

Verbindungsaufbau und Konfigurationsaushandlung

Ein PPP-Ausgangsknoten sendet LCP-Rahmen zur Konfiguration und zum Aufbau der Datenverbindung.

Bestimmung der Verbindungsqualität

Die Verbindung wird getestet, um zu bestimmen, ob ihre Qualität für den Aufruf von Vermittlungsschichtprotokollen (OSI-Schicht) ausreicht. (optionale Phase)

Aushandlung der Konfiguration des Vermittlungsschichtprotokolls

Der PPP-Ausgangsknoten sendet NCP-Rahmen zur Auswahl und Konfiguration. Die Protokolle wie IP, IPX und Appletalk werden konfiguriert, so dass Pakete von jedem Protokoll gesendet werden können.

Verbindungsbeendung

Die Verbindung bleibt für die Kommunikation konfiguriert, bis LCP- oder NCP-Rahmen die Verbindung beenden oder ein externes Ereignis auftritt. (z. B. Inaktivität des Benutzers)

Hier wird die Herstellung einer PPP-Verbindung am Beispiel PPPoE erklärt. Ein ähnlicher Ablauf gilt auch für Modem- und ISDN-Verbindungen. Unterschiede gibt es dort vor allem bei der Daten- und IP-Header-Komprimierung, die bei DSL nicht möglich ist.

Zunächst eine kurze Erklärung zu den verwendeten Bildern:
Rot gekennzeichnet sind hier Empfänger (steht immer rechts) und Sender (steht immer links). Empfänger und Sender besitzen immer MAC-Adressen. Jedes Paket besitzt auch eine ID (grün gekennzeichnet). Dadurch ist gewährleistet, dass zu jeder Anfrage (Request) die richtige Antwort zugeordnet wird, da das Frage-und-Antwort-Spiel meist verschachtelt abläuft. Als Client wird hier der Rechner des Internetnutzers und als PoP („Point of Presence“) der Remote Access Server des Internet Service Providers (ISP) bezeichnet. PoP ist in unserem Beispiel NortelNe_* und Client ist 3Com_*. Blau gekennzeichnet ist das Options-Feld des PPP-Rahmens. Dort werden Daten- und Optionen eingetragen. Auf dieses Feld wird sich ausschließlich bezogen.

Configuration Request:

In diesem Paket sendet der Client eine CBCP-Anfrage (Vorschlag) an den PoP. Das Microsoft Call Back Control Protocol (CBCP) ermöglicht den Rückruf des PoPs. Dies gilt vor allem für ISDN-Verbindungen. Durch den Rückruf des PoPs können Telefonkosten gespart werden.

Configuration Reject:

Da das in unserem Fall nicht möglich ist (da DSL), antwortet der PoP mit einem Reject (Konfiguration nicht angenommen). Die Konfiguration der Verbindung, die abgelehnt wurde, steht im Options-Feld. Ein Reject bedeutet, dass der PoP dieses Feature überhaupt nicht unterstützt und deshalb keine weiteren Konfigurationsverhandlungen möglich sind.

Configuration Request:

Als Nächstes schlägt der PoP über ein LCP Configuration Request das Authentifizierungs-Protokoll CHAP und eine Maximum Receive Unit (MRU) von 1492 Byte vor. Die MRU ist durch den PPP-Header um 8 Byte kleiner als die maximal mögliche MTU von 1500 Byte.

Configuration Nak:

Configuration Nak (Nak bedeutet Not acknowledged) bedeutet im Unterschied zu Reject so viel wie: „Ich lehne diese Konfiguration ab und bitte um eine neue Verhandlung.“ Im DFÜ-Netzwerk von Windows ist eine MTU von 1480 Byte eingestellt. Deshalb lehnt der Client den Vorschlag vom PoP ab und übergibt gleichzeitig die eingestellte MTU/MRU.

Configuration Request:

Der PoP sendet nun ein Configuration Request, welcher die neue MRU und das CHAP beinhaltet.

Configuration Ack:

Der Client bestätigt diese Einstellung mit einem Configuration Acknowledge. Dies bedeutet, dass die Konfiguration mit der neuen MRU und dem CHAP angenommen wurde.

CHAP Challenge:

Nachdem der Client CHAP als Einstellung angenommen hat, sendet der PoP eine 128-bit-Zufallszahl (Challenge). Diese ist unten im Bild als Hex-Wert zu sehen (farbig unterlegt). Diese Challenge ist im Value-Feld des CHAP-Pakets abgelegt. Aus dem Passwort des Internet-Accounts und der Challenge errechnet der Client über den MD5-Algorithmus nun einen Hash-Wert.

CHAP Response:

Der Client schickt nun den Hash als Response (Antwort) an den PoP. Der Hash ist als 128bit-Zahl in Hexform unten im Bild zu erkennen. Der Hash steht wieder im Value-Feld des CHAP-Pakets. Gleichzeitig schickt der Client im Name-Feld den Login (geschwärzt) an den PoP. Der PoP (oder ein RADIUS-Server) schaut mit dem Login in seiner Datenbank nach dem passenden Passwort. Aus dem Passwort und der Challenge (ist die Gleiche wie beim Client) berechnet er über MD5 einen zweiten Hash-Wert. Beide Hash-Werte (der vom Client und der vom PoP berechnete) werden jetzt verglichen. Stimmen beide Hash-Werte überein, so ist der Login erfolgreich (CHAP Success). Sind sie unterschiedlich, so ist der Login nicht erfolgreich (CHAP Fail).

CHAP Success

(c) Appaloosa, CC BY-SA 3.0

Es stimmen beide Hash-Werte überein und man hat damit bewiesen, dass man das richtige Passwort hat. Bewiesen deshalb, da das Passwort im Gegensatz zu PAP nicht als Klartext übertragen wird. Als Nächstes wird nun die Datenkompression eingestellt.

Configuration Request – CCP:

(c) Appaloosa, CC BY-SA 3.0

Über das Compression Control Protocol (CCP) wird die Datenkompression für die Verbindung eingestellt. Der Client schlägt hier die Microsoft Point-to-Point-Compression (MPPC) vor.

Protocol Reject:

Da DSL überhaupt und damit auch der PoP (DSL-AC) keine Datenkompression unterstützt, wird das CCP abgelehnt und nicht nur das MPPC.

Das NCP übermittelt die Daten, die vom Protokoll der Vermittlungsschicht benötigt werden, damit dieses lauffähig ist. Es gibt mehrere NCP-Umsetzungen: IPCP für das Internet Protocol, IPXCP für IPX und AppleTalk Control Protocol für AppleTalk.

Das IPCP wird zum Beispiel zur IP-Vergabe und zur Einstellung der IP-Header-Kompression benutzt. Die IP-Vergabe betrifft die IP-Adresse des PoPs und die dynamische IP des Clients, welche der ISP aus einem IP-Pool vergibt. Außerdem kommen die zwei IP-Adressen des DNSs dazu. Der Client kann auch IP-Adressen vorschlagen. IPCP gehört zur NCP-Protokoll-Familie.

Configuration Request:

Der Client schickt eine Anfrage an den PoP. Diese Anfrage beinhaltet die IP-Header VJ-Kompression, den WINS, DNS und die IP-Adresse für den Client. Das Feld IP-Adress(e) beinhaltet später auch die PoP-ID. Der PoP wählt jetzt die Optionen aus, die er verwenden will, beziehungsweise unterstützt.

Configuration reject:

Im Internet wird der WINS nicht benutzt und die IP-Header-Kompression von DSL nicht unterstützt. Deshalb antwortet der PoP mit einem reject. Übrig bleiben damit für die Konfiguration nur noch der DNS und die IP-Adresse.

Configuration Request:

Da nur die IP-Adressen für den Client und den zwei DNS-Servern zur Konfiguration übriggeblieben sind sendet der Client nur diese als Request. Hier könnten zum Beispiel andere Adressen als „0.0.0.0“ als Vorschlag drinstehen. Vorschlagen könnte man höchstens den ersten und zweiten DNS-Server.

Configuration Nak:

Da „0.0.0.0“ als DNS- und IP-Adresse natürlich falsch sind, sendet der PoP ein Configuration Nak und gleichzeitig seinen Vorschlag.

Configuration Request:

Den Inhalt (DNS, IP) des vorangegangenen Configuration-Nak-Frames sendet der Client noch einmal zur Bestätigung als Request an den PoP. Der PoP weiß jetzt, dass der Client mit der Konfiguration einverstanden ist …

Configuration Ack:

… und bestätigt dies dem Client.

• Fehlererkennung
• dynamische IP-Adressen-Zuweisung
• Authentifizierungsmechanismen
• Aushandeln von Sicherungsschicht-Parametern

• CSLIP
• MPPE
• OSI-Modell
• PPPoA
• SLIP

• Pearson Studium, Andrew S. Tanenbaum, Computernetzwerke, S. 268ff (in 4. Auflage S. 238ff)
• Alle Codes wurden mit Wireshark ermittelt

• W. Simpson: RFC1661 – The Point-to-Point Protocol (PPP). Juli 1994 (löst RFC 1548 ab, englisch).
• W. Simpson: RFC1662 – PPP in HDLC-like Framing. Juli 1994 (löst RFC 1549 ab, englisch).

Commons: Point-to-Point Protocol – Sammlung von Bildern, Videos und Audiodateien

1. ↑ Point-to-Point (PPP) Protocol Field Assignments. Abgerufen am 31. Oktober 2019.