Zusammenfassung

  • RFC 5192 transportiert nicht nur PAA-Adressen, sondern eine Präferenzfolge. Der PaC muss die Einträge in der empfangenen Reihenfolge versuchen. Sortieren, ungeordnetes Speichern oder positionslose Deduplikation können deshalb normativ relevantes Verhalten ändern.
  • Die Reihenfolge ist dennoch kein Gesundheitswert. Sie steuert den Versuch, beweist aber weder Erreichbarkeit noch PAA-Identität oder einen erfolgreichen PANA-Ablauf. Für jeden Übergang ist ein eigener Beleg nötig.

Viele Datenpipelines behandeln Reihenfolge als Präsentationsproblem. Arrays werden sortiert, Sets ersetzen Listen, gleiche Werte werden zusammengeführt. Bei RFC 5192 ist diese Normalisierung keine neutrale Aufbereitung. Die Reihenfolge gehört zur Bedeutung.

DHCPv4-Option 136 enthält 32-Bit-Adressen; ihre Nutzlänge muss durch vier teilbar sein. DHCPv6-Option 40 enthält 128-Bit-Adressen; dort gilt Teilbarkeit durch sechzehn. In beiden Formaten stehen PAAs in Präferenzreihenfolge, und der PaC muss die Datensätze in dieser Reihenfolge versuchen.

Eine sortierte Anzeige kann weiterhin alle Adressen zeigen und trotzdem die entscheidende Information verlieren. Wenn Ausführung und UI dasselbe veränderte Modell verwenden, wird ein Darstellungsfehler zum Steuerungsfehler.

Ordinalposition ist ein Datenwert

Jeder decodierte Eintrag braucht nicht nur eine Adresse, sondern auch ordinal und list_version. Die Version verweist auf den konkreten DHCP-Austausch, die Rohbytes, Länge, Familie, Schnittstelle und Validierung.

Die Originalfolge sollte unveränderlich bleiben. Eine UI darf für Menschen eine alternative Sortierung anbieten, muss sie aber als Ansicht kennzeichnen und darf sie nicht an den Selector zurückgeben. Ausführungsjobs konsumieren die normative Folge oder eine ausdrücklich autorisierte lokale Policy.

Auch Deduplikation braucht Vorsicht. RFC 5192 beschreibt Listen, nicht die Semantik doppelter Werte. Ein Produkt kann Dubletten behandeln, doch es muss die Eingabe bewahren und seine Transformation benennen. Sonst lässt sich nicht mehr prüfen, ob der PaC die empfangenen Records in Reihenfolge versucht hat.

Der Audit-Satz lautet deshalb nicht „Adresse X gewählt“, sondern „Version V, Position 1 versucht; Ergebnis T; Position 2 versucht; Ergebnis U“.

Präferenz ist keine Zustandsmessung

Die Serverreihenfolge sagt, welcher Kandidat zuerst kommt. Sie enthält keinen Health-Timestamp, keine Last, keine Kapazität, keinen Identitätsbeleg, kein Timeout und kein PANA-Ergebnis.

Ein bevorzugter PAA kann ausgefallen sein. Ein weniger bevorzugter kann funktionieren. Das verletzt den Standard nicht. Der Client befolgt die Reihenfolge und erzeugt beim Versuch neue Laufzeitbelege.

Umgekehrt beweist eine Antwort auf IP-Ebene nicht, dass der PANA-Dienst nutzbar ist. Der nachfolgende Protokollaustausch kann scheitern. Netzwerkbeobachtung, PANA-Nachricht und terminales Ergebnis gehören in getrennte Felder.

Nur den Gewinner zu speichern löscht Failover. Nur den ersten Kandidaten zu speichern löscht Erfolg. Eine unveränderte Liste plus Attempt-Ledger erhält beide Wahrheiten.

Angefordert und geliefert sind zwei Fragen

Der DHCPv4-Client sollte die Option in seiner Parameter Request List anfordern; DHCPv6 verwendet die Option Request Option. Ein konfigurierter Server sollte die PAA-Option aber auch senden, wenn der Client sie nicht ausdrücklich angefordert hat.

Darum darf eine Antwort nicht als Beleg für Client-Intent dienen. Request Set und Response Set werden getrennt gespeichert. In der Oberfläche sollte „nicht angefordert, vom Server geliefert“ sichtbar sein.

Diese Trennung verhindert, dass eine Serverkonfiguration zur angeblichen Zustimmung des Endgeräts wird. Sie hilft auch bei Fehlern: Eine unerwartete Liste kann korrekt und erlaubt sein, ohne dass der Client sie bewusst bestellt hat.

Danach folgen Strukturprüfung und Auswahl. Empfang beweist noch nicht, dass der Parser sie akzeptiert oder der Selector einen Kandidaten versucht hat.

Abwesenheit ist keine Verhandlung

RFC 5192 verbietet ausdrücklich, Anwesenheit oder Fehlen der Option als Aushandlung über PANA zu verwenden. Sonst könnte ein Angreifer die Option entfernen und den Client zu schwächerer oder fehlender Sicherheit bewegen.

Option absent ist daher eine Beobachtung des Response, keine Entscheidung „PANA optional“. Die Sicherheitsanforderung kommt aus einer anderen, benannten Policy-Quelle. Alternative Discovery oder Fail-Closed-Verhalten sind lokale Entscheidungen.

