Zum Inhalt springen

DHCPv6/DHCPv4: Unterschied zwischen den Versionen

Aus Foxwiki
Versionsgeschichte interaktiv durchsuchen
← Zum vorherigen Versionsunterschied
Dirkwagner (Diskussion | Beiträge)
Bürokraten, Oberflächenadministratoren, Administratoren
144.700 Bearbeitungen
VisuellWikitext
Keine Bearbeitungszusammenfassung
K Textersetzung - „ “ durch „ “
 
(142 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt)
Zeile 1: Zeile 1:
'''{{BASEPAGENAME}}''' - Beschreibung
'''{{BASEPAGENAME}}''' - Gemeinsamkeiten und Unterschiede


== Beschreibung ==
== Beschreibung ==
Genauso wie IPv4 und IPv6 ihre Gemeinsamkeiten und Unterschiede haben, gibt es auch Gemeinsamkeiten und Unterschiede zwischen DHCP und DHCPv6
; DHCPv4 und DHCPv6 funktional gleichwertig
* 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
Integration von DHCPv4 und DHCPv6 in eine einheitliche Lösung, kann Effizienz steigern und die Netzwerkverwaltung vereinfachen
* Natürlich können Knoten ihre IPv6-Adresse statisch konfigurieren, aber es gibt auch zwei dynamische Adresskonfigurationsmethoden: StateLess Address AutoConfiguration (SLAAC) und Stateful DHCPv6
 
; Nuancen und Besonderheiten
Beide Protokolle weisen ihre eigenen Nuancen und Besonderheiten auf, deren Verständnis von Vorteil ist
* DHCPv4 und DHCPv6, können sie beide nebeneinander existieren
* Hosts, Netzwerke und Server können beide gleichzeitig verwenden können
 
; IPv4
In IPv4-Netzwerken können die IP-Adressen der Knoten entweder  
* statisch konfiguriert oder  
* dynamisch mit DHCPv4 zugewiesen werden
 
; IPv6
IPv6 bietet mehrere Methoden zur Zuweisung von IPv6-Adressen an Endknoten
* statisch
* StateLess Address AutoConfiguration (SLAAC)
* Stateful DHCPv6
<!--
* Wann SLAAC oder DHCPv6 zu wählen ist, wurde in einer frühen Reihe von Infoblox IPv6 COE-Blogs behandelt: Teil 1, Teil 2, Teil 3 und Teil 4
* Wann SLAAC oder DHCPv6 zu wählen ist, wurde in einer frühen Reihe von Infoblox IPv6 COE-Blogs behandelt: Teil 1, Teil 2, Teil 3 und Teil 4
* In diesem Artikel werden DHCP und DHCPv6 verglichen
-->
 
; Betriebsmodell
Es wird empfohlen, dass Unternehmen für IPv4 und IPv6 dasselbe Betriebsmodell verwenden
* Wenn Unternehmen DHCPv4 verwenden, kann es sinnvoll sein, DHCPv6 zu wählen
* Es kann sich als aufwendig erweisen, DHCPv4 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 DHCPv4 einzusetzen
* Es kann jedoch Geräte geben, wie z.&nbsp;B.&nbsp;solche mit Android- oder ChromeOS-Betriebssystem, die DHCPv6 (noch) nicht unterstützen
 
== Gemeinsamkeiten ==
; Standards der Internet Engineering Task Force (IETF)
Innerhalb der Dynamic Host Configuration Working Group (DHC WG) veröffentlicht
* DHCPv4 wurde 1993 in [[RFC/1531]] definiert und 1997 in [[RFC/2131]] weiterentwickelt
* DHCPv6 wurde erstmals 2003 in [[RFC/3315]] definiert, die aktuelle Version ist in [[RFC/8415]] definiert
 
; Grundlegende Eigenschaften
Beide Protokolle erfüllen die Funktion
* Dynamischen Zuweisung einer IP-Adresse an einen Endgerät
* Verfügen über das Konzept eines Bereichs oder einer Reichweite
* Leasinggabe einer einzelnen Adresse an einen Endknoten
 
; Funktionalen Komponenten
* DHCP/DHCPv6-Client
* DHCP/DHCPv6-Relay
* DHCP/DHCPv6-Server
 
Dieselben Clients, Relays und Server können DHCPv4 und DHCPv6 gleichzeitig in einem Dual-Protokoll-Szenario verwenden


