IPv4/DHCP

Historie

• DHCP kann als Nachfolger vom BOOT-Protokoll verstanden werden, das entwickelt wurde, um Rechner ohne Festplatte in IP-Netzen zu starten und automatisch zu konfigurieren.
• Veröffentlichung der ersten DHCP-Version Ende 1993 im RFC 1541
• Ablösung durch neue Version in RFC 2131 im März 1997
• Erweiterungen von RFC 2131 durch die RFCs 2132, 3396 & 4361

Grundlagen

• DHCP regelt die dynamische Vergabe von IP-Adressen und kann die Konfiguration von Rechnern unterstützen
• DHCP funktioniert nach dem Client-Server-Prinzip
• Benutzer eines Rechners benötigt keine IP-Adresse von einem Administrator - werden vom DHCP-Server zur Verfügung gestellt
• IP-Konfigurationsparameter für die Clients sind auf dem DHCP-Server gespeichert
• Vergabe der IP-Adressen erfolgt aus einem Pool von IP-Adressen, der vom Server verwaltet wird
• Implementierung von DHCP-Relays, um DHCP-Nachrichten in andere Subnetze weiterzuleiten, die über keinen DHCP-Server verfügen

Beim Start einer DHCP-Client-Applikation werden vom Server folgende Informationen angefordert:

• Client-IP-Adresse
• Lease-Dauer
• Identifikation des DHCP-Servers
• Subnetzmaske
• Default-Gateways
• statische Routen
• Hostname & Domainname
• Lokation externer Server (z. Bsp. Time-Server)

Anforderungen an den DHCP-Server

• Ein DHCP-Server muß über einen Bereich gültiger IP-Adressen verfügen.
• Der Server benötigt eine manuell zugewiesene statische IP-Adresse (Der Server selbst kann kein Client sein).
• Soll ein Server IP-Adressen für Clients in verschiedenen Subnetzen verteilen, so müssen sämtliche Router zwischen den Subnetzen als DHCP-Relay-Agenten konfiguriert werden. Wird dies von den Routern nicht unterstützt, benötigt jedes Subnetz einen eigenen DHCP-Server.
• Im Pool der IP-Adressen dürfen keine statischen IP-Adressen enthalten sein, da diese anderenfalls doppelt vergeben würden.

Ablauf des DHCP-Verfahrens

Automatische Zuweisung:

• IP-Adressen werden automatisch an die MAC-Adressen von neuen DHCP-Clients vergeben & diese Zuordnung in einer Tabelle festgehalten
• Vergabe der IP-Adresse an den Client erfolgt aus einem Pool von IP-Adressen, der vom Server verwaltet wird
• Zuordnungen sind permanent und werden nicht entfernt - jeder Client erhält somit stets die gleiche IP-Adresse

Dynamische Zuweisung:

• Vergabe erfolgt analog der Automatischen Zuweisung
• Zuweisung der IP-Konfiguration jedoch für einen bestimmten Zeitraum (Lease-Dauer)
• Verfall der IP-Adresse nach Ablauf der Lease-Dauer - Neuvergabe an anderen Client durch den DHCP-Server möglich
• Client kann/muß vor Ablauf der Lease-Dauer eine Verlängerung beantragen
• erlaubt, als einzige Zuweisungsmethode die Wiederverwendung von IP-Adressen, wenn der Client diese nicht mehr benötigt

Manuelle Zuweisung:

• DHCP-Server führt eine Zuweisungstabelle: feste Zuordnung von MAC-Adresse zu IP-Adresse (statisches DHCP)
• Client erhält immer die gleiche IP-Adresse
• nur Rechner mit bekannten & registrierten MAC-Adressen erhalten eine IP-Adresse
• sinnvoll bei Servern, die stets unter der gleichen IP-Adresse erreichbar sein sollen

DHCP_Nachrichten

• Austausch von festgelegten DHCP-Nachrichten zwischen Server & Client
• Übermittlung durch das verbindungslose Transportprotokoll UDP (Server-Port: 67 & Client-Port: 68)
• Der DHCP-Client stellt einen Anwendungsprozess auf einem Rechner dar & ist auf dem Well-Known-Port 68 erreichbar
• Der DHCP-Server läuft als Anwendungsprozess auf einem dedizierten Rechner & ist auf dem Well-Known-Port 67 zu erreichen

Aufbau von DHCP-Nachrichten

