Punkt-zu-Punkt-Protokoll

PPP im TCP/IP‑Protokollstapel:

Anwendung	HTTP	IMAP	SMTP	DNS	…
Transport	TCP			UDP
Internet	IP (IPv4, IPv6)
Netzzugang	PPP
	Serielle Verbindung		Modem		…

Das Point-to-Point Protocol (PPP, zu deutsch „Punkt-zu-Punkt-Protokoll“) ist in der Informationstechnologie ein Netzwerkprotokoll zum Verbindungsaufbau über Wählleitungen. Das Protokoll basiert auf HDLC und ist der Nachfolger von SLIP sowie einer Reihe weiterer 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.

Details

Die Spezifikation von PPP ist nicht auf TCP/IP-Verbindungen beschränkt, sondern ermöglicht verschiedene Netzwerkprotokolle (z. B. IP, 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.

Aufbau von PPP

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

Aufbau eines PPP-Frames

HDLC Flag:

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

HDLC Adresse:

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

HDLC Steuerung (Control):

Der Standardwert 00000011b 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.

Protokoll / Protocol: 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:

• 0x0021 – Internet Protocol IP
• 0x80fd – Compression Control Protocol CCP
• 0x8021 – IP Control Protocol IPCP
• 0xc021 – Link Control Protocol LCP
• 0xc023 – Password Authentication Protocol PAP
• 0xc223 – Challenge Handshake Authentication Protocol CHAP

Nutzdaten:

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

HDLC Prüfsumme (FCS):

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

Herstellung einer PPP-Verbindung

Grundlegende Vorgehensweise

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

1. Verbindungsaufbau und Konfigurationsaushandlung – Ein PPP-Ausgangsknoten sendet LCP-Rahmen zur Konfiguration und zum Aufbau der Datenverbindung.
2. 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)
3. 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.
4. 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)

Beispiel

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 Antwortspiel meist verschachtelt abläuft. Als Client bezeichne ich hier den Rechner des Internetnutzers und als PoP („Point of Presence“) den Remote Access Server des Internet Service Providers (ISP). 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.

LCP – Link Control Protocol

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 PoP. Dies gilt vor allem für ISDN-Verbindungen. Durch den Rückruf des PoP 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. Siehe auch PPPoE.

Configuration Nak:

Configuration Nak (Nak bedeutet 'Not acknowledged') bedeutet im Unterschied zu Reject soviel 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

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:

Ü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.

NCP – Network Control Protocol

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

Das IPCP – IP Control Protocol

Das IPCP wird zum Beispiel zur IP-Vergabe und zur Einstellung der IP-Header-Kompression benutzt. Die IP-Vergabe betrifft die IP-Adresse des PoP und die dynamische IP, welche der ISP aus einem IP-Pool vergibt, des Client. Des Weiteren kommen die zwei IP-Adressen des DNS 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 IP des PoP. 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-Frame 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.

Merkmale

• Fehlererkennung
• dynamische IP-Adressen-Zuweisung
• Authentifizierungsmechanismen
• aushandeln von Sicherungsschicht-Parameter

Siehe auch

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

Quellen

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

Weblinks

• RFC 1661 – Point-to-Point Protocol (PPP) July 1994;
• RFC 1662 – Point-to-Point Protocol in HDLC-like Framing