=== Gemeinsamkeiten ===
== Unterschiede ==
Beide Protokolle sind Standards, die von der Internet Engineering Task Force (IETF) innerhalb der Dynamic Host Configuration Working Group (DHC WG) veröffentlicht wurden
=== UDP-Portnummern ===
* DHCP wurde ursprünglich 1993 (vor über 30 Jahren) in RFC 1531 definiert und 1997 in RFC 2131 weiterentwickelt
DHCPv4 und DHCPv6 verwenden ein verbindungsloses Dienstmodell mit [[User Datagram Protocol]] (UDP)-Nachrichten
* 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
; DHCPv4
* Server/Relays lauschen auf UDP-Port 67
* Clients auf UDP-Port 68 (BOOTP)


DHCP und DHCPv6 haben viele grundlegende Eigenschaften gemeinsam
; DHCPv6
* Beide Protokolle erfüllen die Funktion der dynamischen Zuweisung einer IP-Adresse an einen Endhost
* Server/Relays lauschen auf UDP-Port 546
* Beide verfügen über das Konzept eines Bereichs oder einer Reichweite und einer Leasinggabe einer einzelnen Adresse an einen Endknoten
* Clients auf UDP-Port 547
* 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
; Registrierte Port-Nummern
* Wenn ein Unternehmen heute DHCP in seinen IPv4-Netzwerken verwendet, ist es sinnvoll, DHCPv6 für seine IPv6-Netzwerke zu wählen
Von der [[Internet Assigned Numbers Authority]] ([[IANA]]) dokumentiert
* 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
* „Service Name and Transport Protocol Port Number Registry“
* 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.&nbsp;B.&nbsp;solche mit Android- oder ChromeOS-Betriebssystem, die DHCPv6 nicht unterstützen


