Zusammenfassung

  • draft-ietf-intarea-dhcp-rate-signaling-00 transportiert Upstream-, Downstream- und Ratentypwerte; ein unbekannter, für die Deutung wesentlicher Typ macht die gesamte Rate Option unbrauchbar.
  • Betreiber brauchen einen Entscheidungsbeleg vom empfangenen Byte über Parser, Nachrichtenstatus, Quelle, Ziel und physische Kappung bis zur tatsächlich laufenden Queue und ihrer gemessenen Wirkung.

Die Option enthält 1 Gbit/s Downstream und 200 Mbit/s Upstream. Beide Zahlen passen in die erwarteten Felder. Der danebenstehende Ratentyp ist jedoch reserviert und dem Gerät unbekannt. Zählt er Layer-2-Overhead mit oder nicht? Ohne diese Antwort lässt sich der gewünschte Engpass nicht zuverlässig setzen.

Der Vorschlag der INTAREA-Arbeitsgruppe behandelt diesen Fall bewusst streng. Unbekannte Suboption-Codes dürfen für Erweiterbarkeit übersprungen werden. Trägt dagegen ein bekanntes, semantisch wesentliches Feld einen unbekannten Wert, wird die ganze Rate Option verworfen. Das Gerät bleibt bei seiner lokalen Standardkonfiguration.

Revision 00 vom 27. August 2026 ist ein Informational Internet-Draft und läuft am 28. Februar 2027 ab. Sie ist weder RFC noch Nachweis einer Betreiberimplementierung. Beantragte Option-Codes und Registrierungen sind noch Teil des Verfahrens.

Vorwärtskompatibilität ist keine Einladung zum Raten

Die Unterscheidung zwischen unbekanntem Code und unbekanntem Wert schützt zwei Dinge zugleich. Ein Gerät soll neue, für seine Aufgabe irrelevante Erweiterungen tolerieren. Es soll aber keine Bedeutung erfinden, wenn ein bereits verstandenes Feld die Interpretation der übrigen Werte bestimmt.

Layer 2 und Layer 3 können bei identischer Nennrate verschiedene Byte-Mengen zählen. Ein falsch kalibrierter Shaper verschiebt womöglich den Engpass, statt ihn zu beherrschen. „Die Zahl sah plausibel aus“ ist deshalb kein sicherer Fallback.

Auch Wiederholungen haben Semantik: Die letzte Instanz wird verarbeitet. Ein Telemetriesystem, das gleiche Codes in eine ungeordnete Menge überführt, kann den Parserentscheid später nicht rekonstruieren. Und ein erfolgreicher DHCP-Lease beweist nicht, dass auch die Rate Option angenommen wurde. Protokollerfolg und Policy-Erfolg sind getrennte Ereignisse.

Eine OFFER-Zahl besitzt noch keine Ausführungsgewalt

Ein Client kann eine Rate aus DHCPOFFER oder ADVERTISE bei der Serverauswahl berücksichtigen. Anwenden darf er sie erst nach DHCPACK oder REPLY. Die frühe Information beeinflusst, welcher Autorität er folgt; sie ist selbst noch kein Konfigurationsauftrag.

Deshalb reicht „500 Mbit/s gesehen“ als Logzeile nicht. Welche Nachricht? Hat der ausgewählte Server den Wert bestätigt? Hat ein Relay ihn danach geändert? Ist der Lease gültig? Derselbe Zahlenwert wechselt während eines Austauschs seinen Status.

Clients dürfen ihrerseits Raten oder eine Layer-Präferenz vorschlagen. Der Server kann den Hinweis annehmen, ablehnen oder transformieren. Die Anfrage belegt einen Vorschlag, weder Tarif noch spätere Durchsetzung.

Das Relay kann eine neue Beweislage schaffen

Ein DHCPv4-Relay kann die Option aus DHCPACK lesen und einen lokalen Shaper oder Policer instanziieren. Es darf sie auch hinzufügen, verändern oder entfernen, etwa nach Abfrage von RADIUS oder einer anderen AAA-Quelle.

Damit sind Serverausgabe und Clienteingang zwei Beweisobjekte. Eine legitime Änderung bleibt eine Änderung. Ihr Beleg sollte Relay-Identität, Subscriber-Session, AAA-Version, alten und neuen Wert, Richtung, Typ, Ziel, Grund und Gültigkeit enthalten.

RFC 3046 liefert Kontext für Relay-Agent-Information; RFC 2865 für RADIUS. Keines der Dokumente weist für sich nach, dass die konkrete Mutation autorisiert war. Wer nur den Endwert speichert, nennt später womöglich eine Relay-Entscheidung fälschlich Serverpolitik.

In DHCPv6 ist die Kapsel Teil der Adresse

