Zum Inhalt springen

DHCPv6/DHCPv4: Unterschied zwischen den Versionen

Aus Foxwiki
Versionsgeschichte interaktiv durchsuchen
Zum nächsten Versionsunterschied →
Dirkwagner (Diskussion | Beiträge)
Bürokraten, Oberflächenadministratoren, Administratoren
144.695 Bearbeitungen
VisuellWikitext
Die Seite wurde neu angelegt: „Just like IPv4 and IPv6 have their similarities and differences, there are commonalities and differences between DHCP and DHCPv6. On IPv4 networks, nodes can either have their IP addresses statically configured or they can be dynamically configured with DHCP. '''IPv6''' offers several methods of assigning IPv6 addresses to end nodes. Of course, nodes can have their IPv6 address statically configured, but there are also two dynamic address configuration…“
 
Keine Bearbeitungszusammenfassung
Zeile 1: Zeile 1:
Just like IPv4 and IPv6 have their similarities and differences, there are commonalities and differences between DHCP and DHCPv6. On IPv4 networks, nodes can either have their IP addresses statically configured or they can be dynamically configured with DHCP. '''IPv6''' offers several methods of assigning IPv6 addresses to end nodes. Of course, nodes can have their IPv6 address statically configured, but there are also two dynamic address configuration methods: StateLess Address AutoConfiguration (SLAAC) and stateful DHCPv6. When to chose SLAAC or DHCPv6 was covered in a very early set of Infoblox IPv6 COE blogs: Part 1, Part 2, Part 3, and Part 4. This article will compare DHCP and DHCPv6.
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. 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.


=== Commonalities ===
=== Gemeinsamkeiten ===
Both protocols are standards published by the Internet Engineering Task Force (IETF) within the Dynamic Host Configuration Working Group (DHC WG). DHCP was originally defined in RFC 1531 in 1993 (over 30 years ago) and then refined in RFC 2131 in 1997. DHCPv6 was first defined in RFC 3315 in 2003 (a decade after DHCP’s first RFC was published) and the current version is defined in RFC 8415.
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 and DHCPv6 have many fundamental characteristics in common. Both protocols perform the function of dynamically assigning an IP address to an end host. They both have the concept of a scope or range and a lease of an individual address to an end node. Both protocols share the functional components of a DHCP/DHCPv6 client end node, a DHCP/DHCPv6 relay intermediary, and a DHCP/DHCPv6 server. The same clients, relays, and servers can use DHCP and DHCPv6 simultaneously in a dual-protocol scenario.
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.


It is often recommended that organizations follow the same operational model for IPv4 and IPv6. It makes sense that if an organization uses DHCP today in their IPv4 networks that they would select DHCPv6 for their IPv6 networks. For enterprises, it may prove administratively burdensome to use DHCP for IPv4 and SLAAC with Recursive DNS Server (RDNSS) and DNS Search List (DNSSL) (RFC 8106) for IPv6. If that is the case, it may be best to keep things simple and deploy DHCPv6 alongside DHCP. However, there may still be devices, like those running the Android OS or ChromeOS that don’t support DHCPv6.
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.


=== Different UDP Port Numbers ===
=== Unterschiedliche UDP-Portnummern ===
DHCP and DHCPv6 both use a connectionless service model using User Datagram Protocol (UDP) messages on the access segment. IPv4 DHCP servers (or relays) listen on UDP port 67, and the client listens on UDP port 68 (the same ports as BOOTP). For IPv6, DHCPv6 clients listen on UDP port 546 and the DHCPv6 servers and relay agents listen on UDP port 547. These port numbers are well-known registered port numbers documented by the Internet Assigned Number Authority (IANA) in the “Service Name and Transport Protocol Port Number Registry”.
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 ===
=== DORA versus SARR ===
DHCP and DHCPv6 are functionally equivalent in how a client statefully sends messages, often through a relay, and onward to the server. However, the message types and names are different. IPv4 DHCP clients start by sending a DHCPDISCOVER message to the IPv4 broadcast address (e.g., 255.255.255.255) and the server will respond with a DHCPOFFER message. The client then sends a DHCPREQUEST message, and finally the server completes the transaction by sending an DHCPACK acknowledgement message. This is shortened to Discover, Offer, Request, Acknowledge, or “DORA”). With DHCPv6, the four messages that go between the client and the server are SOLICIT, ADVERTISE, REQUEST, REPLY (or “SARR”). The following is a table that lists the functionally equivalent DHCP and DHCPv6 message types and names.
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.
{| class="wikitable"
{| class="wikitable"
|'''DHCP Message Types'''
|‚‘'DHCP-Nachrichtentypen'‚‘
|'''DHCPv6 Message Types'''
|‚‘'DHCPv6-Nachrichtentypen'‚‘
|-
|-
|DHCPDISCOVER
|DHCPDISCOVER
Zeile 38: Zeile 38:
|DECLINE
|DECLINE
|}
|}
This table lists the more common messages, but there are many other DHCP and DHCPv6 message types that we don’t discuss.
Diese Tabelle listet die gängigsten Nachrichten auf, es gibt jedoch noch viele weitere DHCP- und DHCPv6-Nachrichtentypen, auf die wir hier nicht eingehen.