Dasselbe gilt nach einer Sortierpanne. Eine Pipeline darf nicht argumentieren, die PAA-Discovery sei ohnehin nur ein Hinweis und die Reihenfolge deshalb unwichtig. Der Standard gibt der Reihenfolge normative Bedeutung, während er der Option keine Verhandlungsmacht gibt. Beide Grenzen gelten gleichzeitig.

Genau diese asymmetrische Autorität muss das Datenmodell ausdrücken: stark für Sequencing, nicht zuständig für Security Policy.

Strukturfehler bleiben Fehler

Die Längenregeln erlauben eine eindeutige Zerlegung. Bei einem Rest kann ein Parser keine vollständige gültige Adressfolge aus dem gesamten Payload ableiten. RFC 5192 spezifiziert keine stille Reparatur.

Code, deklarierte und erfasste Länge, Rohbytes, Validatorversion und Ergebnis werden gespeichert. Ein lokaler Recovery-Mechanismus ist eine separate Transformation, nicht die empfangene Liste.

Ein ungültiges Feld als leer zu speichern ist ebenfalls falsch. Abwesenheit und ungültige Präsenz haben andere Ursachen. Besonders gefährlich wäre es, die gültig wirkenden vorderen Adressen zu sortieren und den Rest zu verwerfen: zwei stille Änderungen würden sich gegenseitig verdecken.

Die IANA-Registrierung bestätigt den Codepoint, nicht die Korrektheit eines konkreten Pakets. Registry, Syntax und Laufzeit sind verschiedene Beweisebenen.

Reihenfolge hat Akquisitionskontext

DHCP-Nachrichten besitzen Transaktion, Server, Relay, Interface, Lease, Renew und Rebind. Eine Liste gehört zu diesem Kontext. Wenn ein späterer Austausch eine andere Folge liefert, entsteht eine neue Version.

Bereits laufende Versuche bleiben mit der alten Version verknüpft. Eine lokale Policy kann sie abbrechen oder fortsetzen, aber diese Entscheidung wird als Ereignis protokolliert. Die neue Liste schreibt die Ursache des alten Versuchs nicht um.

IPv4 und IPv6 bleiben getrennte Folgen. RFC 5192 legt keine Dual-Stack-Racing-Policy fest. Wer beide Familien zusammenführt, muss Algorithmus, Priorität und Timeout lokal definieren.

Ein globales primary_paa kann weder zwei Familien noch zwei Zeiten abbilden. Es ist eine abgeleitete Ansicht, keine Beweisquelle.

Schutz ist am konkreten Austausch nachzuweisen

RFC 5192 warnt, dass der DHCP-Austausch vor der Zugangsauthentisierung in den meisten Netzen weder integritätsgeschützt noch ursprungsauthentisiert ist. Manipulierte oder eingeschleuste Antworten können einen PaC zu einem bösartigen PAA lenken, der Authentisierungsanfragen abfängt oder Zugang verweigert.

DHCP-Authentisierungsmechanismen existieren in anderen Standards. Ihre Dokumentation schützt kein beobachtetes Paket. Der Receipt nennt den tatsächlich geprüften Mechanismus, die Identität und das Ergebnis.

Auch ein authentisch gelieferter Sortierauftrag ist kein Health Check. Schutz belegt Herkunft und Integrität in seinem Umfang; Endpoint-Zustand und PANA-Ausgang bleiben spätere Beobachtungen.

Das verhindert Übertreibung in beide Richtungen: Eine ungeschützte Liste wird nicht zur Policy, eine geschützte Liste nicht zur Servicegarantie.

Ein Ablauf, der Anzeige und Ausführung trennt

Das Betriebsobjekt speichert Request und Response, Akquisitionskontext, Rohoption und Validierung. Die normative Liste erhält Hash, Version und Ordinals. UI-Views werden als Views markiert und dürfen die Quelle nicht mutieren.

Der Selector protokolliert Algorithmusversion und konsumierte Liste. Jeder Attempt erhält Kandidatenposition, Zeit, Beobachtung und Grund. Der ausgewählte Peer wird mit der PANA-Session verknüpft.

Der bereits veröffentlichte RFC-5191-Beitrag besitzt die späteren Grenzen zwischen Authentisierung, Autorisierung, Enforcement und Datenpfad. Hier bleibt die Frage enger: Hat das System die empfangene Discovery-Anweisung unverfälscht und erklärbar ausgeführt?

Heng Lus Disziplin der Realitätsebenen macht die Konsequenz klar. Eine saubere Darstellung darf nicht Autorität über die empfangene Reihenfolge gewinnen. Wenn die UI die Wirklichkeit schöner macht, muss die Automatisierung trotzdem mit der Wirklichkeit arbeiten.

Sources

  1. RFC 5192 HTML
  2. RFC 5192 Text
  3. RFC-5192-Eintrag
  4. Datatracker RFC 5192
  5. RFC-5192-Historie
  6. RFC-5192-Referenzen
  7. RFC-5192-Errata
  8. RFC 2131
  9. RFC-2131-Eintrag
  10. RFC 2132
  11. RFC 8415
  12. RFC-8415-Eintrag
  13. RFC 3315
  14. RFC 5191
  15. RFC 3748
  16. RFC 3118
  17. IANA BOOTP/DHCP parameters
  18. Heng Lu — On Reality Layers
  19. Heng Lu — Minimum Initial Specification
  20. Heng Lu — Running-Code Primacy