The Cable Guy - Dezember 2006
IPv6 over PPP-Verbindungen
Von The Cable Guy
Alle auf Deutsch verfügbaren Cable Guy-Kolumnen finden Sie unter http://www.microsoft.com/germany/technet/community/columns/cableguy/cgarch.mspx.
Microsoft® Windows Vista™ und Windows Server® Code Name "Longhorn" unterstützen nun IPv6 over PPP-Verbindungen (Internet Protocol version 6 over Point-to-Point Protocol) über den standardmäßigen RAS-Client. Durch diese neue Möglichkeit sind RAS-Clients und Bedarfswahlrouter in der Lage, nativen IPv6-Netzwerkverkehr über eine PPP-Verbindung zu senden (zum Beispiel eine Einwahlverbindung oder eine VPN-Verbindung). Außerdem ist es Internet-Clients möglich, PPP over Ethernet (PPPoE) für Breitband-Internetverbindungen und IPv6-fähige Internetanbieter zu nutzen. In diesem Artikel beschreiben wir, wie IPv6-Pakete beim Senden über PPP-Verbindungen formatiert werden. Außerdem erfahren Sie mehr zu IPV6CP (IPv6 Control Protocol), über das IPv6-Konfigurationsoptionen für die PPP-Verbindung ausgehandelt werden.
Anmerkung: Dieser Artikel geht davon aus, dass Sie sich mit IPv4, IPv6 und dem PPP-Protokoll auskennen.
Auf dieser Seite
 | Einleitung |