=== Efficient Use of Multicast Rather Than Broadcast ===
=== Effiziente Nutzung von Multicast anstelle von Broadcast ===
One key difference between IPv4 and IPv6 is in how they use broadcast messages and/or multicast messages. IPv4 networks could use subnet broadcast messages sent to all local nodes using 255.255.255.255, or IPv4 could use multicast (224.0.0.0/4) destination addresses. IPv6 does not have any mechanism or addresses type that function as a broadcast. Instead, IPv6 uses multicast (ff00::/8) addresses for all one-to-many communications.
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.


This difference carries over to how DHCP and DHCPv6 function on a client access network. DHCP clients send their DHCPDISCOVER and DHCPREQUEST messages as a broadcast to 255.255.255.255. All other nodes on the local segment receive this message and are forced to process it and determine if they need to act upon that message. The DHCP relay will receive this unsolicited broadcast and forward it on to the DHCP server. For example, a Cisco router’s IPv4 access-network interface will be configured with an “ip helper” command with the unicast IPv4 address of the DHCP server.
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.


With DHCPv6, clients send their initial SOLICIT message to the All_DHCP_Relay_Agents_and_Servers link-local scope multicast address of ff02::1:2. The on-link DHCPv6 relay (or DHCPv6 server) is tuned into this multicast address and will receive and process these messages. The DHCPv6 relay could also use the All_DHCP_Servers site-local scope multicast address of ff05::1:3 to send messages to all DHCPv6 servers in the environment. Similarly, on a Cisco router’s IPv6 access network interface, it will use the “ipv6 dhcp relay destination” command with the global unicast address of the DHCPv6 server.
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.


=== Client Source Address Differences ===
=== Unterschiede bei den Client-Quelladressen ===
End hosts using DHCP and/or DHCPv6 both start out in a “chicken or the egg” dilemma whereby they need to send a packet to initiate the process of obtaining a unicast address, but also need a source address to use for their initial DHCP or DHCPv6 communications. IPv4 DHCP clients use 0.0.0.0 as their initial source address to send their DHCPDISCOVER and DHCPREQUEST messages. DHCPv6 clients use their link-local IPv6 address (on the fe80::/10 network) when sending their SOLICIT and REQUEST messages for communicating with the relay or server. DHCP relies on broadcasts to send messages to the relay or server and the relay or server uses unicast addresses to send back the responses. With DHCP, the client receives their address in the DHCPOFFER message destination address. DHCPv6 clients and relay/servers use their link-local addresses as their source address, and the relay/server is tuned into link-local multicasts to receive messages from clients. DHCPv6 clients don’t receive their global unicast address until the full four-way protocol exchange has finished.
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 Messages Initiate DHCPv6 ===
=== Router-Advertisement-Nachrichten initiieren DHCPv6 ===
One of the key differences between how IPv4 and IPv6 function on a LAN segment is IPv6’s use of ICMPv6 for router discovery. IPv6 routers send ICMPv6 type 134 Router Advertisement (RA) messages to the all-nodes link-local multicast address of ff02::1 to share information about the local network with all the nodes on the segment. These RAs sent by the first-hop router are a vital message that initiates the boot-up process for end nodes. In fact, it is the RA with the “Managed Address Configuration” flag set to “1” that triggers a client to begin the DHCPv6 stateful address assignment process. IPv4 doesn’t have any equivalent of the router discovery function. A DHCP client simply starts up and broadcasts the DHCPDISCOVER message to start the process.
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 ===
=== MACs versus DUIDs ===
DHCP uses the link-layer MAC address as the identifier for the client. The client’s MAC address is noted by the relay and the server, and associated with the address lease. DHCPv6 uses what is known as a DHCP Unique Identifier (DUID) for the client identifier. There are four DUID types defined in DHCPv6 (RFC 8415) and the choice of the DUID format is left to the client.
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.