=== Unterschiedliche UDP-Portnummern ===
=== SARR statt DORA ===
DHCP und DHCPv6 verwenden beide ein verbindungsloses Dienstmodell mit User Datagram Protocol (UDP)-Nachrichten im Zugangssegment
DHCPv4 und DHCPv6 sind funktional gleichwertig, da ein Client zustandsbehaftet Nachrichten oft über einen Relay an den Server sendet
* 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)
* Nachrichtentypen und -namen sind unterschiedlich
* 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 ===
IPv4-DHCP-Clients senden zunächst eine DHCPDISCOVER-Nachricht an die IPv4-Broadcast-Adresse (z.&nbsp;B.&nbsp;255.255.255.255), woraufhin der Server mit einer DHCPOFFER-Nachricht antwortet
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
* 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
* 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
[[File:DHCPv6-statefulMode.png|mini|300px]]
{| class="wikitable"
; Die vier wichtigsten Nachrichten von DHCPv6 (SARR)
|‚‘'DHCP-Nachrichtentypen'‚‘
* '''S'''OLICIT
|‚‘'DHCPv6-Nachrichtentypen'‚‘
* '''A'''DVERTISE
* '''R'''EQUEST
* '''R'''EPLY
 
; Häufige Nachrichten
Funktional äquivalent mit DHCPv6
{| class="wikitable big"
! DHCPv4-Nachrichtentypen !! DHCPv6-Nachrichtentypen !! Beschreibung
|-
|-
|DHCPDISCOVER
| DHCPDISCOVER || SOLICIT || Entdeckung eines DHCP-Servers
|SOLICIT
|-
|-
|DHCPOFFER
| DHCPOFFER || ADVERTISE || Angebot
|ADVERTISE
|-
|-
|DHCPREQUEST
| DHCPREQUEST || REQUEST || Anftrage
|REQUEST
|-
|-
|DHCPACK
| DHCPACK || REPLY || Bestätigung
|REPLY
|-
|-
|DHCPRELEASE
| DHCPRELEASE || |RELEASE || Freigabe
|RELEASE
|-
|-
|DHCPINFORM
| DHCPINFORM || INFORMATION-REQUEST || Informationsanfrage
|INFORMATION-REQUEST
|-
|-
|DHCPDECLINE
| DHCPDECLINE || DECLINE || Ablehnung
|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
Weitere Nachrichtentypen sind bei der [https://www.iana.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xhtml#dhcpv6-parameters-1 IANA] zu finden


=== Effiziente Nutzung von Multicast anstelle von Broadcast ===
=== Multicast statt Broadcast ===
Ein wesentlicher Unterschied zwischen IPv4 und IPv6 besteht in der Verwendung von Broadcast- und/oder Multicast-Nachrichten
; Effiziente Nutzung von Multicast anstelle von Broadcast
Wesentlicher Unterschied zwischen IPv4 und IPv6
* 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
* 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
* 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
* 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
; DHCPv4
* DHCP-Clients senden ihre DHCPDISCOVER- und DHCPREQUEST-Nachrichten als Broadcast an 255.255.255.255
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
* 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
* 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
; DHCPv6
Clients senden ihre erste SOLICIT-Nachricht an die link-lokale Multicast-Adresse <nowiki>ff02::1:2</nowiki> 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
* 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
* 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 ===
=== 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
; Unterschiede bei den Client-Quelladressen
* IPv4-DHCP-Clients verwenden 0.0.0.0 als erste Quelladresse zum Senden ihrer DHCPDISCOVER- und DHCPREQUEST-Nachrichten
„Henne-Ei“-Dilemma
* 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
* Beschaffung einer Unicast-Adresse ohne eine Absenderadresse zu haben
* 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
DHCPv4
* Bei DHCP erhält der Client seine Adresse in der Zieladresse der DHCPOFFER-Nachricht
* verwendet 0.0.0.0 als erste Quelladresse zum Senden ihrer DHCPDISCOVER- und DHCPREQUEST-Nachrichten
* 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
* 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
* DHCPv6-Clients erhalten ihre globale Unicast-Adresse erst, wenn der vollständige Vier-Wege-Protokollwechsel abgeschlossen ist
* Client erhält seine Adresse in der Zieladresse der DHCPOFFER-Nachricht
 
DHCPv6
* 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
* 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
* Clients erhalten ihre globale Unicast-Adresse erst, wenn die Konfiguration abgeschlossen ist


=== Router-Advertisement-Nachrichten initiieren DHCPv6 ===
=== Router-Advertisement ===
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
; Router-Advertisement-Nachrichten initiieren DHCPv6
* 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
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
* Diese vom First-Hop-Router gesendeten RAs sind wichtige Nachrichten, die den Startvorgang für Endknoten initiieren
Managed Address Configuration
* 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
* 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
* IPv4 verfügt über keine Entsprechung zur Router-Erkennungsfunktion
Zeile 103: Zeile 147:


=== MACs versus DUIDs ===
=== MACs versus DUIDs ===
DHCP verwendet die MAC-Adresse der Verbindungsschicht als Kennung für den Client
; DHCPv4
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
* 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


# Link-Layer-Adresse plus Zeit (DUID-LLT) – wird von Windows 10/11-Clients und Apple MacOS verwendet
; DHCPv6
# Vom Hersteller zugewiesene eindeutige ID basierend auf der Enterprise ID (DUID-EN) – wird von einigen Linux-Distributionen verwendet
Verwendet für die Client-Kennung eine sogenannte DHCPv4 Unique Identifier (DUID)
# Link-Layer-Adresse (DUID-LL)
* In DHCPv6 ([[RFC/8415]]) sind vier DUID-Typen definiert, wobei die Wahl des DUID-Formats dem Client überlassen bleibt
# UUID-basierte DUID (DUID-UUID) (RFC 6355) – wird von einigen Linux-Distributionen verwendet
** Link-Layer-Adresse plus Zeit (DUID-LLT) – wird von Windows 10/11-Clients und Apple MacOS verwendet
** Vom Hersteller zugewiesene eindeutige ID basierend auf der Enterprise ID (DUID-EN) – wird von einigen Linux-Distributionen verwendet
** Link-Layer-Adresse (DUID-LL)
** 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
Dies kann für Unternehmen eine operative Herausforderung darstellen, da DHCPv4 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
<!--
* 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 DHCPv4 und DUIDs für DHCPv6 verfasst
-->


DHCP und DHCPv6 ermöglichen beide die Erstellung einer statischen Reservierung
; Statischen Reservierung
* Für IPv4 ermöglicht DHCP die Erstellung einer festen Adressbindung zwischen einer IP-Adresse basierend auf der MAC-Adresse des Clients
DHCPv4 und DHCPv6 ermöglichen beide die Erstellung einer statischen Reservierung
* 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 IPv4 ermöglicht DHCPv4 die Erstellung einer festen Adressbindung zwischen einer IP-Adresse basierend auf der MAC-Adresse des Clients
* Durch die Nutzung von [https://de.wikipedia.org/wiki/IP_Address_Management IP Address Management] wird eine optimierte Verwaltung der Adresszuweisungen und der Leasingverfolgung für DHCPv4- und DHCPv6-Umgebungen gewährleistet
* Für IPv6 verwendet DHCPv6 die DUID für die statische Reservierungszuordnung zur globalen IPv6-Adresse innerhalb des Bereichs
* Für IPv6 verwendet DHCPv6 die DUID für die statische Reservierungszuordnung zur globalen IPv6-Adresse innerhalb des Bereichs


=== Hohe Verfügbarkeit ===
=== Hochverfü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
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
* 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
Hochverfügbarkeit war für DHCPv6-Server bisher eine Herausforderung, da es lange keine standardisierte Redundanzmethode gab
* Die IETF hat diese Probleme in „DHCPv6 Redundancy Deployment Considerations“ (RFC 6853) und „DHCPv6 Failover Requirements“ (RFC 7031) dokumentiert
* 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
* Mit dem DHCPv6-Failover-Protokoll ([[RFC/8156]]) entspricht die Redundanz von DHCPv6-Servern nun der Redundanz von DHCPv4-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 ===
=== Lease-Zeiten ===
; DHCPv4-Lease-Zeiten
Da der IPv4-Adressraum knapp ist, sind die Bereiche in der Regel klein und die Lease-Zeiten sehr niedrig angesetzt, um Adressraum zu sparen
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
* Tatsächlich können DHCP-Netzwerke sogar so konfiguriert werden, dass Clients ihre Adressen freigeben, bevor sie ein Netzwerk verlassen
Zeile 138: Zeile 187:
* Andererseits ermöglicht die effiziente Nutzung von Multicast durch IPv6, dass Netzwerke weitaus mehr Knoten in einem reinen IPv6-Segment haben können
* 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
; 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
* 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
* Die DHCPv6-Lease-Zeiten können jedoch von den üblichen IPv4-DHCP-Lease-Zeiten abweichen, sodass Sie möglicherweise unterschiedliche Lease-Zeiten für DHCPv4 und DHCPv6 festlegen möchten


=== DHCPv6-Bereiche ===
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
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
* 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
<!--
* <s>Das Intervall ist konfigurierbar und reicht von 7 bis zu maximal 180 Tagen</s>
-->


=== DHCP- und DHCPv6-Optionen ===
=== Optionen ===
Ein weiterer Unterschied zwischen DHCP und DHCPv6 besteht in der Art und Weise, wie Optionen verarbeitet werden
Optionen ermöglichen es DHCP-Servern zusätzliche Konfigurationsinformationen an Clients zu senden
* Optionen ermöglichen es DHCP- (RFC 2132) und DHCPv6-Servern, zusätzliche Konfigurationsinformationen mit Clients auszutauschen
* DHCPv6-Optionen unterscheiden sich von DHCPv4 für IPv4, sind jedoch funktional gleichwertig
* DHCPv6-Optionen unterscheiden sich von DHCP für IPv4, sind jedoch funktional gleichwertig
** Optionsnummern und -namen sind unterschiedlich
* 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
** DHCPv4 verwendet ein einzelnes Oktett-Optionsfeld
* Oft gibt es funktional gleichwertige Optionen, aber die Optionsnummern und -namen sind unterschiedlich
** DHCPv6 eine größere 16-Bit-Optionstyp-Codelänge hat
* Die IANA führt eine vollständige Liste aller DHCP-Optionen und DHCPv6-Optionen


=== Zusammenfassung ===
Die IANA führt die vollständige Liste aller DHCPv4-Optionen und DHCPv6-Optionen (s.&nbsp;u)
DHCP und DHCPv6 sind hinsichtlich der von ihnen bereitgestellten Basisdienste (d.&nbsp;h.&nbsp;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


== Anhang ==
== Anhang ==
=== Siehe auch ===
=== Siehe auch ===
<div style="column-count:3">
<div style="column-count:2">
<categorytree hideroot=on mode="pages">{{BASEPAGENAME}}</categorytree>
<categorytree hideroot=on mode="pages">DHCPv6</categorytree>
</div>
</div>
----
----
{{Special:PrefixIndex/{{BASEPAGENAME}}/}}
{{Special:PrefixIndex/DHCPv6/}}
 
=== Dokumentation ===
=== Dokumentation ===
; Man-Page
<!--
# [https://manpages.debian.org/stable/procps/pgrep.1.de.html prep(1)]
; Info-Pages
-->


=== Links ===
=== Links ===
Zeile 182: Zeile 222:


==== Weblinks ====
==== Weblinks ====
# [https://www.iana.org/assignments/bootp-dhcp-parameters/bootp-dhcp-parameters.xhtml#message-type-53 DHCPv4 Message Types]
# [https://www.iana.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xhtml#dhcpv6-parameters-1 DHCPv6 Message Types]
# [https://www.iana.org/assignments/bootp-dhcp-parameters/bootp-dhcp-parameters.xhtml#options DHCPv4-Optionen]
# [https://www.iana.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xhtml#dhcpv6-parameters-2 DHCPv6-Optionen]
# https://de.wikipedia.org/wiki/Dynamic_Host_Configuration_Protocol
# https://www.networkacademy.io/ccna/ipv6/stateful-dhcpv6
# https://www.rapidseedbox.com/blog/guide-to-dhcpv6


[[Kategorie:IPv6/DHCP]]
[[Kategorie:DHCPv6]]


</noinclude>
</noinclude>

Aktuelle Version vom 14. Juni 2026, 00:46 Uhr

DHCPv6/DHCPv4 - Gemeinsamkeiten und Unterschiede

Beschreibung

DHCPv4 und DHCPv6 funktional gleichwertig

Integration von DHCPv4 und DHCPv6 in eine einheitliche Lösung, kann Effizienz steigern und die Netzwerkverwaltung vereinfachen

Nuancen und Besonderheiten

Beide Protokolle weisen ihre eigenen Nuancen und Besonderheiten auf, deren Verständnis von Vorteil ist

  • DHCPv4 und DHCPv6, können sie beide nebeneinander existieren
  • Hosts, Netzwerke und Server können beide gleichzeitig verwenden können
IPv4

In IPv4-Netzwerken können die IP-Adressen der Knoten entweder

  • statisch konfiguriert oder
  • dynamisch mit DHCPv4 zugewiesen werden
IPv6

IPv6 bietet mehrere Methoden zur Zuweisung von IPv6-Adressen an Endknoten

  • statisch
  • StateLess Address AutoConfiguration (SLAAC)
  • Stateful DHCPv6
Betriebsmodell

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

  • Wenn Unternehmen DHCPv4 verwenden, kann es sinnvoll sein, DHCPv6 zu wählen
  • Es kann sich als aufwendig erweisen, DHCPv4 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 DHCPv4 einzusetzen
  • Es kann jedoch Geräte geben, wie z. B. solche mit Android- oder ChromeOS-Betriebssystem, die DHCPv6 (noch) nicht unterstützen

Gemeinsamkeiten

Standards der Internet Engineering Task Force (IETF)

Innerhalb der Dynamic Host Configuration Working Group (DHC WG) veröffentlicht

  • DHCPv4 wurde 1993 in RFC/1531 definiert und 1997 in RFC/2131 weiterentwickelt
  • DHCPv6 wurde erstmals 2003 in RFC/3315 definiert, die aktuelle Version ist in RFC/8415 definiert
Grundlegende Eigenschaften

Beide Protokolle erfüllen die Funktion

  • Dynamischen Zuweisung einer IP-Adresse an einen Endgerät
  • Verfügen über das Konzept eines Bereichs oder einer Reichweite
  • Leasinggabe einer einzelnen Adresse an einen Endknoten
Funktionalen Komponenten
  • DHCP/DHCPv6-Client
  • DHCP/DHCPv6-Relay
  • DHCP/DHCPv6-Server

Dieselben Clients, Relays und Server können DHCPv4 und DHCPv6 gleichzeitig in einem Dual-Protokoll-Szenario verwenden

Unterschiede

UDP-Portnummern

DHCPv4 und DHCPv6 verwenden ein verbindungsloses Dienstmodell mit User Datagram Protocol (UDP)-Nachrichten

DHCPv4
  • Server/Relays lauschen auf UDP-Port 67
  • Clients auf UDP-Port 68 (BOOTP)
DHCPv6
  • Server/Relays lauschen auf UDP-Port 546
  • Clients auf UDP-Port 547
Registrierte Port-Nummern

Von der Internet Assigned Numbers Authority (IANA) dokumentiert

  • „Service Name and Transport Protocol Port Number Registry“

SARR statt DORA

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

  • Nachrichtentypen und -namen sind unterschiedlich

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
Die vier wichtigsten Nachrichten von DHCPv6 (SARR)
  • SOLICIT
  • ADVERTISE
  • REQUEST
  • REPLY
Häufige Nachrichten

Funktional äquivalent mit DHCPv6

DHCPv4-Nachrichtentypen DHCPv6-Nachrichtentypen Beschreibung
DHCPDISCOVER SOLICIT Entdeckung eines DHCP-Servers
DHCPOFFER ADVERTISE Angebot
DHCPREQUEST REQUEST Anftrage
DHCPACK REPLY Bestätigung
DHCPRELEASE RELEASE Freigabe
DHCPINFORM INFORMATION-REQUEST Informationsanfrage
DHCPDECLINE DECLINE Ablehnung

Weitere Nachrichtentypen sind bei der IANA zu finden

Multicast statt Broadcast

Effiziente Nutzung von Multicast anstelle von Broadcast

Wesentlicher Unterschied zwischen IPv4 und IPv6

  • 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
DHCPv4

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
DHCPv6

Clients senden 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

Client-Quelladressen

Unterschiede bei den Client-Quelladressen

„Henne-Ei“-Dilemma

  • Beschaffung einer Unicast-Adresse ohne eine Absenderadresse zu haben

DHCPv4

  • verwendet 0.0.0.0 als erste Quelladresse zum Senden ihrer DHCPDISCOVER- und DHCPREQUEST-Nachrichten
  • 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
  • Client erhält seine Adresse in der Zieladresse der DHCPOFFER-Nachricht

DHCPv6

  • 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
  • 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
  • Clients erhalten ihre globale Unicast-Adresse erst, wenn die Konfiguration abgeschlossen ist

Router-Advertisement

Router-Advertisement-Nachrichten initiieren DHCPv6

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

Managed Address Configuration

  • 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

DHCPv4

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 DHCPv4 Unique Identifier (DUID)

  • In DHCPv6 (RFC/8415) sind vier DUID-Typen definiert, wobei die Wahl des DUID-Formats dem Client überlassen bleibt
    • Link-Layer-Adresse plus Zeit (DUID-LLT) – wird von Windows 10/11-Clients und Apple MacOS verwendet
    • Vom Hersteller zugewiesene eindeutige ID basierend auf der Enterprise ID (DUID-EN) – wird von einigen Linux-Distributionen verwendet
    • Link-Layer-Adresse (DUID-LL)
    • UUID-basierte DUID (DUID-UUID) RFC/6355 – wird von einigen Linux-Distributionen verwendet

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

Statischen Reservierung

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

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

Hochverfü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 lange 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 DHCPv4-Servern

Lease-Zeiten

DHCPv4-Lease-Zeiten

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
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 DHCPv4 und DHCPv6 festlegen möchten

DHCPv6-Bereiche

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

  • Der DHCPv6-Server erneuert und wiederverwendet Leases bis zum Intervall, wiederverwendet, erneuert und bereinigt jedoch nach diesem Intervall abgelaufene Leases

Optionen

Optionen ermöglichen es DHCP-Servern zusätzliche Konfigurationsinformationen an Clients zu senden

  • DHCPv6-Optionen unterscheiden sich von DHCPv4 für IPv4, sind jedoch funktional gleichwertig
    • Optionsnummern und -namen sind unterschiedlich
    • DHCPv4 verwendet ein einzelnes Oktett-Optionsfeld
    • DHCPv6 eine größere 16-Bit-Optionstyp-Codelänge hat

Die IANA führt die vollständige Liste aller DHCPv4-Optionen und DHCPv6-Optionen (s. u)

Anhang

Siehe auch

Dokumentation

Projekt

  1. DHCPv4 Message Types
  2. DHCPv6 Message Types
  3. DHCPv4-Optionen
  4. DHCPv6-Optionen
  5. https://de.wikipedia.org/wiki/Dynamic_Host_Configuration_Protocol
  6. https://www.networkacademy.io/ccna/ipv6/stateful-dhcpv6
  7. https://www.rapidseedbox.com/blog/guide-to-dhcpv6


Abgerufen von „https://wiki.foxtom.de/index.php?title=DHCPv6/DHCPv4&oldid=166042“