Zusammenfassung

  • RFC 9928 erlaubt einem 4o6RA, DHCPv4-Nachrichten für einen Legacy-Client in DHCPv6 ein- und wieder auszupacken. Der Client bleibt über diesen Transport im Unklaren.
  • Liegt die Funktion in einem Zwischenknoten, kann das Layer-2-Segment aus der DHCPv6-Topologie verschwinden. Die empfohlene Kombination aus 4o6RA und LDRA ergänzt die Interface-ID; der interne Austausch zwischen beiden Funktionen ist jedoch nicht standardisiert.
  • Ein erfolgreicher Lease belegt Zuteilung und Rücklieferung. Er belegt weder den beobachteten Port noch dessen lokale Abbildung, die angewandte Serverregel oder das Fehlen eines direkten DHCPv4-Pfades.
  • Ein Relay-Custody-Beleg muss Eingang, Kapselung, verschachtelte Relay-Reihenfolge, Poolentscheidung, Rückweg, Bypass-Prüfung sowie Ablauf oder Korrektur zusammenführen.

Das Gerät kennt nur Anfang und Ende

Ein älteres IPv4-Funkmodul sendet DHCPv4 an einen Access-Switch. Wenig später besitzt es Adresse, Gateway und DNS-Konfiguration. Auf dem Gerät erscheint kein Hinweis darauf, dass die Anfrage dazwischen als DHCPv6 weiterlief. Das ist kein Informationsverlust aus Sicht des Clients, sondern die beabsichtigte Kompatibilität.

RFC 7341 beschrieb DHCP 4o6 zunächst für Clients, die die Kapselung selbst beherrschen. Nicht austauschbare Geräte können diese Rolle nicht übernehmen. RFC 9928 verlagert sie daher auf einen DHCPv4-over-DHCPv6 Relay Agent.

Der 4o6RA nimmt die DHCPv4-Anfrage entgegen, erzeugt DHCPV4-QUERY und leitet die eingebettete Nachricht weiter. Auf dem Rückweg prüft er DHCPV4-RESPONSE, entnimmt die gültige DHCPv4-Antwort und liefert sie an den ursprünglichen Client. Der Legacy-Client ist laut RFC nicht darüber informiert, dass ein DHCP-4o6-Dienst beteiligt ist.

Damit kann der Client das Ergebnis bestätigen, nicht den Weg. Er weiß nicht, welche Upstream-Schnittstelle der 4o6RA gewählt hat, welche Relay-Hüllen entstanden oder welche Topologiedaten der Server zur Entscheidung erhielt.

Der Anschlussort kann die Konfiguration bestimmen

RFC 7969 erläutert, wie DHCP-Server Adressen und Parameter anhand von Relay-Topologie auswählen. Der Relay-Knoten kennt den Eingang der ursprünglichen Anfrage. In Zugangsnetzen kann diese Information einen bestimmten Pool oder eine standortspezifische Konfiguration auslösen.

DHCPv4 und DHCPv6 modellieren den Pfad unterschiedlich. Bei DHCPv4 setzt üblicherweise nur das erste Relay giaddr. DHCPv6 kann mehrere Relay-forward-Nachrichten verschachteln; link-address und Interface-ID beschreiben die Abfolge. Die Antwort läuft in umgekehrter Verschachtelung zurück.

Wird DHCP 4o6 in einen Zwischenknoten verschoben, entsteht die DHCPv6-Nachricht erst hinter dem Layer-2-Zugang. RFC 9928 stellt fest, dass eine reine 4o6RA-Lösung keine Schnittstelleninformation in die gekapselte Nachricht einbringt und dadurch die Topologieübertragung unterbricht.

Trotzdem kann der Server einen Lease ausstellen. Ein Fallback-Pool liefert eine verwendbare Adresse, ohne die feinere Standortregel anzuwenden. Der Lease ist dann protokollarisch real, aber als Beleg für den richtigen physischen Anschluss unvollständig.

Die Interface-ID braucht eine lokale Übersetzung

RFC 9928 empfiehlt, 4o6RA und Lightweight DHCPv6 Relay Agent back-to-back zu kombinieren. Der LDRA erfasst die clientseitige Schnittstelle und fügt dem ausgehenden DHCPV4-QUERY eine Interface-ID hinzu.

RFC 6221 verlangt die Option in jedem Relay-forward des LDRA. Der Wert sollte für dieselbe Schnittstelle stabil bleiben, auch über Neustarts hinweg. Ein Server darf ihn für exakte Policy-Zuordnungen verwenden.

