Zusammenfassung

  • draft-ietf-intarea-dhcp-rate-signaling-00 schlägt 64-Bit-Werte für Up- und Downstream sowie einen Rate Type für rein informative, Layer-2- und Layer-3-Bedeutung vor. Die Zahl transportiert eine Service-Policy; sie misst keine momentane Kapazität.
  • Der Client darf vorschlagen, der Server antwortet, ein Relay kann ergänzen oder überschreiben. DHCPv6 kann zudem verschiedene Relay-Ebenen mit unterschiedlichen Werten adressieren. „Kam per DHCP“ benennt weder den einzigen Entscheider noch den Ausführenden.
  • Für eine belastbare Betriebsaussage müssen Herkunft und Gültigkeit erhalten, die wirksame Konfiguration zurückgelesen, die aktive Queue identifiziert und Paket- sowie Dienstresultate beobachtet werden.

Ein Heimrouter erneuert seinen DHCPv6-Lease und erhält im REPLY 1.000.000.000 bit/s für den Downstream. Die Oberfläche zeigt „1 Gbit/s verfügbar“, und die Automatisierung meldet erfolgreiches Shaping. Sobald jedoch ein großer Upload läuft, steigt die Latenz eines Gesprächs stark an.

Das ist kein logischer Widerspruch. Der Wert kann das gebuchte Profil statt einer Messung beschreiben. Er kann Layer-2-Bytes zählen, während ein Speedtest Layer-3-Nutzlast ausweist. Die Queue kann am falschen logischen Interface hängen. Ein BNG kann niedriger begrenzen, oder der tatsächliche Engpass liegt außerhalb des Einflusses des CPE.

Dieses Beispiel ist analytisch, kein dokumentierter Ausfall. Es zeigt die Beweisgrenze der Working-Group-Fassung 00: Das Protokoll verteilt eine beabsichtigte Rate, bestätigt aber weder ihre Ausführung noch ihre Wirkung.

Drei Bücher statt einer Bandbreitenspalte

„Geschwindigkeit“ bezeichnet im Zugangsnetz mindestens drei verschiedene Größen: den gebuchten oder zugewiesenen Tarif, den tatsächlich wirksamen Shaper/Policer und das beobachtete Ergebnis eines konkreten Verkehrsprofils.

Buch Notwendiger Beleg Offene Frage
Signal rohe Option, Richtung, Rate Type, Nachricht, Transaktion, Lease, Server/Relay Hat irgendein Gerät den Wert angewandt?
Wirksame Steuerung Gerät, Interface, Queue, Algorithmus, Overhead-Modell, Schreibvorgang und Rücklesen Ist dies der reale Engpass und stimmt das Resultat?
Dienstergebnis ECN, Drops, Queue-Verweilzeit, Verlust, Latenz und Durchsatz unter definierter Last Wer hat die Policy autorisiert?

Die DHCP-Option speist das erste Buch und soll das zweite ermöglichen. Das dritte schreibt nur der laufende Verkehr. Werden alle drei in bandwidth zusammengeführt, verschwinden Ursache, Zuständigkeit und sichere Rücknahme.

Die Zählebene ist Teil des Vertrags

Beide Richtungswerte sind vorzeichenlose 64-Bit-Ganzzahlen in bit/s. Der Rate Type legt fest, welche Bytes zählen.

Typ 2 bedeutet Layer 2: Ethernet-Header und Nutzlast, nach der empfohlenen Rechnung ohne FCS und Inter-Packet Gap. Typ 3 bedeutet Layer 3: IP-Header und Nutzlast, unabhängig von wechselnden VLAN-Tags oder Tunneln. Fehlt der Rate Type, muss der Empfänger Layer 2 annehmen. Typ 0 ist ausschließlich informativ; er darf weder Interface noch Shaper, Policer oder AQM verändern.

