Zum Inhalt springen

DHCPv6/DHCPv4: Unterschied zwischen den Versionen

Aus Foxwiki
Versionsgeschichte interaktiv durchsuchen
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…“
 
K Textersetzung - „ “ durch „ “
 
(145 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt)
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.
'''{{BASEPAGENAME}}''' - Gemeinsamkeiten und Unterschiede


=== Commonalities ===
== Beschreibung ==
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.
; DHCPv4 und DHCPv6 funktional gleichwertig
Integration von DHCPv4 und DHCPv6 in eine einheitliche Lösung, kann Effizienz steigern und die Netzwerkverwaltung vereinfachen


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


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.
; IPv4
In IPv4-Netzwerken können die IP-Adressen der Knoten entweder
* statisch konfiguriert oder
* dynamisch mit DHCPv4 zugewiesen werden


=== Different UDP Port Numbers ===
; IPv6
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”.
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
-->


=== DORA versus SARR ===
; Betriebsmodell
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.
Es wird empfohlen, dass Unternehmen für IPv4 und IPv6 dasselbe Betriebsmodell verwenden
{| class="wikitable"
* Wenn Unternehmen DHCPv4 verwenden, kann es sinnvoll sein, DHCPv6 zu wählen
|'''DHCP Message Types'''
* 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
|'''DHCPv6 Message Types'''
* 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
 
== 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.&nbsp;B.&nbsp;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
 
[[File:DHCPv6-statefulMode.png|mini|300px]]
; Die vier wichtigsten Nachrichten von DHCPv6 (SARR)
* '''S'''OLICIT
* '''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
|}
|}
This table lists the more common messages, but there are many other DHCP and DHCPv6 message types that we don’t discuss.


=== Efficient Use of Multicast Rather Than Broadcast ===
Weitere Nachrichtentypen sind bei der [https://www.iana.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xhtml#dhcpv6-parameters-1 IANA] zu finden
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.
 
=== 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 <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
* 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


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.
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 DHCPv4 und DUIDs für DHCPv6 verfasst
-->


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


=== Client Source Address Differences ===
=== Hochverfügbarkeit ===
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.
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


=== Router Advertisement Messages Initiate DHCPv6 ===
Hochverfügbarkeit war für DHCPv6-Server bisher eine Herausforderung, da es lange keine standardisierte Redundanzmethode gab
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.
* 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


=== MACs Versus DUIDs ===
=== Lease-Zeiten ===
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.
; 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


# Link-layer address plus time (DUID-LLT) – used by Windows 10/11 clients and Apple MacOS
; DHCPv6-Lease-Zeiten
# Vendor-assigned unique ID based on Enterprise ID (DUID-EN) – used by some Linux distros
Müssen nicht mit den IPv4-DHCP-Lease-Zeiten des Netzwerks übereinstimmen
# Link-layer address (DUID-LL)
* Bei beiden Protokollen erfolgt die Erneuerung nach der Hälfte der Lease-Zeit, dies kann jedoch angepasst werden und ist implementierungsspezifisch
# UUID-Based DUID (DUID-UUID) (RFC 6355) – used by some Linux distros
* 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


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


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


=== High Availability ===
Die IANA führt die vollständige Liste aller DHCPv4-Optionen und DHCPv6-Optionen (s.&nbsp;u)
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.


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.
== Anhang ==
=== Siehe auch ===
<div style="column-count:2">
<categorytree hideroot=on mode="pages">DHCPv6</categorytree>
</div>
----
{{Special:PrefixIndex/DHCPv6/}}


=== Lease Times for DHCP and DHCPv6 ===
=== Dokumentation ===
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.


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.
=== Links ===
==== Projekt ====


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


=== DHCP and DHCPv6 Options ===
[[Kategorie:DHCPv6]]
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.


=== Summary ===
</noinclude>
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.

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“