Ein Server kann dem Client im REPLY eine Rate senden und Relays in verschachtelten RELAY-REPL-Schichten andere Werte geben. Ein CPE könnte 480 Mbit/s erhalten, ein Access-Relay 520 Mbit/s für Burst-Spielraum. Die Abweichung ist kein Konflikt, wenn die Ziele verschieden sind.

Das Relay muss die Option seiner eigenen Hülle verwenden. Es darf nicht in der clientgerichteten Nutzlast nach einem passenden Wert suchen. Besitz des äußeren Pakets bedeutet nicht Zuständigkeit für alle inneren Anweisungen.

Eine belastbare Aufzeichnung hält daher Kapselungsebene und Adressat fest. Eine semantisch korrekte Rate am falschen Ziel bleibt eine unautorisierte Aktion.

Gültigkeit kann wechseln, obwohl die Anzeige stillsteht

Bei widersprüchlichen DHCPv4- und DHCPv6-Werten bevorzugt der Entwurf v6 und verlangt, das Quellprotokoll mit der angewandten Rate zu speichern. Liefern beide 500 Mbit/s und läuft der v6-Lease ab, bleibt die Anzeige unverändert, während die Autorität auf v4 übergeht.

Server, Relay-Pfad und Lebensdauer können sich geändert haben. Ohne gültigen v4-Lease fällt das Gerät auf seine Voreinstellung zurück. In PPPoE-Umgebungen überstimmt DHCP eine Rate aus der PPP-Authentifizierungsantwort; das Ende der Session entzieht wiederum die Gültigkeit.

Null bedeutet in diesen Suboptionen unbeschränkt beziehungsweise Entfernen eines bestehenden Limits. Es ist keine Messung von null Kapazität. Ein Dashboard, das beides gleichsetzt, macht aus einem korrekten Löschbefehl einen erfundenen Ausfall.

Aus Snooping wird Eingriff

Ein DHCP-Snooping-Switch darf die Option beobachten und daraus Hardware-Queues, Shaper oder Policer bauen. Sobald er den Verkehr verändert, ist er Aktuator und nicht bloß Sensor.

Der Beleg muss beobachtetes Paket, Trust-Domain des Ports, Session-Bindung, Nachrichtenstatus, Kapselung, Ziel, Interface-Kapazität, lokale Grenze, Konfigurations-Commit und ausgelesenen Hardwarezustand verbinden. Die Sichtbarkeit eines Feldes beweist nicht, dass es an den Switch gerichtet war.

Heng Lus Gedanke der running-code primacy wird hier praktisch: Entscheidend ist der Zustand, der tatsächlich Pakete behandelt. Doch laufender Code allein legitimiert sich nicht. Die Kette muss ebenfalls zeigen, wessen Auftrag ihn in diesen Zustand brachte.

Plausibilitätsgrenzen authentifizieren keinen Absender

DHCP läuft häufig im Klartext und ohne Authentifizierung. Ein Rogue Server oder On-Path-Angreifer kann eine niedrige, syntaktisch korrekte Rate einschleusen. Die Adressvergabe funktioniert, während der nutzbare Dienst gedrosselt wird.

Eine Mindestschwelle fängt extreme Tiefwerte ab; die physische Portgrenze kappt überhöhte Werte. Keine der Regeln belegt die Quelle. RFC 3118 beschreibt DHCP-Authentifizierung, aber seine Existenz ist kein Deployment-Beleg. Zu prüfen sind Server-Allowlist, vertrauenswürdige Ports, Relay-Kette, Snooping-Schutz, Session-Bindung und AAA-Autorität.

Eine installierte Queue ist noch kein Latenzerfolg

Gute Kenntnis des Engpasses kann Shaping und AQM verbessern. RFC 7567 beschreibt die Schäden übergroßer Queues; RFC 9330 die flachen Queues von L4S. Der Empfang einer Option beweist dennoch keine geringere Latenz.

Nach dem Commit müssen effektive Konfiguration, Queue-Belegung, Marks, Drops, Latenzverteilung, Durchsatz, Fehler und Rollback beobachtet werden. Signal, Handlung und Ergebnis sind drei verschiedene Aussagen.

Der robuste Standardisierungsgewinn bleibt schmal: Richtung, Zählebene, Ziel, ausführbarer Nachrichtenstatus, Konfliktregel, Ablauf und Fallback. Er kann kein Subscriber-Profil wahr machen, kein Relay transparent und keine Queue wirksam erklären, nur weil die Zahl in DHCP steht.

Unsicherheit

Der Entwurf kann sich ändern, ersetzt werden oder auslaufen. Diese Recherche hat keine konkrete Firmware, kein CPE, Relay, Switch oder Produktionsnetz als Implementierung bestätigt. Die behaupteten Betriebs- und Performancevorteile bleiben lokal zu prüfende Begründungen.

Quellen