imported>Horst Gräbner: Änderungen von ~2025-26409-65 (Diskussion) auf die letzte Version von Horst Gräbner zurückgesetzt

2025-09-25T09:12:13Z

Änderungen von ~2025-26409-65 (Diskussion) auf die letzte Version von Horst Gräbner zurückgesetzt

Neue Seite

{| class="wikitable float-right"
|-
! colspan="2" class="hintergrundfarbe6"| DHCP (Dynamic Host Configuration Protocol)
|-
| style="text-align:left"| '''Familie:'''
| style="text-align:left"| [[Internetprotokollfamilie]]
|-
| style="text-align:left"| '''Einsatzgebiet:'''
| style="text-align:left"| Automatischer Bezug von<br />[[IP-Adresse]]n und weiteren<br />Parametern
|-
| style="text-align:right"| '''Ports:'''
| style="text-align:left"| 67/UDP (IPv4 Server oder Relay-Agent)<br />68/UDP (IPv4 Client)
547/UDP (IPv6 Server oder Relay-Agent)<br />546/UDP (IPv6 Client)
|-
| style="text-align:center" colspan="2" |
{{Netzwerk-UDP-IP-Anwendungsprotokoll|DHCP|}}
|-
| style="text-align:left"| '''Standards:'''
| style="text-align:left"| <nowiki>RFC 2131</nowiki> (1997)
|}

Das '''Dynamic Host Configuration Protocol''' ('''DHCP''') ist ein [[Kommunikationsprotokoll]] in der [[Computertechnik]]. Es ermöglicht die Zuweisung der Netzwerkkonfiguration an [[Client]]s durch einen [[Server (Software)|Server]].

DHCP wurde im <nowiki>RFC 2131</nowiki> definiert und bekam von der [[Internet Assigned Numbers Authority]] die [[User Datagram Protocol|UDP]]-[[Port (Netzwerkadresse)|Ports]] 67 und 68 zugewiesen.

== Konzept ==
DHCP ermöglicht es, angeschlossene Clients ohne manuelle Konfiguration der Netzschnittstelle in ein bestehendes [[Rechnernetz|Netz]] einzubinden. Nötige Informationen wie [[IP-Adresse]], [[Netzmaske]], [[Gateway (Informatik)|Gateway]], [[Domain Name System|Name Server (DNS)]] und ggf. weitere Einstellungen werden automatisch vergeben, sofern das [[Betriebssystem]] des jeweiligen Clients dies unterstützt.

DHCP ist eine Erweiterung des [[Bootstrap Protocol|Bootstrap-Protokolls]] (BOOTP), das für Arbeitsplatz-Computer ohne eigene Festplatte ([[Diskless-Workstation]]) notwendig war, wo sich der Computer beim Startvorgang zunächst vom BOOTP-Server eine IP-Adresse zuweisen ließ, um danach das Betriebssystem aus dem Netz zu laden. DHCP ist weitgehend kompatibel zu BOOTP und kann entsprechend mit BOOTP-Clients und -Servern (eingeschränkt) zusammenarbeiten.

DHCP wurde erstmals 1993 in <nowiki>RFC 1531</nowiki> und <nowiki>RFC 1541</nowiki> definiert, aufbauend auf dem 1985 entstandenen BOOTP (<nowiki>RFC 951</nowiki>).

== Aufbau eines DHCP-Paketes ==
{| class="wikitable float-right" style="text-align:center"
! colspan="4"| 32 Bit
|-
| op
| htype
| hlen
| hops
|-
| colspan="4" |xid
|-
| colspan="2" | secs
| colspan="2" | flags
|-
| colspan="4" | ciaddr
|-
| colspan="4" | yiaddr
|-
| colspan="4" | siaddr
|-
| colspan="4" | giaddr
|-
| colspan="4" | chaddr
|-
| colspan="4" | sname
|-
| colspan="4" | file
|-
| colspan="4" | options
|}

