Zusammenfassung

  • RFC 7710 hatte den DHCPv4-Code 160 für die Captive-Portal-Erkennung zugewiesen. Bei einem Netzversuch während der IETF 106 verwendeten einige Polycom-Geräte 160 bereits für andere Zwecke und arbeiteten mit der dort übertragenen API-URL nicht wie vorgesehen.
  • RFC 8910 verschob die Funktion auf 114. Im IANA-Register steht 160 heute als nicht zugewiesen, doch der Hinweis auf RFC 7710 und die Polycom-Nutzung bleibt erhalten: Registerzustand und tatsächliche Parserlandschaft sind getrennte Belege.

Zwei Wahrheiten im selben OFFER

Das Tagungsnetz der IETF 106 in Singapur erprobte eine bessere Entdeckung von Captive-Portalen. Kompatible Clients sollten eine venue-info-url erhalten. Für DHCPv4 lag die Wahl scheinbar fest: RFC 7710 hatte 2015 den Optionscode 160 für die Captive-Portal-Information bestimmt.

Der Versuch erreichte jedoch auch einige Polycom-Geräte. RFC 8910 hält fest, dass sie Code 160 für andere Zwecke nutzten. Enthielt die Option die URL der Captive Portal API, funktionierten diese Geräte nicht wie gewünscht.

Mehr gibt die Quelle nicht her. Sie nennt weder Modell noch Firmware, Anzahl, alternatives Datenformat oder genauen Fehler. Aus einer Herstellerbezeichnung lässt sich keine Geräteklasse konstruieren. Belegt ist die Kollision im beobachteten Netz und ihre Relevanz für die folgende Standardänderung; unbelegt sind heutige Verbreitung, Absicht und eine allgemeine Produktbewertung.

Erik Kline schrieb RFC 8910 gemeinsam mit Warren Kumari. Der abgelöste RFC 7710 stammt von Kumari, Olafur Gudmundsson, Paul Ebersman und Steve Sheng. Die Revision war Gemeinschaftsarbeit. Klines Rolle ist die eines Mitautors, der den negativen Versuchsbefund präzise in den neuen Standard aufnahm.

Ein Register programmiert keine Firmware um

DHCPv4 kennzeichnet eine Option mit einem acht Bit langen Code. IANA verwaltet den gemeinsamen Namensraum, damit Server und Clients nicht raten müssen. Die Zuweisung beantwortet verbindlich, welche standardisierte Bedeutung eine Zahl trägt.

Ein Endgerät lädt diese Tabelle aber nicht bei jedem Paket. Es verzweigt nach der Logik seiner installierten Software. Erwartet der eine Client bei 160 eine URI und der andere eine andere Struktur, wird aus denselben Bytes eine unterschiedliche Zustandsänderung. Ein Paket kann nach RFC 7710 korrekt sein und trotzdem einen älteren, privaten Parser auf einen falschen Pfad schicken.

Darum bedeutet normative Autorität nicht empirische Leere. Das Register kann öffentliche Spezifikationen, formale Reservierungen und bekannte Geschichte erfassen. Es kann nicht jede ausgelieferte Binärdatei, private Konvention oder nie dokumentierte Erweiterung durchsuchen. Erst Verkehr mit einer repräsentativen Gerätepopulation beantwortet die zweite Frage: Wer reagiert tatsächlich auf diese Zahl?

RFC 3679 zeigt, dass DHCP diese Unterscheidung schon früher brauchte. Das Dokument gab Codes zur Neuzuweisung frei, deren Vorhaben nie zum Standard oder zur allgemeinen Nutzung wurden. Andere, nicht in einem RFC dokumentierte Codes blieben reserviert, weil Geräte sie einsetzten. Für eine Wiedervergabe war also nicht nur Papierlage, sondern Feldwissen entscheidend.

114 löst das Ziel, nicht die Vergangenheit

RFC 8910 erschien im September 2020 auf dem Standards Track, ersetzte RFC 7710 und aktualisierte RFC 3679. Die DHCPv4-Captive-Portal-Option erhielt Code 114. Das heutige IANA-Register für BOOTP- und DHCP-Parameter führt 114 als DHCP Captive-Portal mit Verweis auf RFC 8910.

Code 160 steht als Unassigned in der Tabelle. Der Eintrag trägt zugleich den Satz, dass er zuvor RFC 7710 zugewiesen und auch durch Polycom genutzt worden sei. „Nicht zugewiesen“ beschreibt den aktuellen normativen Besitzstand. Der Zusatz warnt davor, dies mit weltweiter Nichtbenutzung gleichzusetzen.

Nur der DHCPv4-Raum wurde umnummeriert. Bei DHCPv6 bleibt die Captive-Portal-Option 103, bei IPv6 Router Advertisements 37. Wer pauschal von einer Änderung 160→114 spricht, muss DHCPv4 nennen; sonst werden drei getrennte Coderäume fälschlich zu einem.

Auch ein neuer RFC erreicht Altgeräte nicht aus der Ferne. DHCP-Server müssen 114 senden, Relays und Zugangssteuerungen müssen die Option unverändert tragen, Clients müssen sie verstehen. Eine Übergangsphase enthält daher 114-fähige Geräte, 160-empfindliche Altgeräte und solche ohne CAPPORT-Unterstützung. Beide Codes gleichzeitig zu senden kann die alte Kollision erneut auslösen.

Der Dienst ist die letzte Messstelle

Vor einer breiten Aktivierung braucht der Betreiber ein Inventar nach Hardware, Firmware und Aufgabe. Im Labor wird der exakte Code mit Länge und repräsentativer Nutzlast eingespielt. Danach folgt ein begrenztes, bewusst gemischtes Canary-Segment.

Adresse und Lease sind nur Zwischenstände. Zu prüfen sind auch Bootabschluss, Dienstregistrierung, Erreichbarkeit und die eigentliche Gerätefunktion. Ein Telefon kann DHCP erfolgreich beenden und später scheitern. Ein grüner ACK-Zähler wäre dann technisch richtig und betrieblich unvollständig.

Der Rückweg muss vorher feststehen: eine versionierte Serverkonfiguration, die die Option rasch entfernt. Nicht aktualisierbare Bestände können ein eigenes Segment oder eine ausdrückliche DHCP-Richtlinie benötigen. Sichtbare Ausnahmen sind billiger als eine vermeintlich einheitliche Umstellung, deren unbekannte Geräte erst im Störungsfall auffallen.

Ein guter Standard behält den negativen Befund

Die Episode ist kein Beweis, dass privater Gebrauch einen Code rechtmäßig besetzt. Eine solche Regel würde stille Aneignung belohnen und gemeinsame Register zerstören. Sie ist ebenso wenig Beweis, dass eine Zuteilung installierte Decoder überschreibt.

Die belastbare Lösung verbindet Zuständigkeiten. IANA hält die anerkannte Bedeutung fest. Begrenzte Tests prüfen die angenommene Verfügbarkeit gegen reale Implementierungen. Bei einer Kollision kann der Standard sein Ziel beibehalten und den Mechanismus ändern.

RFC 8910 dokumentiert Ort, begrenzte Gerätebeschreibung, allgemeine Wirkung und Konsequenz. Diese Zurückhaltung schützt vor unbelegten Vorwürfen und bewahrt zugleich den wertvollen Teil des Fehlschlags. Der Warnhinweis bei 160 ist eine kleine Kompatibilitätsakte, die künftige Entscheidungen besser macht.

Quellen