W i l l k o m m e n   b e i   [ www.mauspfeil.com ]
 
 







  www.esprit.de

 

Wörterbuch der Bedeutung
<<Zurück
Bitte wählen Sie einen Buchstaben:
A, Ä | B | C | D | E | F | G | H | I | J | K | L | M | N | O, Ö | P | Q | R | S | T | U, Ü | V | W | X | Y | Z | 0-9

Suchen:

(Groß-/Kleinschreibung wird nicht unterschieden)

Shopping-Bestseller-Suche:   
 Klicken Sie hier, um zur Shopping-Mall zu gelangen

Google


Point-to-Point Protocol

*** Shopping-Tipp: Point-to-Point Protocol

{| border="0" cellspacing="3" style="float:right;padding-left:15px" |+ '''PPP mit TCP/IP-Referenzmodell TCP/IP-Protokollstapel''' |----- | align="center" bgcolor="#FFEEBB" | ''Anwendung'' | align="center" bgcolor="#EEEEFF" | File Transfer Protocol FTP | align="center" bgcolor="#EEEEFF" | Simple Mail Transfer Protocol SMTP | align="center" bgcolor="#EEEEFF" | Hypertext Transfer Protocol HTTP | align="center" bgcolor="#EEEEFF" | Domain Name System DNS | align="center" bgcolor="#EEEEFF" | ... |----- | align="center" bgcolor="#FFEEBB" | ''Transport'' | colspan="3" align="center" bgcolor="#EEEEFF" | Transmission Control Protocol TCP | colspan="2" align="center" bgcolor="#EEEEFF" | User Datagram Protocol UDP |----- | rowspan="1" align="center" bgcolor="#FFEEBB" | ''Netzwerk'' | colspan="5" align="center" bgcolor="#EEEEFF" | Internet Protocol IP |----- | rowspan="2" align="center" bgcolor="#FFCC99" | '''Netzzugang''' | colspan="5" align="center" bgcolor="#9999FF" | '''PPP''' |----- | colspan="3" align="center" bgcolor="#EEEEEE" | ''Serielle Leitung'' | align="center" bgcolor="#EEEEEE" | ''Modem'' | align="center" bgcolor="#EEEEEE" | ... |} Das '''Point-to-Point Protocol''' (PPP, zu Deutsche Sprache deutsch „Punkt zu Punkt Protokoll“) ist in der Informationstechnologie ein Netzwerkprotokoll zum Verbindungsaufbau über Wählleitungen (zumeist über Modem oder Integrated Services Digital Network ISDN).

Details
Das PPP ermöglicht die Übertragung verschiedenster Netzwerkprotokolle (z. B. Internet Protocol IP, Internetwork Packet Exchange IPX, AppleTalk, ...) und wird in RFC 1661 standardisiert. Seltener wird PPP für statische Verbindungen (Standleitungen) verwendet, beispielsweise um die Authentifizierungs-Mechanismen (Password Authentication Protocol PAP, Challenge Handshake Authentication Protocol CHAP) zu nutzen. Hierfür kommen meist modifizierte Protokolle wie PPP over Ethernet PPPoE oder Point-to-Point Tunneling Protocol PPTP zum Einsatz. Heute ist PPP das Standardprotokoll, das Internet-Provider für die Einwahl der Kunden verwenden, die Spezifikationen sind jedoch so definiert, dass PPP nicht ausschließlich TCP/IP-Verbindungen unterstützt.

Aufbau von PPP
In diesem Absatz wird der Fall von PPP über High-Level Data Link Control HDLC gezeigt, wie im RFC 1662 beschrieben. Andere übliche PPP Benutzungen sind: PPP über Ethernet (PPP over Ethernet PPPoE) oder PPP über ATM (PPPoA). Bild:Ppp.png 830px '''HDLC Flag:''' Kennzeichnet die Frame-Begrenzung und entspricht dem High-Level Data Link Control 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 *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
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 Vermittlungsschichtprotokollen (OSI-Modell OSI-Schicht) ausreicht. ''(optionale Phase)'' #'''Aushandlung der Konfiguration des Vermittlungsschichtprotokolls''' – Der PPP-Ausgangsknoten sendet Network Control Protocol NCP-Rahmen zur Auswahl und Konfiguration. Die Protokolle wie Internet Protocol IP, Internetwork Packet Exchange 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 Network Control Protocol 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 PPP over Ethernet 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-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 Point of Presence PoP 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-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 Challenge Handshake Authentication Protocol 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 Transmission 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 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:'' 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 unterstü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 unterstü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

Siehe auch
* CSLIP * MPPE * OSI-Modell * PPPoA * PPP over Ethernet PPPoE * Serial Line Internet Protocol SLIP

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 Kategorie:Netzwerkprotokoll bs:Point-to-Point Protocol cs:Point-to-Point Protocol da:PPP en:Point-to-Point Protocol es:Point-to-Point Protocol eu:Point-to-Point Protocol fi:PPP fr:Protocole point à point it:PPP ja:Point-to-Point Protocol ku:PPP li:Point-to-Point Protocol nl:Point to Point Protocol pl:PPP pt:Protocolo Ponto-a-Ponto ru:Point-to-Point Protocol sl:Protokol od toÄ?ke do toÄ?ke sv:Point-to-Point Protocol tr:Point-to-Point Protocol uk:PPP vi:PPP (giao thức) zh:点对点å??è®®

*** Shopping-Tipp: Point-to-Point Protocol




[Der Artikel zu Point-to-Point Protocol stammt aus dem Nachschlagewerk Wikipedia, der freien Enzyklopädie. Dort findet sich neben einer Übersicht der Autoren die Möglichkeit, den Original-Text des Artikels Point-to-Point Protocol zu editieren.
Die Texte von Wikipedia und dieser Seite stehen unter der GNU Free Documentation License.]

<<Zurück | Zur Startseite | Impressum | Zum Beginn dieser Seite