* op (1 Byte): Information, ob es sich um eine Anforderung (request = 1) oder eine Antwort (reply = 2) handelt
* htype (1 Byte): Netztyp (z. B. 1 = Ethernet, 6 = IEEE 802 Netzwerke oder 7 = [[ARCNET]])
* hlen (1 Byte): Länge der physikalischen Netzadresse in Bytes (z. B. 6 = MAC/Ethernet-Adresse)
* hops (1 Byte, optional): Anzahl der DHCP-Relay-Agents auf dem Datenpfad
* xid (4 Byte): ID der Verbindung zwischen Client und Server
* secs (2 Byte): Zeit in Sekunden seit dem Start des Clients
* flags (2 Byte): Z. Zt. wird nur das erste Bit verwendet (zeigt an, ob der Client noch eine gültige IP-Adresse hat), die restlichen Bits sind für spätere Protokollerweiterungen reserviert
* ciaddr (4 Byte): Client-IP-Adresse
* yiaddr (4 Byte): eigene IP-Adresse
* siaddr (4 Byte): Server-IP-Adresse
* giaddr (4 Byte): Relay-Agent-IP-Adresse
* chaddr (16 Byte): Client-MAC-Adresse
* sname (64 Byte): Name des DHCP-Servers, falls ein bestimmter gefordert wird [[Zeichenkette#C|(enthält C-String)]], Angabe optional
* file (128 Byte): Name einer Datei (z. B. System-Kernel), die vom Server per [[Trivial File Transfer Protocol|TFTP]] an den Client gesendet werden soll [[Zeichenkette#C|(enthält C-String)]], Angabe optional
* options (variabel, optional): DHCP-Parameter und -Optionen (Beschreibung in <nowiki>RFC 2132</nowiki>) – Die Optionen können bis zu 312 Bytes lang sein, so dass ein IP-Paket von bis zu 576 Bytes (236 Bytes DHCP-Header + 312 Bytes DHCP-Options + 8 Bytes UDP-Header + 20 Bytes IPv4-Header) Länge auftreten kann. Eine größere maximale Byteanzahl kann zwischen Server und Client ausgehandelt werden.<ref>{{RFC-Internet |Autor=R. Droms |RFC=2131 |Titel=Dynamic Host Configuration Protocol |Seite=10 |Datum=1997-03 |Obsoletes=1541}}</ref>

== Der DHCP-Server ==
Der DHCP-Server wird – wie alle [[Netzwerkdienst]]e – als Hintergrundprozess ([[Netzwerkdienst|Dienst]] oder [[Daemon]]) gestartet und wartet auf [[User Datagram Protocol|UDP]]-Port 67 auf Client-Anfragen. In seiner Konfigurationsdatei befinden sich Informationen über den zu vergebenden Adresspool sowie zusätzliche Angaben über netzwerkrelevante Parameter wie die [[Subnetzmaske]], die lokale [[Domain (Internet)|DNS-Domain]] oder das zu verwendende Gateway. Außerdem lassen sich auch weitere BOOTP-Server oder der Ort des zu verwendenden Bootimages einstellen.

Es gibt drei verschiedene Betriebsmodi eines DHCP-Servers: statische, automatische und dynamische Zuordnung.

=== Statische Zuordnung ===
In diesem Modus (''statisches DHCP'') werden am DHCP-Server die IP-Adressen bestimmten [[MAC-Adresse]]n fest zugeordnet. Die Adressen werden der MAC-Adresse auf unbestimmte Zeit zugeteilt. Der Nachteil kann darin liegen, dass sich keine zusätzlichen Clients in das Netz einbinden können, da die Adressen fest vergeben sind. Das kann unter Sicherheitsaspekten erwünscht sein.

Statische Zuordnungen werden vor allem dann vorgenommen, wenn der DHCP-Client beispielsweise Server-Dienste zur Verfügung stellt und daher unter einer festen IP-Adresse erreichbar sein soll. Auch Port-Weiterleitungen von einem Router an einen Client benötigen in der Regel eine feste IP-Adresse.

=== Automatische Zuordnung ===
Bei der automatischen Zuordnung wird am DHCP-Server ein Bereich von IP-Adressen (''range'') definiert. IP-Adressen werden automatisch an die MAC-Adressen von neuen DHCP-Clients zugewiesen, was in einer Tabelle festgehalten wird. Im Unterschied zur dynamischen Zuordnung sind automatische Zuordnungen permanent und werden nicht entfernt. Der Vorteil ist, dass Hosts immer dieselbe IP-Adresse erhalten und eine zugewiesene IP-Adresse keinem anderen Host zugewiesen wird. Der Nachteil ist, dass neue Clients keine IP-Adresse erhalten, wenn der gesamte Adressbereich vergeben ist, auch wenn IP-Adressen nicht mehr aktiv genutzt werden.

=== Dynamische Zuordnung ===
Dieses Verfahren gleicht der automatischen Zuordnung, allerdings hat der DHCP-Server hier in seiner Konfigurationsdatei eine Angabe, wie lange eine bestimmte [[IP-Adresse]] an einen Client „verliehen“ werden darf, bevor der Client sich erneut beim Server melden und eine „Verlängerung“ beantragen muss. Meldet er sich nicht, wird die Adresse frei und kann an einen anderen (oder auch denselben) Rechner neu vergeben werden. Diese vom Administrator bestimmte Zeit heißt '''Lease'''-Time (zu Deutsch also: „Leihdauer“).

Manche DHCP-Server vergeben auch von der MAC-Adresse abhängige IP-Adressen, d. h. ein Client bekommt hier selbst nach längerer Netzwerkabstinenz und Ablauf der Lease-Zeit die gleiche IP-Adresse wie zuvor (es sei denn natürlich, diese ist inzwischen schon anderweitig vergeben).

== DHCP-Nachrichten ==
* DHCP'''DISCOVER''': Ein Client ohne IP-Adresse sendet eine [[Broadcast|Broadcast-Anfrage]] nach Adress-Angeboten an alle DHCP-Server im lokalen Netz.
* DHCP'''OFFER''': Die DHCP-Server antworten mit entsprechenden Werten auf eine DHCP'''DISCOVER'''-Anfrage.
* DHCP'''REQUEST''': Der Client fordert eine der angebotenen IP-Adressen, weitere Daten sowie Verlängerung der Lease-Zeit von einem der antwortenden DHCP-Server.
* DHCP'''ACK''': Bestätigung des DHCP-Servers zu einer DHCP'''REQUEST'''-Anforderung oder die Übermittlung von Konfigurationsparametern, die vorher durch DHCP'''INFORM''' vom Client angefordert wurden.
* DHCP'''NAK''': Ablehnung einer DHCP'''REQUEST'''-Anforderung durch den DHCP-Server.
* DHCP'''DECLINE''': Ablehnung durch den Client, da die IP-Adresse schon verwendet wird.
* DHCP'''RELEASE''': Der Client gibt die eigene Konfiguration frei, damit die Parameter wieder für andere Clients zur Verfügung stehen.
* DHCP'''INFORM''': Anfrage eines Clients nach weiteren Konfigurationsparametern, z. B. weil der Client eine statische IP-Adresse besitzt.

== DHCP-Relay ==
DHCP-Relay ist eine Funktion, um DHCP über Netzgrenzen (Broadcastdomäne) hinaus nutzen zu können. Damit wird die Notwendigkeit der Bereitstellung eines DHCP-Servers in jedem Subnetz, in dem sich DHCP-Clients befinden, vermieden. Die DHCP-Relay-Funktion wird meist durch den Router selbst erbracht.
Dabei werden Client-seitig mittels Broadcast verschickte DHCP-Anfragen durch den DHCP-Relay empfangen und mittels Unicast einem oder mehreren DHCP-Servern zugestellt. Der DHCP-Relay-Agent wird funktional auf der Schnittstelle des Routers platziert.

== DHCP und Active Directory ==
Bei einem [[Active Directory]] ist der DHCP-Dienst in die AD-Datenbank integriert.
Dabei dürfen nur autorisierte Server Leases verteilen. Um einen Server zu autorisieren, muss dieser ein DC sein oder ein Domänenkonto besitzen.

== Ablauf der DHCP-Kommunikation ==
[[Datei:16a DHCP.png|mini|Ablauf der Zuweisung einer IP-Adresse per DHCP]]
Damit der Client einen DHCP-Server nutzen kann, muss sich dieser im selben Netzwerksegment befinden, da DHCP [[Broadcast]]s verwendet und [[Router]] keine Broadcasts weiterleiten (Router bilden [[Broadcast-Domäne]]n). Befindet sich der DHCP-Server in einem anderen [[Netzwerksegment]], so muss ein so genannter DHCP-Relay-Agent installiert werden, der die DHCP-Anfragen an den eigentlichen Server weitergibt.

=== Initiale Adresszuweisung (Lease/Vergabe) ===
Wenn ein Client erstmals eine IP-Adresse benötigt, schickt er eine ''DHCPDISCOVER''-Nachricht (mit seiner MAC-Adresse) als Netzwerk-Broadcast an die verfügbaren DHCP-Server (es kann durchaus mehrere davon im selben Subnetz geben). Dieser Broadcast hat als Absender-IP-Adresse [[0.0.0.0]] und als Zieladresse 255.255.255.255, da der Absender noch keine IP-Adresse besitzt und seine Anfrage „an alle“ richtet. Dabei ist der UDP-Quellport 68 und der UDP-Zielport 67. Die DHCP-Server antworten mit ''DHCPOFFER'' und machen Vorschläge für eine IP-Adresse. Das geschieht entweder mit einem Broadcast an die Adresse 255.255.255.255 mit UDP-Quellport 67 und UDP-Zielport 68 oder mit einem Unicast an die vorgeschlagene IP-Adresse und die MAC-Adresse des Clients, je nachdem ob der Client in der ''DHCPDISCOVER''-Nachricht das Broadcast-Bit gesetzt hat.<ref>{{RFC-Internet |Autor=R. Droms |RFC=2131 |Titel=Dynamic Host Configuration Protocol |Abschnitt=4.1 |Abschnittstitel=Constructing and sending DHCP messages |Datum=1997-03 |Obsoletes=1541}}</ref>

Der Client darf nun unter den eingetroffenen Angeboten (''DHCPOFFER'') wählen. Wenn er sich für eines entschieden hat (z. B. wegen längster Lease-Zeit oder wegen Ablehnung eines speziellen, evtl. falsch konfigurierten DHCP-Servers, oder einfach für die erste Antwort), kontaktiert er per Broadcast und einem im Paket enthaltenen Serveridentifier den entsprechenden Server mit der Nachricht ''DHCPREQUEST''. Alle eventuellen weiteren DHCP-Server werten das als Absage für ihre Angebote. Der vom Client ausgewählte Server bestätigt in einer ''DHCPACK''-Nachricht (DHCP-Acknowledged) die IP-Adresse mit den weiteren relevanten Daten, oder er zieht sein Angebot zurück (''DHCPNAK'', siehe auch Sonstiges).

Bevor der Client sein Netzwerkinterface mit der zugewiesenen Adresse konfiguriert, sollte er noch prüfen, ob nicht versehentlich noch ein anderer Rechner die Adresse verwendet. Das geschieht üblicherweise durch einen [[Address Resolution Protocol|ARP-Request]] mit der soeben zugeteilten IP-Adresse. Antwortet ein anderer Host im Netz auf diesen Request, so wird der Client die vorgeschlagene Adresse mit einer ''DHCPDECLINE''-Nachricht zurückweisen.

=== DHCP-Refresh (nur bei dynamischer Zuordnung) ===
Zusammen mit der IP-Adresse erhält der Client in der ''DHCPACK''-Nachricht neben der „lease time“, also der Gültigkeitsdauer der IP-Konfiguration, zwei Fristen: Die „renewal time“ T1 und die „rebinding time“ T2. Der Standard schlägt vor, dass T1 auf die Hälfte und T2 auf 7/8, also 87,5 % der Gültigkeitsdauer der ''lease time'' gesetzt wird. Für beide Werte kann der DHCP-Server optional andere Werte vorgeben.

Nach Ablauf der Zeit T1 versucht der Client, seine ''lease time'' zu verlängern. Dazu sendet der Client wieder ''DHCPREQUEST''s per [[Unicast]] an den Server, der die IP-Konfiguration vergeben hat. Der Server sollte dann in der Regel ein ''DHCPACK'' mit identischen Daten wie vorher, aber einer neuen ''lease time'' senden. Damit gilt die Gültigkeitsdauer der IP-Konfiguration des Clients als verlängert.

Antwortet der Server nicht, weil er zum Beispiel abgeschaltet wurde und nun ein neuer Server für die Verwaltung der IP-Adressen zuständig ist, so kann der Client die IP-Konfiguration ohne Einschränkungen weiter verwenden, bis die ''lease time'' abgelaufen ist. Er wird jedoch nach Ablauf von T2 anfangen, ''DHCPREQUEST''s nunmehr per Broadcast zu versenden, um eine neue IP-Konfiguration von irgendeinem anderen DHCP-Server zu erhalten.

Sollte der Client es versäumen, bis zum Ablauf der Lease-Zeit eine Verlängerung zu beantragen, muss er seine Netzwerkkarte dekonfigurieren und wieder bei ''DHCPDISCOVER'' mit einer initialen Adresszuweisung beginnen. Sollte der DHCP-Server keine Adressen mehr zur Verfügung haben oder während des Vorganges schon ein anderer Client seine letzte Adresse zugesagt bekommen haben, sendet der Server ein DHCPNAK (DHCP-Not Acknowledged), und der Vorgang der Adressanfrage beginnt erneut.

=== Sonstiges ===
Eine negative Bestätigung ''DHCPNAK'' kann als Ursache haben, dass der Client versucht, seine ehemalige IP-Adresse zu leasen (engl. lease: mieten oder pachten), die jedoch inzwischen nicht mehr verfügbar ist, oder wenn der Client-Computer in ein anderes Subnetz verschoben wurde.

Um die Ausfallwahrscheinlichkeit zu verringern, ist es auch möglich, mehrere DHCP-Server in einem Netz zu platzieren. Dabei sollte allerdings beachtet werden, dass sich die Adressbereiche der einzelnen Server nicht überlappen, da es sonst zu Doppelvergaben von IP-Adressen kommen kann. Dazu gibt es die „authoritative“ (engl. für „maßgebliche“) Einstellung, mit der man einstellen kann, ob ein ''DHCPNAK'' auch verschickt werden soll, wenn der DHCP-Server für die vom Client vorgeschlagene Adresse nicht zuständig ist.

Wenn der Client eine negative Bestätigung erhält, wird der DHCP-Lease-Vorgang erneut gestartet.

Ein Client sendet ''DHCPRELEASE'', wenn er eine IP-Adresse vor Ablauf der Lease-Zeit zurückgeben will.

Sollte der Client feststellen, dass die zugewiesene Adresse bereits benutzt wird, so teilt er das dem Server durch ''DHCPDECLINE'' mit, der seinerseits den [[Administrator (Rolle)|Administrator]] von dieser potentiellen Fehlkonfiguration unterrichten sollte.

=== DHCP und DNS ===
Damit ihre [[Namensauflösung]] möglich ist, registrieren Computer ihren Namen und ihre IP-Adresse in der Regel bei einem [[Domain Name System|DNS]]-Server. Einige DHCP-Server können das an Stelle der Clients übernehmen. Bei Betriebssystemen von [[Microsoft]] war das vor [[Microsoft Windows 2000|Windows 2000]] erforderlich.

=== Mögliche Zuweisungen ===
Standardmäßig kann DHCP dem Client unter anderem folgende Einstellungen zuweisen:

* IP-Adresse und Netzwerkmaske
* Default-Gateway
* DNS-Server, DNS Context und DNS Tree
* Sekundärer DNS-Server
* Time- (nach <nowiki>RFC 868</nowiki>) sowie [[Network Time Protocol|NTP]]-Server
* [[Windows Internet Naming Service|WINS]]-Server (für Microsoft Windows Clients)
* Proxy-Konfiguration via [[Web Proxy Autodiscovery Protocol|WPAD]]

Es gibt jedoch weit mehr DHCP-Optionen<ref>{{Internetquelle |url=https://www.iana.org/assignments/bootp-dhcp-parameters/bootp-dhcp-parameters.xhtml |titel=Dynamic Host Configuration Protocol (DHCP) and Bootstrap Protocol (BOOTP) Parameters |werk=Internet Assigned Numbers Authority |datum=2023-11-07 |sprache=en |abruf=2024-12-05}}</ref>, die vom DHCP-Client implementiert werden können. Ein gutes Beispiel ist die Angabe eines [[Trivial File Transfer Protocol|TFTP]]-Servers für den Betrieb einer [[Diskless-Workstation]]. In diesem Fall muss das [[BIOS]]/[[UEFI]] die TFTP-Zuweisung per DHCP unterstützen, um einen [[Preboot Execution Environment|PXE]]-Boot zu initiieren.

== DHCP für mehrere Subnetze ==
Der DHCP-Server kann (Teil-)Netze bedienen, wenn er über Definitionen für das jeweilige Netz verfügt. Die Auswahl der Definition wird dann durch die Netzwerkkarte bestimmt, über welche die Anforderung hereinkommt. Beim Start des DHCP-Servers kann angegeben werden, auf welchen Interfaces der Server hört.

Andererseits kann ein DHCP-Server auch entfernte Netze bedienen, wenn diese durch einen DHCP-Relay-Agenten (vielfach als Funktion eines Routers verfügbar) verbunden sind. Der Relay-Agent empfängt im entfernten Netz die DHCP-Broadcast-Anforderungen und leitet diese als Unicast-Botschaften an den/die konfigurierten DHCP-Server weiter. Die IP-Adresse der Schnittstelle, über welche der Broadcast empfangen wurde, wird vom Relay-Agenten dem Unicast-Paket im DHCP-Header hinzugefügt, so dass der DHCP-Server anhand dieser Information bestimmen kann, aus welchem Netzwerksegment die Anfrage kommt. Der DHCP-Relay-Agent empfängt die Antwortpakete der DHCP-Server auf Port UDP 67 und leitet diese dann mit Zielport UDP 68 an den Client weiter.

== Sicherheit ==
DHCP kann leicht gestört und manipuliert werden, weil DHCP-Clients jeden DHCP-Server akzeptieren.

Die versehentliche Aktivierung eines DHCP-Servers, beispielsweise durch den Anschluss eines einfachen DSL-[[Router]]s oder WLAN-Routers im Auslieferungszustand, kann ein Netz weitgehend lahmlegen. Dieser antwortet möglicherweise schneller als der eigentlich vorgesehene DHCP-Server und verteilt dadurch ggf. ungültige Konfigurationen.

Ein Angreifer kann alle Adressen eines DHCP-Servers reservieren ([[DHCP Starvation Attack]]), dadurch dessen Antwort auf weitere Anfragen verhindern und anschließend als einziger DHCP-Server auftreten. Er hat nun die Möglichkeit ein [[rogue DHCP]] [[Spoofing]] zu betreiben, indem er auf andere DNS-Server umleitet, die auf Computer verweisen, die die Kommunikation [[Technische Kompromittierung|kompromittieren]].

Zum einen kann der Angreifer beispielsweise [[Denial of Service|Denial-of-Service-Angriffe]] starten, indem er jedem Client ein eigenes Subnetz zuweist, kein Gateway übermittelt oder auf alle Anfragen mit der gleichen IP-Adresse antwortet. Zum anderen kann er versuchen, mithilfe falscher Gateway- und DNS-Angaben einen fremden Router einzuschleusen, der den Datenverkehr des Clients mitschneidet oder umleitet ([[Man-in-the-Middle-Angriff]]).<ref>{{cite web|url=https://hosting.1und1.de/digitalguide/server/konfiguration/dhcp-das-client-server-protokoll-im-ueberblick/ |title=DHCP: Das steckt hinter dem Dynamic Host Configuration Protocol |publisher=1und1.de/digitalguide| accessdate=2017-10-02| offline= }}</ref>

Die vermeintliche Eindeutigkeit der [[MAC-Adresse]] darf nicht als Sicherheitskriterium angewandt werden. Es ist viel zu einfach, MAC-Adressen-[[Spoofing]] zu betreiben. Fast alle Betriebssysteme erlauben es gewöhnlichen Benutzern, die MAC-Adresse komfortabel in Konfigurationsmasken oder mit einfachen Tools wie ''ifconfig (UNIX, Linux)'' oder ''ip link'' (Linux) zu überschreiben. Gültige MAC-Adressen in einem Schicht-2-Netz können durch ''Abhören'' des Netzverkehrs ausfindig gemacht werden. Dazu ist lediglich der physische Zugang zum Netzwerk nötig. Die exklusive Vergabe von IP-Adressen nur an registrierte MAC-Adressen über [[Reverse Address Resolution Protocol|RARP]] oder DHCP schließt also nicht aus, dass Unberechtigte Zugriff auf das Netzwerk erhalten; dafür ist der Einsatz eines sicheren Authentifizierungsmechanismus wie [[IEEE 802.1X]] notwendig.

Eine Persiflage der Bemühungen, diese Probleme zu umgehen, ist das Wäscheklammerprotokoll [[Peg DHCP]].

== DHCPv6 ==
[[IPv6]] benötigt für die eigentliche Adressvergabe keinen DHCP-Dienst (siehe [[Ipv6#Autokonfiguration|IPv6 Autokonfiguration]]). Allerdings benötigt ein Client neben einem Gateway üblicherweise noch die Zuweisung eines [[Domain Name System|DNS]]-Servers. Ein standardisiertes Verfahren für die Mitteilung der DNS-Server wird in <nowiki>RFC 8106</nowiki> (RDNSS, DNSSL) beschrieben und stellt eine Erweiterung zu Autokonfiguration dar. Werden darüber hinaus Konfigurationsinformationen benötigt, kann anstatt von Autokonfiguration DHCPv6 verwendet werden.

'''DHCPv6''' ist seit Juli 2003 in <nowiki>RFC 3315</nowiki> spezifiziert und ermöglicht für IPv6 die gleiche Funktionalität wie das gegenwärtig aktuelle DHCPv4 für [[IPv4]]. Darüber hinaus ist DHCPv6 darauf ausgelegt, über optionale Felder im DHCPv6-Protokoll Konfigurationsinformationen über [[Network Information Service|NIS+]]-, [[Session Initiation Protocol|SIP]]-, [[Network Time Protocol|NTP]]- und weitere Dienste zu transportieren. Welche Optionen in DHCPv6 aufgenommen werden, wird von der DHCP-Arbeitsgruppe der [[Internet Engineering Task Force|IETF]] festgelegt. Weitere Features von DHCPv6 sind die integrierten Sicherheitsfunktionen, durch die es möglich ist, DHCPv6 nur autorisierten Clients zugänglich zu machen, sowie die Möglichkeit, die Adresskonfiguration weiterhin per statusloser Autokonfiguration erfolgen zu lassen, jedoch weitere Konfigurationsdetails per DHCPv6 auf die Clients zu bringen.

Abweichend von DHCPv4 läuft bei v6 die Kommunikation über die UDP-Ports 546 (Client) und 547 (Server).

== Literatur ==
=== Spezifikationen ===
* {{RFC-Internet |Autor=R. Droms |RFC=2131 |Titel=Dynamic Host Configuration Protocol |Datum=1997-03 |Obsoletes=1541}}
* {{RFC-Internet |Autor=S. Alexander, R. Droms |RFC=2132 |Titel=DHCP Options and BOOTP Vendor Extensions |Datum=1997-03 |Obsoletes=1533}}
* {{RFC-Internet |RFC=2136 |Titel=Dynamic Updates in the Domain Name System (DNS UPDATE) |Datum=1997-04}}
* {{RFC-Internet |RFC=3315 |Titel=Dynamic Host Configuration Protocol for IPv6 (DHCPv6) |Datum=2003-07}}
* {{RFC-Internet |Autor=T. Lemon, S. Cheshire |RFC=3396 |Titel=Encoding Long Options in the Dynamic Host Configuration Protocol (DHCPv4) |Datum=2002-11}}
* {{RFC-Internet |Autor=T. Lemon, B. Sommerfield |RFC=4361 |Titel=Node-specific Client Identifiers for Dynamic Host Configuration Protocol Version Four (DHCPv4) |Datum=2006-02}}
* {{RFC-Internet |RFC=6221 |Titel=Lightweight DHCPv6 Relay Agent |Datum=2011-05}}
* {{RFC-Internet |RFC=6422 |Titel=Relay-Supplied DHCP Options |Datum=2011-12}}
* {{RFC-Internet |RFC=6644 |Titel=Rebind Capability in DHCPv6 Reconfigure Messages |Datum=2012-07}}
* {{RFC-Internet |RFC=6842 |Titel=Client Identifier Option in DHCP Server Replies |Datum=2013-01}}

=== Weblinks ===
* {{dmoz|Computers/Internet/Protocols/DHCP/|DHCP}}
* [https://support.microsoft.com/kb/169289/de Grundlagen zu DHCP]
* {{Webarchiv |url=http://www.microsoft.com/germany/technet/datenbank/articles/images/CH06xx09_big.gif |text=Schaubild zur Verdeutlichung der Funktionsweise eines DHCP-Servers |wayback=20160305014043}}
* [https://ipv6int.net/software/index.html#dhcpv6 IPv6 Intelligence: DHCPv6], Beschreibung und Vergleich verschiedener DHCPv6-Software-Pakete (englisch)
* [http://www.networksorcery.com/enp/protocol/bootp/options.htm Liste aller DHCP-Optionen (englisch)]
* [http://www.litech.org/radvd/ Linux IPv6 Router Advertisement Daemon]

=== Einzelnachweise ===
<references />

{{Normdaten|TYP=s|GND=4608416-2}}

[[Kategorie:Netzwerkprotokoll auf Anwendungsschicht]]
[[Kategorie:Dynamic Host Configuration Protocol| ]]
[[Kategorie:Internetstandard]]

Dynamic Host Configuration Protocol - Versionsgeschichte

imported>Horst Gräbner: Änderungen von ~2025-26409-65 (Diskussion) auf die letzte Version von Horst Gräbner zurückgesetzt