DHCPv6/DHCPv4

DHCPv6/DHCPv4 - Beschreibung

Beschreibung

Genauso wie IPv4 und IPv6 ihre Gemeinsamkeiten und Unterschiede haben, gibt es auch Gemeinsamkeiten und Unterschiede zwischen DHCP und DHCPv6

• In IPv4-Netzwerken können die IP-Adressen der Knoten entweder statisch konfiguriert oder dynamisch mit DHCP zugewiesen werden. ‚‘'IPv6'‚‘ bietet mehrere Methoden zur Zuweisung von IPv6-Adressen an Endknoten
• Natürlich können Knoten ihre IPv6-Adresse statisch konfigurieren, aber es gibt auch zwei dynamische Adresskonfigurationsmethoden: StateLess Address AutoConfiguration (SLAAC) und Stateful DHCPv6
• In diesem Artikel werden DHCP und DHCPv6 verglichen

Gemeinsamkeiten

Beide Protokolle sind Standards, die von der Internet Engineering Task Force (IETF) innerhalb der Dynamic Host Configuration Working Group (DHC WG) veröffentlicht wurden

• DHCP wurde ursprünglich 1993 (vor über 30 Jahren) in RFC 1531 definiert und 1997 in RFC 2131 weiterentwickelt
• DHCPv6 wurde erstmals 2003 (ein Jahrzehnt nach Veröffentlichung des ersten RFC zu DHCP) in RFC 3315 definiert, die aktuelle Version ist in RFC 8415 definiert

DHCP und DHCPv6 haben viele grundlegende Eigenschaften gemeinsam

• Beide Protokolle erfüllen die Funktion der dynamischen Zuweisung einer IP-Adresse an einen Endhost
• Beide verfügen über das Konzept eines Bereichs oder einer Reichweite und einer Leasinggabe einer einzelnen Adresse an einen Endknoten
• Beide Protokolle haben die gleichen funktionalen Komponenten: einen DHCP/DHCPv6-Client-Endknoten, einen DHCP/DHCPv6-Relay-Vermittler und einen DHCP/DHCPv6-Server
• Dieselben Clients, Relays und Server können DHCP und DHCPv6 gleichzeitig in einem Dual-Protokoll-Szenario verwenden

Es wird häufig empfohlen, dass Unternehmen für IPv4 und IPv6 dasselbe Betriebsmodell verwenden

• Wenn ein Unternehmen heute DHCP in seinen IPv4-Netzwerken verwendet, ist es sinnvoll, DHCPv6 für seine IPv6-Netzwerke zu wählen
• Für Unternehmen kann es sich administrativ als aufwändig erweisen, DHCP für IPv4 und SLAAC mit rekursivem DNS-Server (RDNSS) und DNS-Suchliste (DNSSL) (RFC 8106) für IPv6 zu verwenden
• In diesem Fall ist es möglicherweise am besten, die Dinge einfach zu halten und DHCPv6 neben DHCP einzusetzen
• Es kann jedoch weiterhin Geräte geben, wie z. B. solche mit Android- oder ChromeOS-Betriebssystem, die DHCPv6 nicht unterstützen

Unterschiedliche UDP-Portnummern

DHCP und DHCPv6 verwenden beide ein verbindungsloses Dienstmodell mit User Datagram Protocol (UDP)-Nachrichten im Zugangssegment

• IPv4-DHCP-Server (oder Relays) hören auf UDP-Port 67, und der Client hört auf UDP-Port 68 (die gleichen Ports wie BOOTP)
• Bei IPv6 lauschen DHCPv6-Clients auf dem UDP-Port 546 und die DHCPv6-Server und Relay-Agenten auf dem UDP-Port 547
• Diese Portnummern sind bekannte registrierte Portnummern, die von der Internet Assigned Number Authority (IANA) im „Service Name and Transport Protocol Port Number Registry“ dokumentiert sind

DORA versus SARR

DHCP und DHCPv6 sind funktional gleichwertig, da ein Client zustandsbehaftet Nachrichten oft über einen Relay an den Server sendet

• Die Nachrichtentypen und -namen unterscheiden sich jedoch
• IPv4-DHCP-Clients senden zunächst eine DHCPDISCOVER-Nachricht an die IPv4-Broadcast-Adresse (z
• B. 255.255.255.255), woraufhin der Server mit einer DHCPOFFER-Nachricht antwortet
• Der Client sendet dann eine DHCPREQUEST-Nachricht, und schließlich schließt der Server die Transaktion mit einer DHCPACK-Bestätigungsnachricht ab
• Dies wird als Discover, Offer, Request, Acknowledge oder „DORA“ abgekürzt
• Bei DHCPv6 lauten die vier Nachrichten, die zwischen dem Client und dem Server ausgetauscht werden, SOLICIT, ADVERTISE, REQUEST, REPLY (oder „SARR“)
• Die folgende Tabelle listet die funktional äquivalenten DHCP- und DHCPv6-Nachrichtentypen und -namen auf