# Link-layer address plus time (DUID-LLT) – used by Windows 10/11 clients and Apple MacOS
# Link-Layer-Adresse plus Zeit (DUID-LLT) – wird von Windows 10/11-Clients und Apple MacOS verwendet
# Vendor-assigned unique ID based on Enterprise ID (DUID-EN) – used by some Linux distros
# Vom Hersteller zugewiesene eindeutige ID basierend auf der Enterprise ID (DUID-EN) – wird von einigen Linux-Distributionen verwendet
# Link-layer address (DUID-LL)
# Link-Layer-Adresse (DUID-LL)
# UUID-Based DUID (DUID-UUID) (RFC 6355) – used by some Linux distros
# UUID-basierte DUID (DUID-UUID) (RFC 6355) – wird von einigen Linux-Distributionen verwendet


This can cause an operational challenge for organizations because DHCP and DHCPv6 don’t simply both use the client’s MAC address. Tom Coffeen wrote a 2-part blog series (Part 1, Part 2) and Ed Horley also wrote a blog on the challenges of maintaining MAC addresses for DHCP and DUIDs for DHCPv6.
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 and DHCPv6 both allow for the creation of a static reservation. For IPv4, DHCP allows for creating a fixed address binding between an IP address based on the MAC address of the client. Leveraging '''IPAM DHCP''' ensures streamlined management of address allocations and lease tracking for both DHCP and DHCPv6 environments. For IPv6, DHCPv6 uses the DUID for the static reservation mapping to the IPv6 global address within the range.
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.


=== High Availability ===
=== Hohe Verfügbarkeit ===
For IPv4 networks that required a high availability set of DHCP servers in case one fails, leases could be preserved and new leases served by the surviving DHCP server(s). Initially the DHCP Failover Protocol was conceived and then later the “DHC Load Balancing Algorithm” (RFC 3074) was proposed.
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.


High availability has historically been a challenge for DHCPv6 servers because there wasn’t any equivalent redundancy method specified as a standard. The IETF documented these issues in “DHCPv6 Redundancy Deployment Considerations” (RFC 6853) and “DHCPv6 Failover Requirements” (RFC 7031). Now, with the DHCPv6 Failover Protocol (RFC 8156), DHCPv6 server redundancy is equivalent to DHCP server redundancy. In fact, Infoblox worked with Internet Systems Consortium (ISC) on other forms of DHCPv6 redundancy, which are now supported in the Kea DHCPv6 server.
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 Times for DHCP and DHCPv6 ===
=== Lease-Zeiten für DHCP und DHCPv6 ===
Because IPv4 address space is a scarce commodity, scopes are typically small and lease times are set aggressively low to preserve address space. In fact, DHCP networks can even be configured to have clients release their address before they leave a network. Alternatively, IPv6 subnets are large (typically a /64), without any danger of exhausting the pool. Therefore, clients can request a new address each time they join a network. The maximum number of nodes on an IPv4 subnet may be limited to a few hundred because of the potential for subnet broadcast storms. On the other hand, IPv6’s efficient use of multicast allows networks to have far more nodes on an IPv6-only segment.
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 times don’t have to be the same as the network’s IPv4 DHCP lease time. For both protocols, renewal occurs at half the lease time, but this can be adjusted and is implementation-specific. However, DHCPv6 lease times may be different than customary IPv4 DHCP lease times and you may want to have different lease times for DHCP and DHCPv6.
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 ranges are typically /64 prefixes and DHCPv6 servers have enough available addresses to randomly assign a new one each time a client requests a lease. On an Infoblox NIOS system you can configure DHCP Scope/Leases and DHCPv6 Lease Affinity. The DHCPv6 server will renew and reuse leases up to the interval but will reuse, renew and scavenge expired leases after that interval. The interval is configurable, from 7 (default in Infoblox) up to a maximum of 180 days.
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 and DHCPv6 Options ===
=== DHCP- und DHCPv6-Optionen ===
Another difference between DHCP and DHCPv6 is the way they handle options. Options allow for DHCP (RFC 2132) and DHCPv6 servers to share additional configuration information with clients. DHCPv6 Options are different from but functionally equivalent to DHCP for IPv4. Both DHCP and DHCPv6 protocols provide options to the end node to provide additional information, but DHCP uses a single octet option field while DHCPv6 has a larger 16-bit option type code length. Often, there are functionally equivalent options, but the option numbers and names are different. IANA maintains a full list of all the DHCP options and the DHCPv6 options.
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.


=== Summary ===
=== Zusammenfassung ===
DHCP and DHCPv6 are functionally equivalent with the basic service they provide (i.e., dynamic host addressing). Integrating DHCP and DHCPv6 into a unified '''DDI''' solution can enhance operational efficiency and simplify network management. But they each have their own nuances and unique characteristics and it is beneficial to understand these differences. And even though DHCP and DHCPv6 have their differences, they can both coexist. Best of all, hosts, networks, and servers can all use both at the same time.
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.

Version vom 19. Mai 2025, 21:21 Uhr

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. 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.

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.

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