Feld	Länge [Byte]	Bedeutung	Beschreibung
op	1	Operation	gibt an, ob es sich um eine Anfrage oder Antwort handelt
htype	1	Netztyp	Angabe des Netztyps gemäß RFC 1340 (z. Bsp. 6 = 802.x-LAN)
hlen	1	Länge der Hardware-Adresse	physikalische Netzadresse (z. Bsp. 6 = MAC-Adresse)
hops	1	Anzahl der Hops	Anzahl von Routern mit DHCP-Relay-Funktion auf dem Weg zwischen Client & Server
xid	4	Transaktions-ID	Identifikationsnummer für die Transaktion zwischen Client & Server
secs	2	Sekunden	von Seiten des Clients, die Zeit seit Beginn des Vorgangs
flags	2	Flags	nur das höchstwertige Bit wird verwendet, um anzuzeigen, ob der Client noch über eine IP-Adresse verfügt
ciaddr	4	Client-IP-Adresse	wird vom Client angegeben, falls dieser noch über eine IP-Adresse verfügt
yiaddr	4	Your-IP-Adresse	IP-Adresse, die der Server dem Client zugewiesen hat
siaddr	4	Server-IP-Adresse	IP-Adresse des DHCP-Servers
giaddr	4		IP-Adresse des Routers mit DHCP-Relay-Funktion
chaddr	16	Client-Hardware-Adresse	Client-Mac-Adresse
sname	64	Server-Name
file	128	File / Datei
options	bis 312	Optionen	zusätzliche Konfigurationsparameter - DHCP-Optionen nach RFC 2132

Ablauf der Kommunikation

Anforderungsphase:

• Client sendet die Nachricht DHCP-DISCOVER mit einem Broadcast (Ziel-IP: 255.255.255.255) in sein lokales Netz
• DHCP-DISCOVER-Nachricht kann Optionen enthalten, wie zum Beispiel Vorschläge für IP-Adresse & Lease-Dauer
• Anforderung der benötigten Konfigurationsparameter - IP-Adresse, Subnetzmaske etc.
• Angabe der MAC-Adresse des Clients (chaddr) zwingend erforderlich
• Nachricht ist normalerweise auf das eigene Subnetz beschränkt - kann aber durch DHCP-Relay-Agenten in andere Subnetze weitergeleitet werden

Angebotsphase:

• Mit der Nachricht DHCP-OFFER läßt der DHCP-Server dem Client ein Angebot zukommen.
• Der Server versucht dabei, den Client direkt zu erreichen - was nicht immer möglich ist:

Fall A:

• Client wird gerade initialisiert & verfügt noch nicht über eine IP-Adresse
• Angebot wird als Broadcast versandt - erhält aber bereits die MAC-Adresse des Clients, so daß nur dieser die Nachricht lesen darf

Fall B:

• Client verfügt bereits über eine IP-Adresse - deren Lease-Dauer jedoch zu Ende geht
• Angebot wird in diesem Fall direkt an die IP-Adresse des Clients gesendet

• Zu diesem Zeitpunkt muß der Server die IP-Adresse noch nicht reservieren, kann dies aber tun.

Auswahlphase:

• Der Client wählt die Konfigurationsparameter des zuerst erhaltenen Angebots aus.
• Senden einer Nachricht DHCP-REQUEST - Optionsfeld muß den Eintrag DHCP Server Identifier enthalten - Server, die nicht im DHCP-REQUEST erwähnt werden, erhalten somit den Hinweis, daß ihr Angebot nicht angenommen wurde
• angebotene IP-Adresse wird mit der Option Requested IP Address bestätigt
• Nachricht wird als Broadcast versendet, um andere DHCP-Server darüber in Kenntnis zu setzen, daß der Client sich entschieden hat und die entsprechenden Server die reservierten Parameter wieder freigeben können

Bestätigungsphase:

• Antwort des DHCP-Servers mit der Nachricht DHCP-ACK mit allen Konfigurationsparametern für den Client
• Sollten in dieser Phase weitere Angebote eintreffen, werden diese vom Client verworfen.

Weitere DHCP-Nachrichtentypen:

DHCP-NAK:

• wird während der Bestätigungsphase vom Server an den Client gesendet, um diesen darauf hinzuweisen, daß die im DHCP-REQUEST angeforderten Konfigurationsparameter abgeleht wurden:
  • wenn ein Client versucht seine bisherige IP-Adresse zu verlängern, diese jedoch nicht mehr verfügbar ist
  • wenn ein Client in ein anderes Subnetz umgezogen & somit die IP-Adresse ungültig ist

DHCP-RELEASE:

• Hiermit teilt ein Client dem Server mit, daß er seine IP-Adresse nicht mehr benötigt und der Server die Adresse freigeben und anderweitig vergeben kann

DHCP-DECLINE:

• Der Client kann hierüber den Server in Kenntnis setzen, daß einige Parameter ungültig sind (zum Beispiel seine MAC-Adresse)

DHCP-INFORM:

• Kann von Clients verwendet werden, denen eine statische IP-Adresse zugewiesen wurde, um weitere dynamische Konfigurationsparameter vom Server anzufordern.