‚‘'DHCP-Nachrichtentypen'‚‘	‚‘'DHCPv6-Nachrichtentypen'‚‘
DHCPDISCOVER	SOLICIT
DHCPOFFER	ADVERTISE
DHCPREQUEST	REQUEST
DHCPACK	REPLY
DHCPRELEASE	RELEASE
DHCPINFORM	INFORMATION-REQUEST
DHCPDECLINE	DECLINE

Diese Tabelle listet die gängigsten Nachrichten auf, es gibt jedoch noch viele weitere DHCP- und DHCPv6-Nachrichtentypen, auf die wir hier nicht eingehen

Effiziente Nutzung von Multicast anstelle von Broadcast

Ein wesentlicher Unterschied zwischen IPv4 und IPv6 besteht in der Verwendung von Broadcast- und/oder Multicast-Nachrichten

• IPv4-Netzwerke konnten Subnetz-Broadcast-Nachrichten verwenden, die unter Verwendung von 255.255.255.255 an alle lokalen Knoten gesendet wurden, oder IPv4 konnte Multicast-Zieladressen (224.0.0.0/4) verwenden
• IPv6 verfügt über keinen Mechanismus oder Adresstyp, der als Broadcast fungiert
• Stattdessen verwendet IPv6 Multicast-Adressen (ff00::/8) für alle Eins-zu-Viele-Kommunikationen

Dieser Unterschied überträgt sich auf die Funktionsweise von DHCP und DHCPv6 in einem Client-Zugangsnetzwerk

• DHCP-Clients senden ihre DHCPDISCOVER- und DHCPREQUEST-Nachrichten als Broadcast an 255.255.255.255
• Alle anderen Knoten im lokalen Segment empfangen diese Nachricht und müssen sie verarbeiten und entscheiden, ob sie darauf reagieren müssen
• Der DHCP-Relay empfängt diese unaufgeforderte Broadcast-Nachricht und leitet sie an den DHCP-Server weiter
• Beispielsweise wird die IPv4-Zugangsnetzwerkschnittstelle eines Cisco-Routers mit einem „ip helper“-Befehl mit der Unicast-IPv4-Adresse des DHCP-Servers konfiguriert

Mit DHCPv6 senden Clients ihre erste SOLICIT-Nachricht an die link-lokale Multicast-Adresse ff02::1:2 des Bereichs All_DHCP_Relay_Agents_and_Servers

• Das On-Link-DHCPv6-Relay (oder der DHCPv6-Server) ist auf diese Multicast-Adresse eingestellt und empfängt und verarbeitet diese Nachrichten
• Der DHCPv6-Relay könnte auch die Multicast-Adresse ff05::1:3 im lokalen Bereich „All_DHCP_Servers“ verwenden, um Nachrichten an alle DHCPv6-Server in der Umgebung zu senden
• In ähnlicher Weise verwendet er auf der IPv6-Zugangsschnittstelle eines Cisco-Routers den Befehl „ipv6 dhcp relay destination“ mit der globalen Unicast-Adresse des DHCPv6-Servers

Unterschiede bei den Client-Quelladressen

Endhosts, die DHCP und/oder DHCPv6 verwenden, befinden sich zunächst in einem „Henne-Ei“-Dilemma, da sie ein Paket senden müssen, um den Prozess zum Abrufen einer Unicast-Adresse zu starten, aber auch eine Quelladresse für ihre erste DHCP- oder DHCPv6-Kommunikation benötigen

• IPv4-DHCP-Clients verwenden 0.0.0.0 als erste Quelladresse zum Senden ihrer DHCPDISCOVER- und DHCPREQUEST-Nachrichten
• DHCPv6-Clients verwenden ihre link-lokale IPv6-Adresse (im Netzwerk fe80::/10), wenn sie ihre SOLICIT- und REQUEST-Nachrichten zur Kommunikation mit dem Relay oder Server senden
• DHCP verwendet Broadcasts, um Nachrichten an das Relay oder den Server zu senden, und das Relay oder der Server verwendet Unicast-Adressen, um die Antworten zurückzusenden
• Bei DHCP erhält der Client seine Adresse in der Zieladresse der DHCPOFFER-Nachricht
• DHCPv6-Clients und Relay/Server verwenden ihre link-lokalen Adressen als Quelladresse, und der Relay/Server ist auf link-lokale Multicasts eingestellt, um Nachrichten von Clients zu empfangen
• DHCPv6-Clients erhalten ihre globale Unicast-Adresse erst, wenn der vollständige Vier-Wege-Protokollwechsel abgeschlossen ist