Ein L2-Shaper mit 1 Gbit/s stellt der Anwendung nicht dieselbe Nutzlast bereit wie ein L3-Shaper mit 1 Gbit/s. Ein Speedtest kann deshalb unter dem L2-Signal liegen, ohne es zu widerlegen. Eine Oberfläche, die den Typ ausblendet, macht aus einer begrenzten technischen Aussage ein mehrdeutiges Versprechen.

Ein reservierter oder unbekannter Rate Type verwirft die gesamte OPTION_RATE. Ein unbekannter Suboption-Code wird dagegen übersprungen, während die übrigen Werte verarbeitet werden. Bei mehrfacher gleicher Suboption gilt die letzte. Der Audit-Trail muss diesen Auswertungspfad bewahren, nicht nur die normalisierte Zahl.

Auch Null hat zwei Rollen. Ein Richtungswert von null entfernt eine vorherige Grenze und setzt auf den Gerätestandard zurück; er ist keine Messung von null Kapazität. Rate Type null heißt „nur Anzeige/Telemetrie“. Wer beides zusammenwirft, lässt entweder eine alte Drossel zurück oder macht aus Information einen Befehl.

Serverautorität endet an der Protokollgrenze

Ein DHCPv4-Client kann die Option in der PRL anfordern und in DHCPREQUEST eine maximale Rate oder bevorzugte Ebene vorschlagen. Das bleibt ein Hinweis. Der Server entscheidet; der Client übernimmt die Antwort im DHCPACK. Ein Wert im DHCPOFFER darf die Serverwahl beeinflussen, aber nicht das Interface konfigurieren.

DHCPv6 trennt ebenso: ORO fordert an, Request darf vorschlagen, REPLY liefert den anwendbaren Wert. ADVERTISE reicht nicht. Mit RECONFIGURE kann der Server vor T1 ein Renew oder Information-request auslösen.

Der Server kann die Rate aus lokalem Profil, RADIUS/AAA oder externer Policy ableiten. Ein DHCPv4-Relay wie ein BNG darf OPTION_RATE hinzufügen, ändern oder entfernen. Damit kann die Antwort für das im Draft definierte Clientverhalten autoritativ sein und trotzdem einen veralteten oder für den Datenpfad ungeeigneten Wert tragen.

RFC 2131 und RFC 8415 liefern die DHCP-Zustandsmaschinen. RFC 3046 beschreibt Relay-Information, RFC 2865 RADIUS. Keines liest eine installierte Queue zurück oder bewertet das Nutzerergebnis.

DHCPv6 kann mehrere lokale Wahrheiten verteilen

Verschachtelte Relay-Header erlauben dem Server, einen Wert in der clientseitigen REPLY und andere Werte für einzelne Relay-Ebenen zu setzen. Der Draft nennt etwa einen Upstream-Policer am Relay, der leicht oberhalb des CPE-Shapers liegt. Jedes Relay soll seine gezielt adressierte Ebene konsumieren, nicht passiv die innere Client-REPLY auswerten.

Es gibt dann nicht „die DHCP-Rate“. Der Datensatz braucht Richtung, Kapselungsebene, Empfänger, Policy-Quelle, Zählebene, Lease und Gültigkeitsintervall. RFC 6221 beschreibt den referenzierten Lightweight DHCPv6 Relay Agent, belegt aber nicht, dass ein konkretes Gerät die neue Option verarbeitet oder Hardware programmiert hat.

Dual Stack macht aus der Zahl eine Historie

DHCPv4 und v6 können widersprüchliche Raten liefern. Der Draft empfiehlt v6 und verlangt, das Quellprotokoll mit dem angewandten Wert zu speichern. Läuft der v6-Lease ab, während v4 gültig bleibt, wird die beibehaltene Rate für spätere Updates als v4-abgeleitet behandelt. Ohne gültiges v4 fällt das Gerät auf den Standard zurück.

Ein zeitloses Feld „aktuelle Rate“ kann diese Entscheidung nicht nachbilden. Nötig sind Lease-Kennungen, Erwerb, Ablauf, Präzedenzzweig, Ablösung und Reset-Grund.

