Zusammenfassung

  • Der aktive INTAREA-Arbeitsgruppenentwurf von Remco van Mook schlägt 192.0.0.11/32 als Sentinel-Gateway vor. Ein angepasster Host sendet dafür kein ARP, sondern verwendet die MAC des ausgewählten IPv6-Default-Routers.
  • Das Paket bleibt natives IPv4, ohne Tunnel und Übersetzung. Für den Rückweg braucht das Netz jedoch die IPv4-Hostroute /32 mit einem routbaren IPv6-GUA- oder ULA-Next-Hop.
  • Die Vereinfachung verbindet mehrere Zustände: DHCP, Router Advertisements, NUD, IPv4-Weiterleitung, Rückroute und ARP-Kompatibilität können unabhängig voneinander scheitern.

Eine Adresse als Verhaltensschalter

Der Sentinel bezeichnet kein Gerät. Er soll weder per ARP aufgelöst noch als echte Route verteilt oder als weitergeleitete Quell- beziehungsweise Zieladresse verwendet werden. Sein Platz in der IPv4-Tabelle löst lediglich eine lokale Regel aus: Wähle auf demselben Interface einen IPv6-Default-Router und entnimm dessen Layer-2-Adresse dem IPv6 Neighbor Cache.

Anwendungen verwenden weiter IPv4-Sockets, der Host erzeugt IPv4-Pakete und Router leiten IPv4 weiter. Es gibt weder NAT64 noch IPv6-Kapselung. Eingespart wird ausschließlich die getrennte IPv4-Auflösung des ersten Hops.

Seit August 2026 ist der Text ein INTAREA-Working-Group-Draft. Er berichtet von Tests ohne Änderungen an Anwendungen oder DHCPv4-Konfiguration unter Windows 11, macOS, Android, iOS, Linux, FreeBSD und ChromeOS. Das ist der Befund des Entwurfs, keine unabhängige Zertifizierung. Als Internet-Draft kann er sich ändern; der Sentinel ist noch kein überall gültiger Standard.

Vorwärts und zurück haben verschiedene Voraussetzungen

Ein DHCP-Lease beweist nur, dass die Anweisung beim Host ankam. Ohne Router Advertisement existiert kein IPv6-Router, dessen Nachbarzustand verwendbar wäre. Vor der ersten RA darf ein Implementierer Pakete nur begrenzt puffern.

Bei mehreren Kandidaten entscheidet zunächst die Präferenz nach RFC 4191, dann die Erreichbarkeit und schließlich eine implementierungsspezifische Auswahl. Ändert sich der Router, muss auch die IPv4-Route neu bewertet werden; bestehende Sitzungen können abbrechen. Auf der IETF 126 warnte Lorenzo Colitti deshalb vor Implementierungen, die IPv6-Änderungen nicht korrekt verfolgen und dadurch IPv4 beschädigen.

Auch der Neighbor Cache ist kein Gesamtbeweis. Reachable, stale, delay und probe nach RFC 4861 sind nutzbare, aber unterschiedliche Zustände. Eine gespeicherte MAC garantiert nicht, dass das Gerät noch IPv4 weiterleitet. Ein funktionierender Router bleibt umgekehrt unbrauchbar, wenn RA- oder ND-Zustand fehlt.

Für den ausgehenden ersten Hop genügt eine IPv6-Link-Local-Adresse. Über Router hinweg taugt sie nicht als Next Hop. Der Betreiber muss daher das IPv4 /32 des Hosts mit einem routbaren IPv6-GUA oder ULA bekanntmachen. RFC 8950 definiert IPv4-NLRI mit IPv6-Next-Hop in BGP; der ergänzende Entwurf v4-via-v6 behandelt die Router-zu-Router-Seite.

Ein ausgehender Ping ist somit nur ein Teilbeleg. Lease, gewählte RA, MAC, native IPv4-Weiterleitung und Rückroute müssen einzeln sichtbar sein.

