Zusammenfassung

  • RFC 9928 verlagert die DHCPv4-over-DHCPv6-Kapselung eines nicht aufrüstbaren IPv4-Clients in einen 4o6RA.
  • Damit verschiebt sich die Beobachtung: Ein sauberer Austausch belegt nicht, dass Layer-2-Herkunft und Interface-ID die Zuteilungspolitik erreichten oder der Client anschließend erreichbar war.

Die Freigabeakte enthielt alle erwarteten Nachrichtentypen. Der Altclient sendete DHCPv4, der Zwischenknoten erzeugte DHCPV4-QUERY, die Antwort kam zurück, und der innere Inhalt wurde weitergeleitet. Trotzdem fehlte das entscheidende Bindeglied: Zu welchem Access-Port gehörte die Transaktion? Wenn der Server seine Auswahl nach Topologie trifft, ist eine Antwort ohne diese Herkunft noch kein Beleg für die richtige Konfiguration.

RFC 7341 beschreibt DHCPv4-over-DHCPv6, damit IPv4-Parameter durch ein IPv6-Netz bezogen werden können. Dort beherrscht der Client DHCP 4o6 selbst. RFC 9928 nimmt sich der langlebigen, eingebetteten oder sonst nicht aktualisierbaren IPv4-only-Geräte an. Ein Switch oder Router führt als 4o6RA die Kapselung und Entkapselung stellvertretend aus.

Der Endpunkt spricht weiter gewöhnliches DHCPv4. Im Verhältnis zu RFC 7341 übernimmt jedoch der 4o6RA die Clientrolle. Er bestimmt seine DHCPv6-Schnittstelle, sucht Server oder Relay, beschafft die nötige IPv6-Konfiguration, fordert die DHCP 4o6 Server Address option an und verpackt die eingehende Clientnachricht.

Auf dem Rückweg verwirft er eine Antwort, wenn die DHCPv4 message option fehlt oder die Nachricht fehlerhaft ist. Nur ein korrekter innerer Inhalt, der tatsächlich weitergeleitet werden kann, darf den anfragenden Client erreichen. Das Format bleibt das bestehende DHCPv6-Relay-Format; dem kompatiblen Server werden keine neuen Anforderungen auferlegt. Der Standard schafft einen engen, prüfbaren Transportvertrag.

Der Zuteilungskontext liegt außerhalb dieses Vertrags. RFC 7969 zeigt, wie DHCP Konfiguration nach Netztopologie unterscheiden kann. Bei DHCPv4 setzt üblicherweise nur der erste Relay giaddr; eine Relay-Kette bildet damit nur einen Teil des Weges ab. DHCPv6 kann durch link-address und Interface-ID mehrerer Relays eine Folge bis zum Server übermitteln.

Kapselt der Client selbst, kennt der DHCPv6-Relay die Eingangsschnittstelle des gekapselten Pakets. Wandert die 4o6-Funktion an einen Zwischenknoten am Rand des IPv6-Netzes, erscheint dieser als DHCPv6-Client. Das Layer-2-Segment dahinter verschwindet. RFC 9928 sagt ausdrücklich, dass eine reine 4o6RA-Lösung die Topologieübermittlung unterbricht, weil dem gekapselten Paket die Schnittstelleninformation des verborgenen Segments fehlt.

Empfohlen wird ein unmittelbar gekoppelter LDRA nach RFC 6221, der Interface-ID in die ausgehende Anfrage einbringt. Doch wie 4o6RA und LDRA intern Schnittstelleninformationen austauschen, welches Format gilt und ob die Beteiligung des 4o6RA markiert wird, bleibt außerhalb der Spezifikation. Genau dort beginnt die lokale Nachweispflicht.

Heng Lus Minimum Initial Specification liefert dafür den richtigen Maßstab. Die gemeinsame Schicht enthält nur das, was für Interoperabilität nötig und lokal prüfbar ist. Spätere Implementierungs- und Einführungsentscheidungen bleiben bei den Betreibern, die ihre Folgen tragen. „RFC-konform“ ist daher keine Ersatzbehauptung für eine unbekannte interne Zuordnung. Der Betreiber muss diese Zuordnung benennen, versionieren und testen.

Auch die Pfadkontrolle ist lokal. Weil der Altclient nichts vom 4o6RA weiß, müssen sämtliche DHCPv4-Broadcasts und -Unicasts durch ihn gelenkt werden. RFC 9928 nennt eine zentrale Platzierung oder NAT für Unicast. Ist im selben Layer-2-Bereich noch ein gewöhnlicher DHCPv4-Server direkt erreichbar, kann Verkehr den 4o6RA umgehen. Falscher Zustand bei Client und Server sowie Fehlkonfiguration mit Erreichbarkeitswirkung sind möglich. Der RFC nennt das einen Deploymentfehler, kein neu geschaffenes Sicherheitsproblem. Für den Betrieb bleibt es eine echte Störung.

Ein belastbarer Beleg trennt deshalb: Transaction ID und Request-Hash; Access-Port, VLAN oder Eingangsinterface; gewählte DHCPv6-Schnittstelle; Serverfindung; Query- und Response-Hashes; Relay-Reihenfolge, link-address und Interface-ID; tatsächlich verwendete Policy-Eingaben; gewählte Adresse und Optionen; Formprüfung und Weiterleitungsentscheidung; vom Client akzeptierten Lease-Zustand; Konfliktbeobachtung; sowie eine unabhängige Pfad-, Erreichbarkeits- oder Dienstprobe.

Mit den Fakten werden auch Rollen getrennt. Access-Betrieb belegt den Eintrittspunkt. Relay-Betrieb belegt die Transformation. DHCP-Verantwortliche belegen die Auswahlregel. Endpoint-Verantwortliche belegen den installierten Zustand. Service Operations belegt die Wirkung. Selbst bei einem gemeinsamen Team bleiben diese Belege getrennt, weil sie anders altern und anders zurückgerollt werden.

Running-Code Primacy verlangt nicht, einer grünen Kennzahl alles zu glauben. Sie verlangt, den tatsächlichen Rechenbefund ernst zu nehmen. Eine Relay-Transaktion ist genau das. Eine Serverantwort ist eine Entscheidung auf den vorhandenen Eingaben. Ein gebundener Client ist lokaler Zustand. Ein Probe-Ergebnis ist eine zeitgebundene Beobachtung. Erst ihre nachvollziehbare Verbindung schließt den Kreis.

Quellen