Point-to-Point Protocol
0x0021 – [[Internet Protocol]] IP
0x80fd – [[Compression Control Protocol]] CCP
0x8021 – [[IP Control Protocol]] IPCP
0xc021 – [[Link Control Protocol]] LCP
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 und Protocol.
== Herstellung einer PPP-Verbindung ==
PPP stellt die Kommunikation über eine Punkt-zu-Punkt-Verbindung in vier Phasen her:
#'''Verbindungsaufbau und Konfigurationsaushandlung''' – Ein PPP-Ausgangsknoten sendet [[Link Control Protocol|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 [[Vermittlungsschicht]]protokollen ([[OSI-Modell|OSI]]-Schicht) ausreicht. ''(optionale Phase)''
#'''Aushandlung der Konfiguration des Vermittlungsschichtprotokolls''' – Der PPP-Ausgangsknoten sendet [[NCP]]-Rahmen zur Auswahl und Konfiguration. Die Protokolle wie [[Internet Protocol|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 [[Link Control Protocol|LCP]]- oder [[NCP]]-Rahmen die Verbindung beenden oder ein externes Ereignis auftritt. (z.B. Inaktivität oder Benutzer)
=== 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 [[Digital Subscriber Line|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-Adresse]]n. 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 [[Point of Presence|PoP]] den Remote Access Server des [[Internet Service Provider|ISP]].
PoP ist in unserem Beispiel NortelNe_* und Client ist 3Com_*.
Blau gekennzeichnet ist das Options-Feld des PPP-Pakets. Dort werden Daten- und Optionen eingetragen. Auf dieses Feld wird sich ausschließlich bezogen.
'''LCP – Link Control Protocol'''
''Configuration Request:''
[[Bild:CBCP_req.png|center]]
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:''
[[Bild:CBCP_reject.png|center]]
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:''
[[Bild:CHAP_MRU_request.png|center]]
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 maximale MRU ist durch den PPP-Header um 8 Byte kleiner als die maximal mögliche [[Maximum Transfer Unit|MTU]] von 1500 Byte. Siehe auch [[PPPoE]].
''Configuration Nak:''
[[Bild:CHAP_MRU_nak.png|center]]
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:''
[[Bild:CHAP_Challenge.png|center]]
Nachdem der Client CHAP als Einstellung angenommen hat, sendet der PoP eine 128bit-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:''
[[Bild:CHAP_Response.png|center]]
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''
[[Bild:CHAP_Success.png|center]]
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 [[Password Authentication Protocol|PAP]] nicht als Klartext übertragen wird.
Als nächstes wird nun die Datenkompression eingestellt.
''Configuration Request – CCP:''
[[Bild:CCP_MPPC_request.png|center]]
Ü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:''
[[Bild:CCP_MPPC_reject.png|center]]
Da DSL überhaupt und damit auch der PoP ([[DSL-AC]]) keine Datenkompression ünterstützt, wird das CCP abgelehnt und nicht nur das MPPC.
'''NCP – Network Control Protocol'''
'''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 [[Domain Name System|DNS]] dazu. Der Client kann auch IP-Adressen vorschlagen. IPCP gehört zur NCP-Protokoll-Familie.
''Configuration Request:''
[[Bild:IPCP_IPcomp_DNS_WINS_IP.request.png|center]]
Der Client schickt eine Anfrage an den PoP. Diese Anfrage beinhaltet die IP-Header VJ-Kompression, den [[Windows Internet Naming Service|WINS]], [[Domain Name System|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 ünterstützt.
''Configuration reject:''
[[Bild:WINS_IPcomp_reject.png|center]]
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:''
[[Bild:IPCP_IP_DNS_request.png|center]]
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:''
[[Bild:IPCP_IP_DNS_nak.png|center]]
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
== Quellen ==
Pearson Studium, [[Andrew S. Tanenbaum]], Computernetzwerke, S. 268ff (in 4. Auflage S. 238ff)
Alle Codes wurden mit ethereal ermittelt.
== Weblinks ==
* RFC 1661 – Point-to-Point Protocol (PPP) July 1994;
* RFC 1662 – Point-to-Point Protocol in HDLC-like Framing
''Siehe auch:'' [[Serial Line Internet Protocol|SLIP]], [[CSLIP]], [[OSI-Modell]], [[PPPoE]], [[PPPoA]], [[MPPE]]
[[Kategorie:Netzwerkprotokoll]]
[[en:Point-to-Point Protocol]]
[[es:PPP]]
[[fi:PPP]]
[[fr:Protocole point point]]
[[ja:Point-to-Point Protocol]]
[[ku:PPP]]
[[nl:Point to Point Protocol]]
[[pl:PPP]]
[[ru:PPP (сетевой протокол)]]
[[sv:Point-to-Point Protocol]]
[[zh:点对点协议]]Diese Version des Artikels stammt vom 24.04.2006.
Der Inhalt dieser Seite basiert auf dem Artikel „Point-to-Point Protocol“ aus der freien Enzyklop�die Wikipedia und ist unter der GNU-Lizenz f�r freie Dokumentation ver�ffentlicht. Auf der Wikipedia-Seite ist eine Liste der Autoren einzusehen.