Das /32 verhindert die Rückkehr des Subnetzes

Mit einem breiteren Präfix hielte der Host andere IPv4-Adressen für on-link und würde wieder ARP senden. Die Hostmaske ist deshalb ein Bestandteil des Mechanismus. Ebenso darf 192.0.0.11 nie zu einem gewöhnlichen Netzobjekt werden.

Der Draft verweist auf Hetzner, OVH und Scaleway, wo einzelne IPv4-Adressen mit Off-Link-Gateways eingesetzt würden und Betriebssysteme heute besondere Konfiguration benötigen. Diese vom Draft angeführten Beispiele erklären den Bedarf, belegen aber keine Einführung des neuen Sentinels bei den Unternehmen.

RFC 8925 bietet fähigen Clients die Präferenz für IPv6-only. Der Sentinel bedient einen anderen Fall: Dual-Stack-Geräte sollen in einem IPv6-zentrierten Zugangsnetz natives IPv4 behalten. Beide Bausteine können zusammenpassen, ersetzen aber nicht ihre jeweiligen Tests.

Altgeräte nutzen einen zweiten Pfad

Ein unveränderter Host behandelt den Sentinel wie ein normales Gateway und sendet ARP. Der Router soll mit der eigenen MAC antworten. Damit können moderne und alte Systeme dasselbe Segment teilen.

Doch Erfolg im Legacy-Pfad beweist nicht die IPv6-basierte Auswahl, und Erfolg im neuen Pfad beweist nicht den ARP-Fallback. Gemeinsame Verfügbarkeitswerte verschleiern genau diese Differenz. Beide Populationen brauchen eigene Sonden.

Tobias Fiebig nannte den Ansatz auf der IETF 126 im Vergleich zu DHCPv4-over-DHCPv6 elegant. Weniger Protokoll auf dem Draht bedeutet allerdings nicht weniger Betriebszustand. Die vorhandene IPv6-Steuerung übernimmt mehr Verantwortung.

Der Prototyp markiert seine Grenzen

Das öffentliche Repository v4-with-v6-nh enthält einen Linux-Daemon. Er erkennt den Sentinel, wählt nach RFC 4191, installiert eine IPv4-Route über einen IPv6-Next-Hop, verfolgt Änderungen und zieht die Route zurück. Linux kann solche Routen seit Kernel 5.2 darstellen.

Der Code kann vor der ersten RA nicht einzelne Pakete in der vom Entwurf beschriebenen Weise puffern. Die systemd-networkd-Unterstützung ist ein Patch, FreeBSD-Syntax wurde validiert, aber nicht getestet, kommerzielle Konfigurationen liefen nicht auf Hardware, und ein markiertes Release fehlt. Das ist starke Machbarkeitsevidenz, aber kein Beleg einheitlicher Produktionsreife.

Ein sinnvoller Test erzeugt Übergänge: DHCP-Ablauf, verspätete RA, Rückzug des bevorzugten Routers, alternden NUD-Zustand, Verlust der /32-Rückroute, gleich priorisierte Router und gemischte Hostgenerationen.

Das Vertrauen wandert zu RA und ND

Weniger ARP reduziert auf angepassten Hosts eine Spoofing-Fläche. First-Hop-Vertrauen verschwindet nicht. Eine falsche RA kann die für IPv4 verwendete MAC bestimmen, ein ND-Ausfall beide Adressfamilien unterbrechen.

RA Guard, vertrauenswürdige Ports, Prüfung des Nachbarzustands und explizite Präferenzen werden damit zu IPv4-Kontrollen. Besonders gefährlich ist ein stiller Fehler: DHCP verteilt den Sentinel in einem Segment, das nur die Hälfte des Verfahrens unterstützt. Manche DHCP-Prüfung kann das Off-Link-Gateway schon vorher ablehnen. Konfigurationsannahme und Weiterleitungsfähigkeit dürfen nie dieselbe grüne Lampe sein.

Quellen