Zusammenfassung

  • Ein Relay kann per Suboption 11 die IPv4-Adresse vorgeben, die der Server in Option 54 schreibt. Sie lenkt spätere Renewals zurück zum Relay, ist aber weder Interface noch Identitätsnachweis des realen Servers.
  • ACK-Empfang, lokale Konfigurationsübernahme, Route, Policy, Verkehr und Dienst benötigen eigene Belege. Ein erfolgreicher Override schließt keinen dieser Zustände.

Der Packet Trace endet mit einem DHCPACK. Das Dashboard meldet Erfolg. Auf dem Client fehlt trotzdem die erwartete Route, und die Serviceprobe bleibt stumm. Die Ursache liegt nicht zwingend im DHCP-Transport; der Fehler kann zwischen Empfang und Installation oder zwischen Installation und Verkehr liegen. Der Server Identifier erklärt diese Übergänge nicht.

Bei DHCPv4 kann ein Relay im ersten DHCPDISCOVER Relay Agent Information mit Circuit-ID, Remote-ID und weiteren Suboptionen einsetzen. Nach der Zuweisung sendet ein Client in RENEWING seinen DHCPREQUEST normalerweise direkt an die Adresse aus Option 54. Abhängig von der Topologie sieht das Relay die Erneuerung nicht mehr und kann aktuelle Anschlussdaten nicht ergänzen.

RFC 5107 führt Server Identifier Override ein. Suboption 11 enthält vier Oktette IPv4-Adresse. Ein unterstützender Server muss diesen Wert in die Server-Identifier-Option seiner Antwort einsetzen. Das nächste Renewal erreicht damit das Relay, das aktuelle Relay Agent Information hinzufügt und die Anfrage an den eigentlichen Server weiterleitet.

Der Name der Option beschreibt dann nicht den physischen Server. Die Adresse ist ein Rückkehrpunkt im Steuerpfad. Client-Ziel, Relay-Instanz, Lease-Autorität und realer Server sind getrennte Rollen, auch wenn eine Oberfläche sie in einem Feld zeigt.

Der Server muss die Override-Adresse für spätere Nachrichten des Clients speichern, bis eine neue Relay-Nachricht eintrifft. Dieser Hilfszustand benötigt Generation, Quelle und Zeit. Ohne diese Provenienz lässt sich nach Restart oder Migration nicht erklären, warum ein gültiges Lease eine nicht mehr bekannte Rückadresse besitzt.

Ein Server ohne Unterstützung ignoriert die Suboption und schreibt sein eigenes Interface in Option 54. Die Erstzuweisung kann erfolgreich sein. Beim Renewal umgeht der Client jedoch das Relay, Circuit-ID und Remote-ID fehlen, und die beabsichtigte Policy-Kette ist nicht mehr dieselbe.

Support muss pro Serverinstanz geprüft werden. In einem gemischten Pool kann ein Teil die Adresse spiegeln und ein anderer nicht. Eine aggregierte ACK-Rate verdeckt den Zweig. Telemetrie braucht empfangene Suboption, tatsächlich ausgegebene Option 54 und beobachteten Renewal-Pfad.

Normalerweise vergleicht ein Server Option 54 im DHCPREQUEST mit seinen eigenen Interfaces. Mit Override vergleicht er Option 54 und Suboption 11. Stimmen beide überein, sollte er den Request verarbeiten, auch wenn die Adresse nicht lokal ist.

Die Übereinstimmung ist ein Konsistenzbeleg. Sie authentisiert weder Relay noch Server, beweist nicht den Ersteller der Felder und sagt nichts über Besitz der Adresse. Ein Boolesches server_verified aus diesem Vergleich wäre eine zusätzliche Behauptung.

Das Relay setzt giaddr weiterhin normal. Override-Adresse, Zuordnungsnetz, Circuit-ID, Remote-ID, Device Class und ursprünglicher Broadcast/Unicast-Modus haben unterschiedliche Geltungsbereiche. Ein undurchsichtiger Relay-Metadatenblock verliert diese Grenzen.

RFC 5010 stellt Relay Agent Flags für den ursprünglichen Empfangsmodus bereit; RFC 5107 empfiehlt ihre Nutzung. Der Server sieht den transformierten Relay-zu-Server-Paketweg. Daraus kann er die ursprüngliche Client-Übertragung nicht zuverlässig ableiten.

Bei mehreren Zielservern sollte das Relay alle DHCP-Nachrichten, einschließlich Renewals, an alle senden. Es soll keine Schattenkopie des Lease-Zustands pflegen. Die Server prüfen die Anfrage gegen ihren Zustand und die zuständige Instanz entscheidet.

Fan-out braucht Empfängerbelege. Relay-Empfang beweist nicht Server-Empfang. Ein ACK beweist nicht die Zustellung an alle Ziele. Schweigen eines Servers ohne Lease ist nicht automatisch Packet Loss. Transaktion, Override-Generation und Instanz müssen korreliert werden.

Das Relay wird Teil der Lease-Verfügbarkeit. Erreicht der Client die Override-Adresse nicht, scheitert das erste Segment. Erreicht das Relay den Server nicht, scheitert das zweite. In beiden Fällen kann Option 54 korrekt aussehen, während das Lease ausläuft.

Eine belastbare Kette erfasst Client-Ingress, Adresswahl, giaddr, ursprünglichen Modus, Digest der Relay-Information, Server-Empfang, gespeicherte Generation, Antwortwert, Client-Empfang, Renewal-Rückkehr, Forwarding je Ziel, Lease-Entscheidung, Konfigurationsinstallation und ersten Verkehr.

Restarts müssen Lease und Override getrennt testen. Ein Server kann das Lease wiederherstellen, aber die Hilfsadresse verlieren. Der Client behält die alte Option 54. Der präzise Fehler ist override_state_lost, nicht falsche Clientidentität.

Migrationen zeigen den Gegenfall. Eine Anycast-Adresse bleibt gleich, während sich die Relay-Menge ändert; oder der Serverpool bleibt gleich und die Rückadresse wechselt. Adresse, Instanz und Autorität müssen unabhängig versioniert werden.

Die Sicherheitsgrenze beruht auf Vertrauen zwischen Relay und Server. Ein bösartiges Relay kann seine Adresse eintragen, Renewals auf sich ziehen, sie später blockieren, DHCPACK-Optionen ändern oder eine längere Lease-Dauer darstellen. RFC 5107 verspricht durch die Suboption keinen Sicherheitsgewinn.

DHCP Authentication und Relay-Agent-Information-Authentisierung schützen unterschiedliche Beziehungen. Jeder Receipt muss Principal und geschützte Felder nennen. Serverseitige Relay-Authentisierung ist keine Client-seitige Serverauthentisierung.

Der Empfang eines authentischen DHCPACK beweist nur die Nachricht. Ob der Client Adresse, Maske, Router und Route übernommen hat, ist eine neue Transition. Ob Policy, Traffic und Dienst funktionieren, folgt noch später.

Für Führungskräfte ist deshalb die Conversion Chain wichtiger als die ACK-Zahl: Override ausgegeben, Renewal über Relay, Evidence rekonstruiert, Lease entschieden, ACK empfangen, Konfiguration installiert, erstes Paket, Serviceprobe. Jede Lücke hat eine andere Eigentümerschaft.

RFC 5107 zeigt, warum Feldnamen keine Ontologie sind. Ein Server Identifier kann absichtlich ein Relay-Ziel sein. Ein gutes Betriebsmodell behält die Indirektion bei und speichert die reale Serverinstanz separat.

Quellen