PPPoE bringt eine weitere Lebensdauer. DHCP OPTION_RATE hat Vorrang vor einer Rate in der PPP-Authentifizierungsantwort. Doch die PPP-Session bildet den logischen Link: eine gültige Null entfernt den Wert, und ein Session-Ende widerruft ihn implizit. RFC 2516 liefert den Kontext. Bleibt die Drossel danach bestehen, ist sie keine Priorität mehr, sondern verwaiste Autorität.

Der physische Deckel entdeckt keinen Pfad

Meldet der Server 2 Gbit/s an einen CPE-Port mit 1 Gbit/s, soll das Gerät die wirksame Shaping-, Policing- oder AQM-Rate auf die physische Kapazität begrenzen. Verwaltung sollte Original und Deckelwert zeigen und die Abweichung protokollieren.

Das beweist nur eine lokale Schranke. Es beweist weder verfügbare 1 Gbit/s noch die Position des Engpasses. PON-Segment, Aggregation, BNG, Transit oder Gegenstelle können langsamer sein. Der ehrliche Name lautet „wirksame lokale Rate“, nicht „verfügbare Kapazität“.

AQM braucht die richtige Queue

Die Motivation ist plausibel. Ist der CPE-Port schneller als der Tarif, entsteht die Queue womöglich in einem vorgelagerten Gerät mit tiefem Puffer oder grobem Drop-Verhalten. Ein lokaler Shaper knapp unter der Providergrenze kann die kontrollierbare Queue ins CPE verlagern, wo AQM Verzögerung begrenzt.

RFC 7567 gibt AQM-Empfehlungen. RFC 9330, RFC 9331 und RFC 9332 beschreiben L4S-Architektur, ECN-Protokoll und Coupled DualQ AQM. Wirkung erfordert weiterhin korrekte Queue-Platzierung, Klassifikation, ECN-Semantik, Algorithmus und reagierende Staukontrolle.

Der Draft nennt sein Signal zutreffend einen Enabler und lässt den AQM-Entwurf außerhalb des Geltungsbereichs. Eine empfangene Zahl wählt keinen qdisc, bindet ihn nicht ans aktive Egress und belegt weder geringere Latenz noch volle Auslastung.

Authentifizierung endet bei der Urheberschaft

Der Draft weist darauf hin, dass DHCP meist unverschlüsselt und nicht authentifiziert ist. Ein Rogue-Server oder Angreifer im Pfad kann eine sehr niedrige Rate injizieren und lokal drosseln. Mindestschwellen und physische Deckel begrenzen Extremwerte, stellen aber keine Herkunft fest.

Auch eine Signatur würde zunächst nur den Sprecher belegen. Sie bestätigt nicht die Aktualität des Profils, die Treue des Relays, die Ausführung beim Empfänger oder das Dienstresultat. Identität, Autorisierung, Ausführung und Ergebnis bleiben vier Belege.

Running-Code Primacy stellt das tatsächliche Verhalten über das Label. Minimum Initial Specification empfiehlt einen schmalen interoperablen Kern und lokal austauschbare Weiterentwicklung. Reality Layers trennt Symbol, Konfiguration, physische Queue und beobachtetes Ergebnis.

Veröffentlichung ist kein Einsatznachweis

Der Datatracker führt Revision 00 als aktiven Internet-Draft der Internet Area Working Group mit angestrebtem Status Informational, veröffentlicht am 27. August 2026 und gültig bis 28. Februar 2027. Die Historie dokumentiert die Ablösung des Individual Draft. WG-XML, Vorgängerakte und Individualrevision 01 machen die Linie prüfbar.

Es ist kein RFC; die Optionscodes sind TBD. Die Quellen belegen weder Herstellerunterstützung noch Feldbetrieb, Interoperabilität, messbare Verbesserung oder einen realen Vorfall.

Quellen