Router-Advertisement-Nachrichten initiieren DHCPv6

Einer der Hauptunterschiede zwischen der Funktionsweise von IPv4 und IPv6 in einem LAN-Segment ist die Verwendung von ICMPv6 für die Routererkennung in IPv6

• IPv6-Router senden ICMPv6-Nachrichten vom Typ 134 (Router Advertisement, RA) an die link-lokale Multicast-Adresse ff02::1 aller Knoten, um Informationen über das lokale Netzwerk an alle Knoten im Segment weiterzugeben
• Diese vom First-Hop-Router gesendeten RAs sind wichtige Nachrichten, die den Startvorgang für Endknoten initiieren
• Tatsächlich ist es die RA mit dem auf „1“ gesetzten Flag „Managed Address Configuration“, die einen Client dazu veranlasst, den DHCPv6-Prozess zur Zuweisung einer zustandsbehafteten Adresse zu starten
• IPv4 verfügt über keine Entsprechung zur Router-Erkennungsfunktion
• Ein DHCP-Client startet einfach und sendet die DHCPDISCOVER-Nachricht, um den Prozess zu starten

MACs versus DUIDs

DHCP verwendet die MAC-Adresse der Verbindungsschicht als Kennung für den Client

• Die MAC-Adresse des Clients wird vom Relay und vom Server notiert und mit der Adresszuweisung verknüpft
• DHCPv6 verwendet für die Client-Kennung eine sogenannte DHCP Unique Identifier (DUID)
• In DHCPv6 (RFC 8415) sind vier DUID-Typen definiert, wobei die Wahl des DUID-Formats dem Client überlassen bleibt

1. Link-Layer-Adresse plus Zeit (DUID-LLT) – wird von Windows 10/11-Clients und Apple MacOS verwendet
2. Vom Hersteller zugewiesene eindeutige ID basierend auf der Enterprise ID (DUID-EN) – wird von einigen Linux-Distributionen verwendet
3. Link-Layer-Adresse (DUID-LL)
4. UUID-basierte DUID (DUID-UUID) (RFC 6355) – wird von einigen Linux-Distributionen verwendet

Dies kann für Unternehmen eine operative Herausforderung darstellen, da DHCP und DHCPv6 nicht einfach beide die MAC-Adresse des Clients verwenden

• Tom Coffeen hat eine zweiteilige Blog-Reihe (Teil 1, Teil 2) geschrieben, und Ed Horley hat ebenfalls einen Blog über die Herausforderungen der Verwaltung von MAC-Adressen für DHCP und DUIDs für DHCPv6 verfasst

DHCP und DHCPv6 ermöglichen beide die Erstellung einer statischen Reservierung

• Für IPv4 ermöglicht DHCP die Erstellung einer festen Adressbindung zwischen einer IP-Adresse basierend auf der MAC-Adresse des Clients
• Durch die Nutzung von „IPAM DHCP“ wird eine optimierte Verwaltung der Adresszuweisungen und der Leasingverfolgung für DHCP- und DHCPv6-Umgebungen gewährleistet
• Für IPv6 verwendet DHCPv6 die DUID für die statische Reservierungszuordnung zur globalen IPv6-Adresse innerhalb des Bereichs

Hohe Verfügbarkeit

Für IPv4-Netzwerke, die im Falle eines Ausfalls einen hochverfügbaren Satz von DHCP-Servern erforderten, konnten Leases beibehalten und neue Leases von den überlebenden DHCP-Servern bereitgestellt werden

• Zunächst wurde das DHCP-Failover-Protokoll konzipiert und später der „DHC Load Balancing Algorithm“ (RFC 3074) vorgeschlagen

Hochverfügbarkeit war für DHCPv6-Server bisher eine Herausforderung, da es keine standardisierte Redundanzmethode gab