| PPP-Kapselung von IPv6-Paketen |
| IPV6CP-Konfigurationsoptionen |
| Zusätzliche Informationen |
Einleitung
PPP ist ein Standardverfahren (RFC 1661) für Point-to-Point-Verbindungen, über die Pakete verschiedenster Protokolle übertragen werden. PPP führt hierbei die folgenden Funktionen aus:
| • | Kapselung von anderen Protokollen auf Datenschicht: PPP erstellt Rahmen, in denen sich Pakete der Netzwerkschicht befinden. |
| • | Einrichtung, Betrieb und Beendigung einer logischen Verbindung: Das PPP-Protokoll nutzt LCP (Link Control Protocol), um die Parameter für die Verbindung auf Datenschicht einzurichten. Teil der LCP-Aushandlung ist hierbei die Authentifizierung der Sicherheitsinformationen auf dem PPP-Client. |
| • | Protokollkonfiguration: Nachdem die Verbindung ausgehandelt ist, müssen Protokolle der Netzwerkschicht (zum Beispiel IPv4 oder IPv6) konfiguriert werden. Bei IPv4 wird dem RAS-Client zum Beispiel über den RAS-Server eine IP-Adresse zugewiesen. Auch die Komprimierung und Verschlüsselung muss ausgehandelt werden. |
Es gibt vier Phasen bei der Aushandlung einer PPP-Verbindung:
1. | Konfiguration der PPP-Verbindung |
2. | Authentifizierung |
3. | Callback (optional) |
4. | Protokollkonfiguration |
In Phase 4 konfiguriert ein entsprechendes Protokoll Einstellungen für jedes Protokoll, das auf Netzwerkschicht Daten über die PPP-Verbindung senden soll. Bei IP handelt es sich hierbei um IPCP (IP Control Protocol). IPCP verfügt über eine Vielzahl von Konfigurationsoptionen, über die eine IP-Adressen von DNS-Servern zugewiesen werden können. Während der IPCP-Aushandlung einigen sich beide PPP-Peers auf IPv4-Konfigurationsoptionen. Bei IPv6 wird IPV6CP eingesetzt (RFC 2472).
Weitere Informationen zu den einzelnen Phasen finden Sie unter Die Funktionsweise von Einwahl-RAS-Verbindungen - Windows Server 2003: Technische Referenz (engl.).
In den folgenden Abschnitten beschreiben wir die Kapselung von IPv6-Paketen über PPP-Verbindungen und die IPV6CP-Konfigurationsoptionen.
PPP-Kapselung von IPv6-Paketen
Die PPP-Kapselung nutzt eine Variante des ISO-Protokolls HDLC (High Level Data Link Control), welches in RFC 1662 beschrieben wird. In Abbildung 1 sehen Sie, wie PPP IPv6-Pakete über HDLC kapselt.
Abbildung 1: Kapselung von IPv6-Paketen mit HDLC
Im PPP-Header und -Trailer gibt es die folgenden Fehler:
| • | Flag: Legt Start und Ende des PPP-Rahmens fest und wird auf den Wert 0x7E gesetzt. In aufeinander folgenden PPP-Rahmen wird nur ein einzelnes Flag-Zeichen genutzt, um sowohl das Ende eines PPP-Rahmens als auch den Start des nächsten PPP-Rahmens zu markieren. Das Feld ist ein Byte groß. |
| • | Address: Wird in HDLC-Umgebungen genutzt, um den Rahmen an einen Zielknoten zu senden. Bei einer Point-to-Point-Verbindung muss kein Zielknoten angegeben werden. Daher ist das Feld bei PPP auf den Wert 0xFF gesetzt (der Broadcastadresse). Das Feld ist ein Byte groß und wird normalerweise nicht verwendet. |
| • | Control: Wird in HDLC-Umgebungen zur Sequenzierung und für Acknowledgments auf Datenschicht genutzt. Bei PPP ist das Feld auf den Wert 0x3 gesetzt (UI-Rahmen - nicht nummerierter Rahmen). Das Feld ist ein Byte groß und wird normalerweise nicht genutzt. |
| • | Protocol: Legt das Protokoll für den PPP-Datenteil fest. Das Protokollfeld wird auf den Wert 0x00-57 gesetzt (IPv6-Paket). Bei IPv4 hat das Feld den Wert 0x00-21. Das Feld ist zwei Byte groß. Normalerweise wird jedoch das erste Byte ignoriert. |
| • | Frame Check Sequence: Enthält eine Checksumme, mit der Bitfehler im PPP-Rahmen ermittelt werden können. Das Feld ist zwei Byte groß. |
Die MTU für eine PPP-Verbindung (auch Maximum Receive Unit genannt) wird über LCP ausgehandelt. Die standardmäßige MRU ist 1.500 Byte groß. Bei einem kleineren Wert muss der PPP-Host trotzdem noch in der Lage sein, Rahmen zu senden und zu empfangen, die mindestens der minimalen MTU von IPv6 entsprechen (1.280 Byte).
IPV6CP-Konfigurationsoptionen
IPV6CP-Konfigurationsoptionen werden in IPV6CP-Nachrichten gesendet. Sie verwenden den gleichen Paketaufbau und die gleichen Aushandlungsverfahren wie LCP-Nachrichten. Weitere Informationen zu LCP finden Sie unter Die Funktionsweise von Einwahl-RAS-Verbindungen - Windows Server 2003: Technische Referenz (engl.).
In Abbildung 2 sehen Sie den Aufbau von IPV6CP-Nachrichten.
Abbildung 2: Aufbau von IPV6CP-Nachrichten
IPV6CP nutzt das PPP-Protokoll 0x80-57. Jede IPV6CP-Nachricht besteht aus einem Code-Feld, das die Art der Nachricht anzeigt, einem Identifier-Feld, mit dem Anfragen und Antworten erkannt werden, einem Length-Feld, das die Größe der Nachricht festlegt, und einer oder mehreren IPV6CP-Optionen.
Für IPV6CP wurden die folgenden Nachrichtentypen definiert:
| • | Configure-Request (Code=1): Startet die IPV6CP-Aushandlung. Enthält eine Liste mit IPV6CP-Optionen, die von den Standardeinstellungen abweichen. |
| • | Configure-Ack (Code=2): Zeigt an, dass alle Werte für IPV6CP-Optionen aus der letzten Configure-Request-Nachricht empfangen und akzeptiert wurden. Wenn beide PPP-Peer Configure-Acks senden und empfangen, ist die IPV6CP-Aushandlung vollständig. |
| • | Configure-Nack (Code=3): Zeigt an, dass alle IPV6CP-Optionen empfangen wurden, aber einige Optionen nicht akzeptiert werden. Die nicht akzeptierten Optionen und die entsprechenden akzeptablen Werte sind in der Nachricht enthalten. |
| • | Configure-Reject (Code=4): Zeigt an, dass bestimmte IPV6CP-Optionen nicht empfangen wurden oder für die Aushandlung nicht akzeptabel sind. Die entsprechenden Optionen sind in der Nachricht enthalten. |
| • | Terminate-Request (Code=5): Kann optional gesendet werden, um die IPV6CP-Aushandlung zu schließen. |
| • | Terminate-Ack (Code=6): Wird als Reaktion auf Terminate-Request gesendet. |
| • | Code-Reject (Code=7): Wird gesendet, wenn eine IPV6CP-Option unbekannt ist. Enthält die entsprechende Option. |
RFC 2472 definiert die folgenden Konfigurationsoptionen für IPV6CP:
| • | Interface-Identifier |
| • | IPv6-Compression-Protocol |
Interface-Identifier-Option
Mit der Option Interface-Identifier handeln PPP-Peers die Verwendung der acht Byte langen Schnittstellen-ID der lokalen zur PPP-Schnittstelle zugewiesenen Adresse aus. In Abbildung 3 sehen Sie den Aufbau der Interface-Identifier-Option.
Abbildung 3: Die Option Interface-Identifier
PPP-Peers können die Schnittstellen-ID von der einer physischen Schnittstelle zugewiesenen Adresse (zum Beispiel einer IEEE 802-Adresse) oder von anderen auf dem Peer eindeutigen Seriennummern ableiten. Wenn es jedoch keine entsprechende Information gibt, mit der die ID für die PPP-Schnittstelle abgeleitet werden kann, dann kann der Peer seine Schnittstellen-ID auf 0 setzen und muss dem anderen Peer die Ermittlung einer Schnittstellen-ID überlassen. Die beiden PPP-Peers müssen dafür sorgen, dass jeder Peer eine eindeutige Schnittstellen-ID nutzt. Im Folgenden sehen Sie Beispiele für die Aushandlung von Schnittstellen-IDs:
| • | PPP-Peer A ermittelt eine Schnittstellen-ID auf Basis einer lokalen Hardwareadresse. PPP-Peer B ermittelt eine andere Schnittstellen-ID auf Basis einer lokalen Hardwareadresse. Peer A sendet eine IPV6CP-Configure-Request-Nachricht mit seiner Schnittstellen ID in der Interface-Identifier-Option. Peer B überprüft die ID von A, stellt fest, dass sie sich von seiner eigenen unterscheidet, und sendet eine Configure-Ack-Nachricht an Peer A. Peer B sendet eine Configure-Request-Nachricht mit seiner ID. Peer A prüft die ID von B, stellt fest, dass sie sich von seiner unterscheidet, und sendet eine Configure-Ack-Nachricht an B. Die IPV6CP-Aushandlung ist abgeschlossen. |
| • | Peer A ermittelt eine ID auf Basis einer lokalen Hardwareadresse. Peer B kann keine ID ermitteln und setzt diese daher auf 0. Peer A sendet eine Configure-Request-Nachricht mit seiner ID. Peer B überprüft die ID von A, stellt fest, dass sie von seiner abweicht, und sendet eine Configure-Ack-Nachricht an A. Peer B sendet eine Configure-Request-Nachricht mit seiner ID (0). Peer A überprüft die ID, ermittelt eine weitere Schnittstellen-ID (die sich von seiner unterscheidet) und sendet eine Configure-Nack-Nachricht mit der ID an Peer B. Die IPV6CP-Aushandlung ist abgeschlossen. |
Weitere Beispiele für die Aushandlung sind in RFC 2472 beschrieben.
IPv6-Compression-Protocol-Option
Mit der IPv6-Compression-Protocol-Option zeigen PPP-Peers an, dass sie in der Lage sind, IPv6-Pakete zu empfangen, die über ein bestimmtes Protokoll oder über ein bestimmtes Verfahren komprimiert wurden. Ein Beispiel für ein solches Protokoll ist ROHC over PPP (Robust Header Compression), das in RFC 3241 definiert wurde.
In Abbildung 4 sehen Sie den Aufbau der Option IPv6-Compression-Protocol.
Abbildung 4: Aufbau der Option IPv6-Compression-Protocol
Die Option IPv6-Compression-Protocol enthält ein zwei Byte großes Feld, das ein bestimmtes Kompressionsprotokoll oder -verfahren definiert. Zusätzlich können - abhängig vom Protokoll oder Verfahren - optionale Daten folgen.
Zusätzliche Informationen
Weitere Informationen finden sie unter: