Zusammenfassung

  • Eine DHCPv4-Antwort mit Maske /32 und ohne Router-Option kann einen älteren Client bedienen und zugleich dessen gewöhnliche IPv4-Route zu Zielen außerhalb des lokalen Links entfernen.
  • Weniger Wiederholungsanfragen bedeuten weder eine freigewordene Adresse noch einen abgeschirmten Host: Die eindeutige Lease bleibt belegt, und Nachbarn desselben Links können weiterhin Pakete senden.

Eine ruhigere Schnittstelle ist noch keine freiere Adresse

Ein alter Dual-Stack-Rechner kann weiter IPv4 anfordern, obwohl ein Betreiber die Anwendungen auf IPv6 ausrichten will. Die Antwort einfach einzustellen, kann den Client zu weiteren unbeantworteten DHCPv4-Versuchen veranlassen. Ein am 2. Oktober veröffentlichter technischer Beitrag im LACNIC-Blog beschreibt einen engeren Kompatibilitätsweg aus einem individuellen Internet-Draft: Der Server antwortet mit bekannten DHCPv4-Parametern, konfiguriert die Schnittstelle aber ohne die gewöhnliche IPv4-Route zu Zielen außerhalb des lokalen Links.

Option 1 nach DHCPv4 übermittelt die Maske 255.255.255.255, also /32. Der Server lässt Option 3 mit den Router-Informationen weg. Für den Host liegt damit jedes andere IPv4-Ziel außerhalb seines eigenen einzelnen Adressbereichs; ohne mitgeteilten Router fehlt ihm die übliche nächste Station. Er hat die angefragte Konfiguration erhalten, sodass erneute Suchversuche enden können. Daraus folgt keine nutzbare IPv4-Verbindung ins übrige Netz.

Das Verfahren schaltet IPv4 nicht vollständig ab. Auf der konfigurierten Schnittstelle bleibt eine IPv4-Adresse aktiv, und DHCPv4 läuft weiter. Eine zweite Schnittstelle, eine statische Route, ein Tunnel oder eine Anwendung mit abweichendem Verhalten kann weiterhin einen anderen Pfad bereitstellen. Manche Anwendungen versuchen nach einem IPv4-Fehler IPv6. Der Draft beschreibt eine Erwartung, aber keine Garantie für jedes Betriebssystem oder jeden Dienst. Eine belastbare Aussage muss sich deshalb auf die konkrete Schnittstelle und deren Routing beziehen.

Für jeden stillen Host bleibt eine eindeutige Lease nötig

Der oft übersehene Punkt ist nicht das Paketaufkommen, sondern der Zustand der Zuweisung. Jeder Host am gleichen Link benötigt weiterhin eine eindeutige IPv4-Adresse vom DHCPv4-Server. Ein einzelner Wert lässt sich im Normalfall nicht von allen stillen Clients eines gemeinsamen Segments gleichzeitig verwenden. Mechanismen zur Adresskonflikterkennung können vor der Nutzung prüfen; erhalten zwei Clients doch dieselbe Adresse, kann ein Konflikt sichtbar werden. Der Draft warnt zudem, dass eine wiederholte Neuvergabe einer bekannten Konfliktadresse in eine DHCPDECLINE-Schleife führen kann.

Sinkt die Zahl der Wiederholungsanfragen, läuft die Adressvergabe trotzdem weiter. Bis ein Client seine Adresse freigibt oder die dynamische Lease ausläuft, belegt der Datensatz einen Platz im Pool. RFC 2131 definiert dynamische Zuweisung als zeitlich begrenzt und grundsätzlich wiederverwendbar, wenn eine Adresse nicht mehr gebraucht wird. Ein aktiver Lease-Eintrag misst weder die Zahl der Broadcasts noch beweist er, dass der Wert wieder verfügbar ist.

Die Opportunitätskosten hängen davon ab, welcher Pool verwendet wird. Stammt die Lease aus einem knappen öffentlichen IPv4-Bestand, bleibt sie auch dann kostspielig, wenn der Host über seinen gewöhnlichen Pfad keine externen Ziele erreicht. Der Draft nennt auch linklokale oder RFC-1918-Adressen. Ein eigens dafür reservierter privater Pool schont öffentliche Adressen, erfordert aber weiterhin eine eindeutige Adresse pro Gerät, DHCP-Zustand, Konfliktbehandlung und eine Prüfung auf Überschneidungen mit der bestehenden privaten Adressplanung.

Pool-Wiederverwendung zwischen unterschiedlichen physischen Links ist nur unter Bedingungen denkbar, etwa wenn der DHCP-Server unmittelbar an jedem Link hängt. Bei Weiterleitung über DHCP-Relay wählt der Server einen Pool anhand der Relay-Adresse. Der Draft verlangt deshalb Eindeutigkeit im weitergeleiteten Netzbereich. Wer diese Grenze ignoriert, verwandelt eine rechnerische Einsparung in eine falsche Adresszuweisung.

Längere Leases tauschen Nachrichten gegen längere Bindung

Für Hosts, die keine externen IPv4-Ziele erreichen sollen, hält der Draft Leases von einem Tag bis zu mehreren Wochen für erwägenswert. Weniger Verlängerungen können Serverlast und DHCP-Nachrichten reduzieren. Zugleich bleibt die Adresse länger reserviert. Bei einem knappen öffentlichen Pool folgt aus weniger DHCP-Verkehr nicht, dass mehr freie Adressen entstehen. Betreiber sollten daher Anfragerate und belegte Adresstage gemeinsam betrachten. Das ist eine Folgerung aus der Lease-Mechanik, kein im Blog ausgewiesener Messwert.

Option 108 bietet einem anderen Clienttyp einen anderen Pfad. RFC 8925 standardisiert IPv6-Only Preferred für unterstützende Clients in ausdrücklich dafür konfigurierten IPv6-mostly-Netzen. Unterstützen Client und Server die Option, kann ein Client dort auf eine IPv4-Zuweisung verzichten, sofern die erforderlichen IPv6-Funktionen bereitstehen. Das bewahrt Poolkapazität. Die /32-Idee richtet sich an Altgeräte, die Option 108 nicht verstehen; der Draft sieht beide Ansätze als kombinierbar an. Keiner der beiden DHCP-Wege belegt für sich, dass Anwendungen, DNS64/NAT64 oder betriebliche Dienste funktionieren.

Keine Standardroute ist keine eingehende Firewall

Ohne Router-Option fehlt dem Host die gewöhnliche Route zu IPv4-Zielen außerhalb seines Links. Unsichtbar für andere Geräte desselben Links wird er dadurch nicht. Der Sicherheitsabschnitt des Drafts hält ausdrücklich fest, dass ein anderer Host IPv4-Pakete an den /32-Rechner senden kann. Empfohlen wird eine Host-Firewall, die auf dieser Schnittstelle nur DHCPv4 zwischen Client und Server oder Relay zulässt.

„Kann gewöhnliche IPv4-Verbindungen außerhalb des Links nicht beginnen“ ist eine andere Aussage als „kann keine IPv4-Pakete empfangen“. Die erste ergibt sich aus der vorgeschlagenen Routenlage, die zweite nicht. Läuft auf dem Gerät ein lokaler Dienst oder ist es über eine weitere Schnittstelle erreichbar, ersetzt das fehlende Gateway keine klare Eingangsregel.

Was die öffentliche Evidenz trägt

Dem LACNIC-Beitrag zufolge hat Autor Alejandro Acosta den Ansatz mit Windows 11, Fedora 43, Raspberry Pi OS auf Basis von Debian Trixie, Chromecast und Google Nest ausprobiert. Smartphones wurden nicht getestet; der Text fordert ausdrücklich weitere Kompatibilitätsprüfungen. Das sind vom Autor berichtete Versuche, keine unabhängige Replikation, repräsentative Geräteauswahl oder Produktionsmessung. Der Blog erklärt außerdem, dass die Ansichten des Autors nicht notwendigerweise die Position von LACNIC wiedergeben.

Die zitierte Grundlage ist Version 02 eines individuellen Internet-Drafts. Der IETF Datatracker führt den 15. Juni 2026 als Ablaufdatum und weist darauf hin, dass der Entwurf keinen formalen Status im IETF-Standardisierungsprozess hat. Ein abgelaufener Entwurf ist dadurch nicht technisch widerlegt; ein verfügbarer Draft ist aber auch keine Standardfreigabe. In den geprüften öffentlichen Quellen finden sich keine gemessene Verringerung von DHCP-Broadcasts, keine Änderung der Poolauslastung, kein Ergebnis zum IPv6-Erfolg von Anwendungen und kein Sicherheitsaudit für eingehenden Verkehr.

Ein Betreiber, der den Ansatz erprobt, sollte daher getrennt erfassen: wiederholte DHCP-Anfragen der Zielgeräte, aktive Leases und belegte Adresstage nach öffentlichem, privatem und linklokalem Pool, Freigaben, Ablauf und DHCPDECLINE, die Zuordnung zu Relay und Link, IPv6-Erfolg einer Stichprobe von Anwendungen sowie die tatsächlich wirksamen Firewall-Regeln. Ein ruhigerer Link, eine zurückgewonnene knappe Adresse, eine funktionierende Anwendung und ein begrenzter Eingangsverkehr sind vier verschiedene Ergebnisse.

Quellen: