Zusammenfassung

  • draft-ietf-intarea-dhcp-rate-signaling-00 definiert vorgeschlagene DHCPv4- und DHCPv6-Optionen für provisionierte Raten; Server, Relays und Zugangsknoten können dabei unterschiedliche Werte erzeugen oder anwenden.
  • Ein Rate-Authority-Datensatz sollte Tarif, Serverangabe, L2/L3-Bezug, Relay-Änderungen, tatsächlich aktive Steuerung, physische Obergrenze und unabhängige Messungen auseinanderhalten.

Die Zahl ist da, bevor ein Test beginnt

Zeigt ein Heimrouter unmittelbar nach dem DHCPACK „1 Gbit/s“ an, wirkt die Angabe amtlich. Sie kam aus dem Netz und kann sogar als Parameter eines Shapers dienen. Dafür musste das Gerät aber weder Testverkehr erzeugen noch den Zugangslink auslasten oder einen entfernten Messserver erreichen.

DHCP Explicit Rate Signaling soll ein anderes Betriebsproblem lösen. Zwischen CPE und externem Modem oder ONT läuft häufig ein Ethernet-Link, dessen physische Geschwindigkeit über dem gebuchten Anschlussprofil liegt. Kennt das CPE nur diesen Link, bildet sich die Warteschlange womöglich hinter dem tatsächlichen Engpass. Mit expliziten Raten können CPE, Relay und ein DHCP-beobachtender Switch Shaping, Policing oder Active Queue Management näher an der provisionierten Grenze einrichten.

Das ist eine nützliche Kontrollfunktion, aber keine Kapazitätsermittlung. Der DHCP-Server darf den Wert aus lokaler Konfiguration, RADIUS/AAA oder einem externen Policy-System übernehmen. Die Zahl ist eine Projektion des Produkttarifs oder einer Teilnehmerregel. Sie sagt nicht, dass der Pfad diese Rate im Augenblick liefern kann.

Auch der Dokumentstatus braucht diese Nüchternheit. Der individuelle Entwurf durchlief ab 31. Juli 2026 einen INTAREA-Adoptionsaufruf. Am 27. August stellten die Vorsitzenden Konsens zur Übernahme fest; der inhaltlich gleiche WG-Entwurf 00 folgte. Er bleibt ein veränderlicher Internet-Draft. Datatracker nennt keinen vorgesehenen RFC-Status, und die beantragten IANA-Codes sind noch TBD. WG-Adoption ist weder fertiger Standard noch Einsatznachweis.

Einheiten stimmen überein, Bezugsflächen nicht

Die vorgeschlagene Container-Option enthält 64-Bit-Werte in Bit pro Sekunde für beide Richtungen und einen Ratentyp. Gerade dieser Typ entscheidet, worauf sich die Zahl bezieht.

Typ 0 ist rein informativ. Er kann einer Anzeige oder Telemetrie dienen, darf aber keine Schnittstelle, keinen Shaper, Policer oder AQM konfigurieren. Typ 2 bezeichnet eine Layer-2-Rate und gilt als Standard, falls die Typangabe fehlt. Typ 3 zählt auf Layer 3 nur IP-Header und Nutzlast. Der Entwurf weist darauf hin, dass L3 häufig der vermarkteten Produktbandbreite und der Grundlage von Speedtests entspricht.

Ein L2-Shaper und ein L3-Test können daher abweichende richtige Zahlen liefern. VLAN-Tags und Tunnel-Overhead verändern die Relation. Ebenso kann eine informative Rate sachlich korrekt und dennoch für Paketsteuerung unzulässig sein. Erkennt ein Empfänger den grundlegenden Ratentyp nicht, soll er die gesamte Option verwerfen und auf Vorgaben zurückfallen, statt eine Bedeutung zu erraten.

Null ist ebenfalls eine Anweisung. Eine Rate von 0 bedeutet unbeschränkt und kann ein früheres Limit entfernen. Explizite Null, fehlende Option, fehlerhafte Option und nicht beobachtete Antwort sind unterschiedliche Zustände. Wer alles als „0 Mbit/s“ speichert, macht aus einem Reset eine erfundene Störung.

Der autoritative Server ist nicht der letzte Bearbeiter

Der Client kann die Option anfordern, maximale Werte vorschlagen und L2 oder L3 bevorzugen. Im abschließenden DHCPACK beziehungsweise DHCPv6 REPLY ist trotzdem der Server maßgeblich. Diese Autorität gehört zur DHCP-Transaktion. Sie bestätigt weder den zugrunde liegenden Vertrag noch die Aktualität des AAA-Profils.

Auf dem Weg darf der Wert weiter verändert werden. Ein DHCPv4-Relay, darunter ein Broadband Network Gateway, kann die Option hinzufügen, ändern oder entfernen. Ein Layer-2-Knoten kann sie per Snooping auslesen und lokal eine Queue oder einen Policer anlegen. Bei DHCPv6 ermöglichen verschachtelte Relay-Reply-Header einen Wert für den Client und andere Werte für Zwischen-Relays. Jedes Relay verarbeitet die für seine Schicht bestimmte Anweisung, nicht den inneren Client-Inhalt.

Mehrere gültige Raten können somit gleichzeitig existieren. Das CPE kontrolliert vielleicht den Upstream, ein Access-Relay einen Teilpfad und das BNG den Downstream. Die Abweichung ist nicht automatisch ein Fehler. Sie macht aber den Screenshot eines einzelnen Geräts ungeeignet, den gesamten Policy-Zustand zu belegen.