• Die IETF hat diese Probleme in „DHCPv6 Redundancy Deployment Considerations“ (RFC 6853) und „DHCPv6 Failover Requirements“ (RFC 7031) dokumentiert
• Mit dem DHCPv6-Failover-Protokoll (RFC 8156) entspricht die Redundanz von DHCPv6-Servern nun der Redundanz von DHCP-Servern
• Infoblox hat gemeinsam mit dem Internet Systems Consortium (ISC) an weiteren Formen der DHCPv6-Redundanz gearbeitet, die nun vom Kea DHCPv6-Server unterstützt werden

Lease-Zeiten für DHCP und DHCPv6

Da der IPv4-Adressraum knapp ist, sind die Bereiche in der Regel klein und die Lease-Zeiten sehr niedrig angesetzt, um Adressraum zu sparen

• Tatsächlich können DHCP-Netzwerke sogar so konfiguriert werden, dass Clients ihre Adressen freigeben, bevor sie ein Netzwerk verlassen
• IPv6-Subnetze sind hingegen groß (in der Regel /64) und es besteht keine Gefahr, dass der Pool erschöpft wird
• Daher können Clients bei jedem Beitritt zu einem Netzwerk eine neue Adresse anfordern
• Die maximale Anzahl von Knoten in einem IPv4-Subnetz kann aufgrund der Gefahr von Subnetz-Broadcast-Stürmen auf einige Hundert begrenzt sein
• Andererseits ermöglicht die effiziente Nutzung von Multicast durch IPv6, dass Netzwerke weitaus mehr Knoten in einem reinen IPv6-Segment haben können

Die DHCPv6-Lease-Zeiten müssen nicht mit den IPv4-DHCP-Lease-Zeiten des Netzwerks übereinstimmen

• Bei beiden Protokollen erfolgt die Erneuerung nach der Hälfte der Lease-Zeit, dies kann jedoch angepasst werden und ist implementierungsspezifisch
• Die DHCPv6-Lease-Zeiten können jedoch von den üblichen IPv4-DHCP-Lease-Zeiten abweichen, sodass Sie möglicherweise unterschiedliche Lease-Zeiten für DHCP und DHCPv6 festlegen möchten

DHCPv6-Bereiche sind in der Regel /64-Präfixe, und DHCPv6-Server verfügen über genügend verfügbare Adressen, um bei jeder Lease-Anforderung eines Clients eine neue Adresse zuzuweisen

• Auf einem Infoblox NIOS-System können Sie DHCP-Bereich/Leases und DHCPv6-Lease-Affinität konfigurieren
• Der DHCPv6-Server erneuert und wiederverwendet Leases bis zum Intervall, wiederverwendet, erneuert und bereinigt jedoch nach diesem Intervall abgelaufene Leases
• Das Intervall ist konfigurierbar und reicht von 7 (Standard in Infoblox) bis zu maximal 180 Tagen

DHCP- und DHCPv6-Optionen

Ein weiterer Unterschied zwischen DHCP und DHCPv6 besteht in der Art und Weise, wie Optionen verarbeitet werden

• Optionen ermöglichen es DHCP- (RFC 2132) und DHCPv6-Servern, zusätzliche Konfigurationsinformationen mit Clients auszutauschen
• DHCPv6-Optionen unterscheiden sich von DHCP für IPv4, sind jedoch funktional gleichwertig
• Sowohl das DHCP- als auch das DHCPv6-Protokoll bieten Optionen für den Endknoten, um zusätzliche Informationen bereitzustellen, wobei DHCP ein einzelnes Oktett-Optionsfeld verwendet, während DHCPv6 eine größere 16-Bit-Optionstyp-Codelänge hat
• Oft gibt es funktional gleichwertige Optionen, aber die Optionsnummern und -namen sind unterschiedlich
• Die IANA führt eine vollständige Liste aller DHCP-Optionen und DHCPv6-Optionen

Zusammenfassung

DHCP und DHCPv6 sind hinsichtlich der von ihnen bereitgestellten Basisdienste (d. h. dynamische Hostadressierung) funktional gleichwertig

• Die Integration von DHCP und DHCPv6 in eine einheitliche „DDI“-Lösung kann die betriebliche Effizienz steigern und die Netzwerkverwaltung vereinfachen
• Beide Protokolle weisen jedoch ihre eigenen Nuancen und Besonderheiten auf, deren Verständnis von Vorteil ist
• Und obwohl DHCP und DHCPv6 Unterschiede aufweisen, können sie beide nebeneinander existieren
• Das Beste daran ist, dass Hosts, Netzwerke und Server beide gleichzeitig verwenden können

---

Dokumentation

Man-Page

Links

Weblinks

1. https://blogs.infoblox.com/ipv6-coe/dhcp-and-dhcpv6-commonalities-and-differences/