The Cable GuyDas DHCPv6-Protokoll
Joseph Davies
Das Dynamic Host Configuration-Protokoll (DHCP) wurde entworfen, um Computern IP-Adressen und andere Netzwerkinformationen zuzuweisen, sodass sie im Netzwerk automatisch kommunizieren können. Bei einem IPv6-Netzwerk wird DHCP eigentlich nicht zum Konfigurieren von Adressen benötigt, es können jedoch gute Gründe für seine Verwendung sprechen. DHCP für IPv6 (DHCPv6) kann
die Einstellungen für statusbehaftete Adresskonfigurationseinstellungen oder statusfreie Konfigurationseinstellungen für IPv6-Hosts bereitstellen. IPv6-Hosts können mehrere Methoden verwenden, um Adressen zu konfigurieren:
Statusfreie automatische Adresskonfiguration wird zum Konfigurieren sowohl von verbindungslokalen Adressen als auch von zusätzlichen nicht verbindungslokalen Adressen durch den Austausch der Routeranfrage- und Routerankündigungsnachrichten mit angrenzenden Routern verwendet.
Statusbehaftete automatische Adresskonfiguration wird verwendet, um nicht verbindungslokale Adressen durch die Verwendung eines Konfigurationsprotokolls zu konfigurieren, z. B. DHCP.
Ein IPv6-Host führt eine statusfreie Autokonfiguration automatisch durch und verwendet ein Konfigurationsprotokoll, wie z. B. DHCPv6. Dies erfolgt aufgrund der folgenden Kennzeichen, die in der von einem angrenzenden Router gesendeten Routerankündigungsnachricht enthalten sind:
Das verwaltete Adresskonfigurationskennzeichen (Managed Address Configuration Flag), das auch M-Kennzeichen genannt wird. Wenn dieses Kennzeichen auf 1 eingestellt ist, wird der Host angewiesen, ein Konfigurationsprotokoll zu verwenden, um statusbehaftete Adressen zu erhalten.
Ein anderes statusbehaftetes Konfigurationskennzeichen, das auch O-Kennzeichen genannt wird. Wenn dieses Kennzeichen auf 1 eingestellt ist, wird der Host angewiesen, ein Konfigurationsprotokoll zu verwenden, um andere Konfigurationseinstellungen zu erhalten.
Wenn die Werte der M- und O-Kennzeichen kombiniert werden, kann sich Folgendes ergeben:
Beide Kennzeichen, sowohl M als auch O, sind auf 0 eingestellt. Diese Kombination entspricht einem Netzwerk ohne DHCPv6-Infrastruktur. Hosts verwenden Routerankündigungen für nicht verbindungslokale Adressen und andere Methoden (wie z. B. manuelle Konfiguration), um andere Einstellungen zu konfigurieren.
Beide Kennzeichen, sowohl M als auch O, sind auf 1 eingestellt. DHCPv6 wird sowohl für Adressen als auch für andere Konfigurationseinstellungen verwendet. Diese Kombination wird „DHCPv6 statusbehaftet“ genannt, wobei DHCPv6 den IPv6-Hosts statusbehaftete Adressen zuweist.
Das M-Kennzeichen ist auf 0 und das O-Kennzeichen auf 1 eingestellt. DHCPv6 wird nur dazu verwendet, andere Konfigurationseinstellungen, aber keine Adressen zuzuweisen. Angrenzende Router werden konfiguriert, um nicht verbindungslokale Adresspräfixe anzukündigen, von denen die IPv6-Hosts statusfreie Adressen ableiten. Diese Kombination wird „DHCPv6 statusfrei“ genannt: DHCPv6 weist IPv6-Hosts keine statusbehafteten Adressen, sondern statusfreie Konfigurationseinstellungen zu.
Das M-Kennzeichen ist auf 1 und das O-Kennzeichen auf 0 eingestellt. In dieser Kombination wird DHCPv6 für die Adresskonfiguration, nicht jedoch für andere Einstellungen verwendet. Da IPv6-Hosts in der Regel mit anderen Einstellungen konfiguriert werden müssen, wie z. B. den IPv6-Adressen der DNS-Server, stellt dies eine unwahrscheinliche Kombination dar.
Wie DHCP for IPv4 enthält eine DHCPv6-Infrastruktur folgende Komponenten: DHCPv6-Clients, die eine Konfiguration anfordern, DHCPv6-Server, die eine Konfiguration bereitstellen, und DHCPv6-Relay-Agents, die Nachrichten zwischen Clients und Servern übermitteln, wenn sich Clients in Subnetzen ohne DHCPv6-Server befinden.
DHCPv6-Nachrichten
Wie bei DHCP for IPv4 werden bei DHCPv6 UDP-Nachrichten (User Datagram Protocol) verwendet. DHCPv6-Clients fragen DHCP-Nachrichten auf UDP-Port 546 ab. DHCPv6-Server und Relay-Agents fragen DHCPv6-Nachrichten auf UDP-Port 547 ab. Die Struktur für DHCPv6-Nachrichten ist viel einfacher als für DHCP for IPv4, dessen Ursprung im BOOTP-Protokoll liegt, das zur Unterstützung von Arbeitsstationen ohne Datenträger diente. Abbildung 1 illustriert die Struktur von DHCPv6-Nachrichten, die zwischen Client und Server übermittelt werden.
Abbildung 1** DHCPv6-Nachrichten zwischen Client und Server **(Klicken Sie zum Vergrößern auf das Bild)
Das 1-Byte-Feld „Msg-Type“ zeigt den DHCPv6-Nachrichtentyp an. Das 3-Byte-Feld „Transaction-ID“ wird von einem Client bestimmt und dazu verwendet, die Nachrichten eines DHCPv6-Nachrichtenaustauschs zu gruppieren. Aufgrund des Felds „Transaction-ID“ werden DHCPv6-Optionen dazu verwendet, die Client- und Serveridentifikation, Adressen und andere Konfigurationseinstellungen anzuzeigen. Eine Liste der definierten DHCPv6-Optionen erhalten Sie in der RFC 3315 (siehe auch „DHCPv6-RFC-Ressourcen“ in der Randleiste).
DHCPv6-Optionen sind im Format Typ-Länge-Wert formatiert. Abbildung 2 illustriert die Struktur von DHCPv6-Optionen.
Das 2-Byte-Feld „Option-Code“ zeigt eine bestimmte Option an. Das 2-Byte-Feld „Option-Len“ zeigt die Länge des Felds „Option-Data“ in Bytes an. Das Feld „Option-Data“ enthält die Daten für die Option.
Es ist eine eigene Nachrichtenstruktur für die Nachrichten vorhanden, die zwischen Relay-Agents und Servern ausgetauscht werden, um zusätzliche Informationen aufzuzeichnen. Abbildung 3 illustriert die Struktur dieser Art von Nachrichten.
Abbildung 2** Struktur von DHCPv6-Optionen **(Klicken Sie zum Vergrößern auf das Bild)
Das 1-Byte-Feld „Hop-Count“ zeigt die Anzahl der Relay-Agents an, die die Nachricht empfangen haben. Ein empfangender Relay-Agent kann die Nachricht verwerfen, wenn sie eine konfigurierte maximale Hopanzahl überschreitet. Das 16-Byte-Feld „Link-Address“ enthält eine nicht verbindungslokale Adresse, die einer Schnittstelle zugewiesen wird, die mit dem Subnetz verbunden ist, in dem sich der Client befindet. Über das Feld „Link-Address“ kann der Server den richtigen Adressbereich für die Adresszuweisung bestimmen. Das 16-Byte-Feld „Peer-Address“ enthält die IPv6-Adresse des Clients, der die Nachricht ursprünglich gesendet hat, oder des vorherigen Relay-Agents, der die Nachricht übertragen hat. Abgesehen vom Feld „Peer-Address“ gibt es DHCPv6-Optionen, die die Option „Relay Message“ umfassen, in der die übertragene Nachricht und andere Optionen enthalten sind. Die Option „Relay Message“ stellt eine Kapselung der Nachrichten bereit, die zwischen dem Client und dem Server ausgetauscht werden.
Es gibt keine für IPv6 definierten Broadcastadressen. Daher ist die Verwendung der begrenzten Broadcastadresse für einige DHCPv4-Nachrichten durch die Verwendung der All_DHCP_Relay_Agents_and_Servers-Adresse FF02::1:2 für DHCPv6 ersetzt worden. Beispielsweise sendet ein DHCPv6-Client, der versucht, den Ort des DHCPv6-Servers im Netzwerk festzustellen, eine Solicit-Nachricht (Anfrage) von seiner verbindungslokalen Adresse an FF02::1:2. Wenn im Subnetz des Hosts ein DHCPv6-Server vorhanden ist, empfängt er die Solicit-Nachricht und sendet eine entsprechende Antwort. In der Regel empfängt jedoch ein DHCPv6-Relay-Agent im Subnetz des Hosts die Solicit-Nachricht und leitet sie an einen DHCPv6-Server weiter.
Abbildung 3** Struktur der Nachrichten zwischen Relay und Server **(Klicken Sie zum Vergrößern auf das Bild)
Statusbehafteter Nachrichtenaustausch
Ein statusbehafteter DHCPv6-Nachrichtenaustausch zum Abrufen von IPv6-Adressen und Konfigurationseinstellungen (wobei sowohl das M- als auch das O-Kennzeichen in einer empfangenen Routerankündigung auf 1 eingestellt ist) besteht standardmäßig aus den folgenden Nachrichten:
- Einer Solicit-Nachricht (Anfrage), die vom Client gesendet wird, um die Server zu lokalisieren.
- Einer Advertise-Nachricht (Ankündigung), die von einem Server gesendet wird, um anzuzeigen, dass er Adressen und Konfigurationseinstellungen bereitstellen kann.
- Einer Request-Nachricht (Anforderung), die vom Client gesendet wird, um Adressen und Konfigurationseinstellungen von einem bestimmten Server anzufordern.
- Einer Reply-Nachricht (Antwort), die vom angeforderten Server gesendet wird, der die Adressen und Konfigurationseinstellungen enthält.
Wenn zwischen dem Client und dem Server ein Relay-Agent vorhanden ist, sendet der Server die Relay-Forward-Nachrichten (Weiterleitung), die die gekapselten Solicit- und Request-Nachrichten des Clients enthalten. Der Server sendet die Relay-Reply-Nachrichten des Relay-Agents, die die gekapselten Advertise- und Reply-Nachrichten für den Client enthalten. Eine vollständige Liste der DHCPv6-Nachrichten findet sich in Abbildung 4.
Figure 4 DHCPv6-Nachrichten
| DHCPv6-Nachricht | Beschreibung | Entsprechende DHCP-for-IPv4-Nachricht |
| Solicit | Gesendet durch einen Client, um Server zu lokalisieren. | DHCPDiscover |
| Advertise | Gesendet durch einen Server als Antwort auf eine Solicit-Nachricht, um Verfügbarkeit anzuzeigen. | DHCPOffer |
| Request | Gesendet durch einen Client, um Adressen oder Konfigurationseinstellungen von einem bestimmten Server anzufordern. | DHCPRequest |
| Confirm | Gesendet durch einen Client an alle Server, um zu bestimmen, ob die Konfiguration eines Clients für den verbundenen Link gültig ist. | DHCPRequest |
| Renew | Gesendet durch einen Client an einen bestimmten Server, um die Gültigkeitsdauer der zugewiesenen Adressen zu verlängern und aktualisierte Konfigurationseinstellungen beizubehalten. | DHCPRequest |
| Rebind | Gesendet durch einen Client an einen beliebigen Server, wenn die Renew-Nachricht unbeantwortet blieb. | DHCPRequest |
| Reply | Gesendet durch einen Server an einen bestimmten Client als Antwort auf eine der folgenden Nachrichten: Solicit, Request, Renew, Rebind, Information-Request, Confirm, Release oder Decline. | DHCPAck |
| Release | Gesendet durch einen Client, um anzuzeigen, dass der Client keine zugewiesene Adresse mehr verwendet. | DHCPRelease |
| Decline | Gesendet durch einen Client an einen bestimmten Server, um anzuzeigen, dass die zugewiesene Adresse bereits verwendet wird. | DHCPDecline |
| Reconfigure | Gesendet durch einen Server an einen Client, um anzuzeigen, dass der Server neue oder aktualisierte Konfigurationseinstellungen hat. Der Client sendet dann entweder eine Renew- oder Information-Request-Nachricht. | Nicht zutreffend |
| Information-Request | Gesendet durch einen Client, um Konfigurationseinstellungen (nicht jedoch Adressen) anzufordern. | DHCPInform |
| Relay-Forward | Gesendet durch einen Relay-Agent, um eine Nachricht an einen Server weiterzuleiten. Eine Relay-Forward-Nachricht enthält eine Clientnachricht, die als DHCPv6-Relay Message-Option gekapselt ist. | Nicht zutreffend |
| Relay-Reply | Gesendet durch einen Server, um durch einen Relay-Agent eine Nachricht an einen Client zu senden. Eine Relay-Reply-Nachricht enthält eine Servernachricht, die als DHCPv6-Relay Message-Option gekapselt ist. | Nicht zutreffend |
Statusfreier Nachrichtenaustausch
Ein statusfreier DHCPv6-Nachrichtenaustausch für den ausschließlichen Abruf von Konfigurationseinstellungen, wenn in einer empfangenen Routerankündigung das M-Kennzeichen auf 0 und das O-Kennzeichen auf 1 eingestellt ist, besteht standardmäßig aus den folgenden Nachrichten: Einer Information-Request-Nachricht, die vom DHCPv6-Client gesendet wird, um Konfigurationseinstellungen von einem Server zu erhalten, und einer Reply-Nachricht, die von einem Server gesendet wird, der die angeforderten Konfigurationseinstellungen enthält.
Für ein IPv6-Netzwerk mit Routern, die so konfiguriert sind, dass sie IPv6-Hosts statusfreie Adresspräfixe zuweisen, kann der 2-Nachrichten-DHCPv6-Austausch verwendet werden, um DNS-Server, DNS-Domänennamen und andere Konfigurationseinstellungen zuzuweisen, die in der Routerankündigungsnachricht nicht enthalten sind.
DHCPv6-Unterstützung in Windows
Windows Vista™ und „Longhorn“, die nächste Version von Windows Server®, enthalten einen DHCPv6-Client. In Abhängigkeit von den Werten der M- und O-Kennzeichen in empfangenen Routerankündigungsnachrichten versucht der DHCPv6-Client, eine DHCPv6-basierte Konfiguration durchzuführen. Um DHCPv6 zu verwenden, müssen Sie daher die DHCPv6-Server und -Relay-Agents so konfigurieren, dass sie jedes IPv6-Subnetz verarbeiten, und müssen dann Ihre IPv6-Router konfigurieren, um die beiden Kennzeichen auf ihre entsprechenden Werte einzustellen. Wenn für ein bestehendes Subnetz mehrere Ankündigungsrouter vorhanden sind, sollten sie so konfiguriert werden, dass sie die gleichen statusfreien Adresspräfixe und Werte der M- und O-Kennzeichen ankündigen. IPv6-Hosts unter Windows® XP oder Windows Server 2003 enthalten keinen DHCPv6-Client und ignorieren daher die Werte der M- und O-Kennzeichen in empfangenen Routerankündigungen.
Sie können einen IPv6-Router, der Windows Vista oder Windows Server „Longhorn“ ausführt, so konfigurieren, dass das M-Kennzeichen in Routerankündigungen mit dem Befehl „netsh interface ipv6 set interface InterfaceName managedaddress=enabled“ auf 1 eingestellt wird. Gleichermaßen können Sie das O-Kennzeichen in Routerankündigungen mit dem Befehl „netsh interface ipv6 set interface InterfaceName otherstateful=enabled“ auf 1 einstellen.
Die Beta-2-Version von Windows Server „Longhorn“ unterstützt einen DHCPv6-Relay-Agent und die statusfreie DHCPv6-Konfiguration mit dem DHCP-Serverdienst. Sie können den DHCP-Serverdienst so konfigurieren, dass DHCPv6-Optionen an alle DHCPv6-Clients im 2-Nachrichten-DHCPv6-Austausch verteilt werden, wie bereits beschrieben. Microsoft beabsichtigt, in der Beta-3-Version von Windows Server „Longhorn“ den statusbehafteten DHCPv6-Vorgang zu unterstützen, einschließlich der Fähigkeit, IPv6-Adressbereiche im DHCP-Snap-In zu erstellen.
DHCPv6-RFC-Ressourcen
Ausgewählte RFCs bezüglich DHCPv6:
- RFC 3315 – Dynamic Host Configuration Protocol for IPv6 (DHCPv6) (auf Englisch)
- RFC 2462 – IPv6 Stateless Address Autoconfiguration (auf Englisch)
- RFC 3633 – IPv6 Prefix Options for DHCP Version 6 (auf Englisch)
- RFC 3646 – DNS Configuration Options for DHCPv6 (auf Englisch)
- RFC 3736 – Stateless DHCP Service for IPv6 (auf Englisch)
Joseph Daviesist technischer Redakteur bei Microsoft und lehrt und schreibt seit 1992 über Themen im Bereich der Windows-Netzwerke. Er hat fünf Bücher für Microsoft Press verfasst und ist der Autor der monatlich erscheinenden TechNet-Rubrik „The Cable Guy“
© 2008 Microsoft Corporation und CMP Media, LLC. Alle Rechte vorbehalten. Die nicht genehmigte teilweise oder vollständige Vervielfältigung ist nicht zulässig.