Zeit verändert die Aussage zusätzlich. Lease-Erneuerungen und DHCPv6 Reconfigure können eine Rate während der Sitzung ersetzen. Bei DHCPv4 darf ein Angebot zur Serverwahl beitragen, angewendet wird die Option jedoch nur aus DHCPACK. Nachrichtentyp, Transaktion, Empfangszeit und Ablaufdatum gehören deshalb zum Wert.

Zwei Gigabit treffen auf eine Ein-Gigabit-Schnittstelle

Der Entwurf beschreibt ausdrücklich, wie ein Gerät mit einer Rate oberhalb seiner physischen Kapazität umgehen soll. Erhält ein CPE 2 Gbit/s für einen 1-Gbit/s-Port, soll es Shaping, Policing und AQM auf die Schnittstellenkapazität begrenzen. In der Anzeige sollen sowohl der empfangene als auch der wirksame Wert erscheinen; die Abweichung gehört ins Protokoll.

Damit entstehen drei getrennte Tatsachen: Netzankündigung, Gerätekonfiguration und physische Obergrenze. Eine Geschwindigkeitsmessung ist eine vierte. Sie hängt vom Messziel, vom Weg außerhalb des Access-Segments, von Auslastung, Transport, WLAN und Endgerät ab. Die Werte dürfen verglichen, aber nicht gegenseitig überschrieben werden.

Konflikte zwischen Protokollen benötigen ebenfalls Herkunft. Liefert DHCPv6 einen anderen Wert als DHCPv4, bevorzugt der Entwurf v6 und verlangt, das Quellprotokoll der aktiven Einstellung zu behalten. Bei mehreren gleichen Suboptionen gewinnt die zuletzt verarbeitete. Unter PPPoE hat DHCP Vorrang vor proprietären Raten aus der PPP-Authentifizierung; Null oder Sitzungsende stellen die Standardwerte wieder her.

Eine Anzeige „konfigurierte Rate“ erklärt nicht, ob v6 gewonnen, ein Relay umgeschrieben, ein Port gekappt oder PPP zurückgesetzt hat. Auch verworfene Kandidaten und Entscheidungsregeln sind Betriebsdaten.

Ein Herkunfts- und Entscheidungsblatt für die Rate

Jede wirksame Konfiguration sollte einen kompakten Rate-Authority-Datensatz erhalten. Das ist ein redaktioneller Governance-Vorschlag dieses Artikels, keine Forderung des IETF-Entwurfs.

Der Kopf nennt Teilnehmer-Session oder Lease, Gerät, Schnittstelle, DHCP-Version, Nachrichtentyp, Transaktionsbeleg, Empfang und Ablauf. Daneben stehen — sofern zugänglich — gebuchter Tarif und Policy-Quelle, getrennt von den durch den Server angekündigten Upstream- und Downstream-Werten sowie ihrem Informations-, L2- oder L3-Typ.

Jeder ändernde Hop bekommt eine Zeile: eingegangener Wert, Hinzufügen, Ändern oder Entfernen, ausgehender Wert, Identität von Relay oder BNG, Adressat und lokal eingerichtete Queue. Bei DHCPv6 ist die Relay-Reply-Schicht zu benennen. Ein Switch, der lediglich beobachtete, darf nicht als Durchsetzer erscheinen.

Das Ergebnis steht separat: effektive Shaper-, Policer- und AQM-Raten, physisches Limit, Begründung einer Kappung, siegreiches Protokoll und Reset-Bedingung. Messungen bilden eine verknüpfte Zeitreihe mit Methode und Endpunkten. „Angekündigt“, „angewendet“, „unterstützt“, „vertraglich“ und „gemessen“ sind unterschiedliche Verben. Das nackte Wort „Geschwindigkeit“ verwischt sie.

Plausibilität ersetzt keine Herkunft

DHCP wird oft ohne Nachrichtenauthentifizierung betrieben. Der Entwurf bewertet eine gefälschte niedrige Rate als möglichen Denial-of-Service-Vektor und nennt konfigurierbare Plausibilitätsschwellen. Das ist seine Bedrohungsanalyse, kein Bericht über einen nachgewiesenen Angriff.

Eine Schwelle stoppt extreme Zahlen, nicht glaubwürdige Fälschungen. Sie kann außerdem eine legitime Tarifänderung blockieren. Deshalb muss die administrative Berechtigung sichtbar sein: Welches System durfte den Tarif festlegen, welches Relay durfte überschreiben, und wer klärt eine Abweichung?

Im aktuellen IANA-Register der BOOTP/DHCP-Parameter fehlt die vorgeschlagene Option samt Suboptions- und Ratentyp-Registern. Das beschreibt den heutigen Prozessstand. Es beweist weder Ablehnung noch künftige Zuteilung. Frühe Versuche müssen Entwurfsversion und vorläufigen Code festhalten.

Die Grenze des Nachweises

RFC 7567 erklärt die Bedeutung von AQM am Engpass. RFC 9330 zeigt, weshalb L4S flache Warteschlangen und zeitnahe Überlastungssignale benötigt. Eine gute provisionierte Rate kann diese Mechanismen unterstützen und dadurch auch messbare Leistung verbessern.

Die DHCP-Antwort beweist dennoch nur, dass eine bestimmte Kontrollkette in einer bestimmten Transaktion eine Anweisung geliefert hat. Für eine Leistungsaussage fehlen Policy-Herkunft, Relay-Schritte, angewendeter Zustand, physische Grenzen und unabhängige Beobachtungen. Viele Bits in einem Zahlenfeld sind kein Ersatz für eine genaue Aussage darüber, was die Zahl weiß.

Quellen