Die Interface-ID ist jedoch undurchsichtig. Der Server soll ihre Bytes nicht als Chassis-, Slot-, Port- oder Kundenangabe zerlegen. Erst eine lokale Zuordnung erklärt, welche physische Beobachtung den Wert in einer bestimmten Konfigurationsgeneration erzeugte.

RFC 9915 verpflichtet den Server, die Interface-ID in Relay-reply zu kopieren. Das Relay wählt damit die Schnittstelle zum Client. Der gleiche Wert wirkt somit bei Zuteilung und Zustellung, ohne die Richtigkeit der lokalen Abbildung selbst zu bescheinigen.

Die interne Naht bleibt Sache der Implementierung

RFC 9928 legt weder den internen Austausch zwischen 4o6RA und LDRA noch dessen Format fest. Auch die Kennzeichnung, dass ein 4o6RA beteiligt war, bleibt außerhalb des Anwendungsbereichs. Eine Implementierung kann beide Funktionen in einem Prozess verbinden; eine andere führt Switch-Hardware, Agent und Steuerungssystem zusammen.

Normgerechte Wire-Nachrichten erzeugen daher nicht automatisch eine einheitliche Provenienz. Der Betreiber muss festhalten, welches Bauteil den Port beobachtete, welche Mapping-Generation die Interface-ID erzeugte, was zwischen den Funktionen übergeben wurde und wie fehlende oder veraltete Daten behandelt werden.

Im einfachen Fall, dass 4o6RA und DHCP-4o6-Server auf demselben Knoten liegen, kann der 4o6RA allein genügen. Entscheidend ist nicht die Zahl der Funktionskästen, sondern ob die Serverpolicy ihre erforderliche Topologie erhält und deren Herkunft überprüfbar bleibt.

Ein direkter Pfad kann einen zweiten Lease erzeugen

Weil der Client den Mechanismus nicht kennt, muss das Netz seine DHCPv4-Broadcasts und -Unicasts über den 4o6RA lenken. Ein direkt erreichbarer DHCPv4-Server im selben Layer-2-Bereich kann sonst antworten, ohne dass 4o6 beteiligt ist. RFC 9928 ordnet daraus entstehenden falschen Zustand oder Erreichbarkeitsprobleme als Deployment-Fehler ein.

Für die Beweisführung zählt: Beide Pfade können plausibel aussehen. Der beabsichtigte 4o6-Dienst und der direkte Server können unterschiedliche Leases mit unterschiedlichen Regeln erzeugen. Der Client kann nicht erklären, welcher Kontrollpfad gewann.

Der Custody-Beleg benötigt deshalb auch einen Negativnachweis: Broadcasts wurden abgefangen, Unicast-Erneuerungen blieben im vorgesehenen Pfad, ein direkter Server war nicht erreichbar oder wurde nachweislich blockiert.

Der Beleg besteht aus Übergängen

Der vorgeschlagene Relay-Custody-Beleg ist keine neue DHCP-Option und keine IETF-Konformitätsbescheinigung.

Er hält die beobachtete DHCPv4-Anfrage, Transaktionsbezug, Zeit, Access-Knoten und Client-Port fest. Dazu kommen Mapping-Generation, 4o6RA, Upstream-Auswahl und Kapselungsereignis. Die interne Übergabe zum LDRA erhält einen eigenen Eintrag mit Implementierungsstand und Fehlerverhalten.

Danach folgen undurchsichtige Interface-ID, genaue Ebene im Relay-forward, weitere link-address-Werte und die für die Policy relevante Reihenfolge. Der Server dokumentiert die passende Regel, den Pool und die zurückgegebenen Parameter. Der Rückweg verbindet Relay-reply, Entkapselung und Lieferung an den ursprünglichen Port.

Abschließend werden Bypass-Prüfung, Renew, Rebind, Portwechsel, Korrektur, Ablauf oder Rollback festgehalten. Kein einzelnes Log kann all diese Aussagen tragen. Der Beleg verhindert, dass ein technischer Erfolg ungeprüft die Bedeutung einer anderen Schicht übernimmt.

Die IETF definiert interoperables Verhalten. Der Access-Betreiber kontrolliert Port und Mapping, der Relay-Betreiber Lenkung und Kapselung, der DHCP-Dienst Regel und Pool. Der unwissende Legacy-Client ist Empfänger des Ergebnisses, nicht informierter Auftraggeber der unsichtbaren Topologieentscheidung.

Quellen