DHCP (Dynamic Host Configuration Protocol)

Im Heimnetz: Macht die Fritz!Box automatisch. Im Server-Umfeld: Server haben oft Statische IPs (kein DHCP), damit man sie immer unter der gleichen Adresse findet. Oder "Static DHCP Lease": Der DHCP-Server gibt dem Server immer dieselbe IP, basierend auf seiner MAC-Adresse.

1. DORA Prozess

Die 4 Schritte:

1. Discover: Client schreit (Broadcast 255.255.255.255). "Ist hier ein DHCP-Server?"
2. Offer: Server antwortet (Unicast an MAC). "Ich hätte die .5 frei."
3. Request: Client sagt "Ja, die .5 will ich."
4. Acknowledge: Server bestätigt "Gehört dir für 24 Stunden."

2. Lease Time

Die IP gehört dir nur auf Zeit (Lease). Nach 50% der Zeit (T1 Timer) versucht der Client, zu verlängern (Renew). Wenn der Server nicht antwortet, versucht er nach 87.5% (T2) einen anderen Server zu finden. Wenn Lease abläuft -> Netzwerk weg.

3. DHCP Snooping & Starvation

• Starvation Attack: Ein Hacker sendet Millionen DHCP Requests mit gefälschten MACs. Der Server vergibt alle IPs aus seinem Pool. Echte User kriegen keine IP mehr (DoS).
• Rogue DHCP: Hacker stellt eigenen DHCP-Server auf. Er gibt Usern eine falsche Gateway-IP (seine eigene). Jetzt leitet er den Traffic um (Man-in-the-Middle).
• Schutz: "DHCP Snooping" auf dem Switch aktivieren. Der Switch lässt DHCP-Antworten nur vom vertrauenswürdigen Router-Port zu.

1. Der DHCP-Relay Agent (PXE Routing über Subnetze)

Das Fundament von DHCP ist eine dicke Schwachstelle: Es basiert aus Prinzip auf extrem radikalen IP-Broadcasts (Ziel-IP 255.255.255.255). Nach der Naturgesetz-Regel von Routing-Hardware werden Broadcasts niemals "geroutet". Sie enden brutal am eigenen Router (Subnetz-Grenze). Doch Enterprise-Firmen wollen verständlicherweise nicht für jedes der 50 internen VLANs einen eigenen, teuren dedizierten DHCP-Server betreiben. Lösung: Der DHCP Relay Agent (oft direkt auf dem Cisco Switch Konfiguriert, ip helper-address). Er "fängt" den rohen Client-Broadcast stumm ab dem Port des Switches, maskiert ihn (kapselt die Daten), verschickt das Paket per gezieltem Unicast (direkt Adressiert) ans zentrale Datacenter zum DHCP-Server. Die Antwort wird den gleichen Weg demaskiert zurück gespielt.

2. DHCPv6 (Stateless vs. Stateful IPv6)

DHCP ist das Rückgrat von IPv4. In einer modernen IPv6 Welt drohte DHCP fast völlig bedeutungslos zu sterben. Warum? IPv6 nutzt SLAAC (Stateless Address Autoconfiguration). Der Router brüllt per SLAAC Router-Advertisement (RA) völlig dezentral den Prefix (die ersten 64 bit) ins Netz, und der Client bastelt sich aus der eigenen MAC-Adresse den restlichen IPv6 Teil (64 bit) völlig autark zusammen (Stateless). Keiner protokolliert (Server), wer da ist. Es klappt magisch. Doch große Firmen wollen absolute Kontrolle und Logging (wer hat wann welche IP in Benutzung gehabt, für das Compliance Audit). Deswegen wurde Stateful DHCPv6 entwickelt. Hier behält ein Server im Kernnetz (wie beim klassischen v4) alle Buchungen in einer Tabelle (State). Wenn ein IPv6 Client bootet, sagt das Router-RA ihm "Frag bitte explizit beim DHCPv6 Server um Erlaubnis und Settings."

3. Option 82 (Circuit ID & Port-Sicherheit)

Warum loggt man sich im ICE Zug in das WLAN ein und kriegt magisch immer die "richtige ICE 19" IP-Range? Das geheimnisvolle Feature ist DHCP Option 82 (Relay Agent Information Option). Ein Access-Point stempelt an einen simplen "Ich brauche ne IP"-Request eines Handys noch wichtige Hardware-Zusatz-Infos an das Header-Protokoll an, bevor es weiter ans Backend geht: Option 82: Sub-Option 1 (Circuit ID) = "WLAN-Wagon-3-Sitz-5A" / Sub-Option 2 (Remote ID) = MAC-of-AP. Auf Basis dieser knallharten physischen Location-Token kann der zentrale DHCP Backend Server filtern und sagen: "Kunde am Wagen 3 kriegt eine IP in Subnetz .3, Kunde im Speisewagen VLAN erhält ein Red-Network Tag."